Credentials
Axec uses different credentials for different trust relationships. Keeping them separate prevents an agent from turning proof of its own identity into unrestricted access to an upstream account.
Choose the credential path from the use case
Section titled “Choose the credential path from the use case”- A User authorizes an agent to work in their account: use a User OAuth Connection and delegated Grant. OAuth Authorization Code with PKCE (RFC 7636) keeps the authorization response bound to the client that started it.
- A backend agent runs a shared automation task: use a workspace Vaulted Credential through an autonomous Application. The credential remains an upstream secret; the Application receives only an Axec gateway bearer.
- A confidential service must call a provider directly: use governed OAuth credential release only when mediation is impossible. Axec controls delivery but cannot govern subsequent provider traffic.
- An operator automates Axec itself: use a Service Account management token, not a Connector credential or MCP gateway token.
This choice is a trust-boundary decision, not an SDK convenience. Prefer the path that keeps the credential on the Axec side of the execution boundary.
Credential roles
Section titled “Credential roles”| Credential | Owner and purpose | Where it is usable |
|---|---|---|
| Application Credential | Proves a downstream Application to Axec | Axec OAuth authorization or token flow |
| Connection | A User’s OAuth account or personal credential for one Connector | Axec resolves it only after delegated authority is admitted |
| Vaulted Credential | A workspace-owned bearer token, API key, or Basic credential for one Connector | An eligible autonomous Application attachment or a delegated Grant |
| Service Account credential | A tenant management principal’s long-lived secret | Only the tenant token endpoint, in exchange for a short-lived management token |
An Application Credential never authenticates to an upstream system. A Connection or Vaulted Credential never authenticates a caller to Axec. A Service Account cannot invoke an MCP gateway or inherit a User Connection.
Vaulted and brokered upstream access
Section titled “Vaulted and brokered upstream access”A Vaulted Credential is workspace-owned upstream authority. Axec stores its typed payload encrypted and exposes only safe metadata, never the secret value. An autonomous Application can use only its own active vaulted or no-auth Connector attachments. A delegated Grant can also pin an exact Vaulted Credential when the User consents to that capability.
For User OAuth, Axec stores the access and refresh tokens in a User-owned Connection. A mediated MCP or proxy call keeps that credential inside Axec: live authority is reloaded, then Axec injects the credential for the selected upstream capability.
An eligible confidential delegated Application can instead request a governed OAuth credential release. Axec authorizes and records that release, but a released provider token is no longer mediated. Axec cannot inspect, mask, revoke, or observe later direct provider calls made with it. Prefer mediated MCP or proxy execution when the agent needs per-action governance.
Consent creates authority, not credential possession
Section titled “Consent creates authority, not credential possession”User consent creates a GrantBundle and independent Grants. Each Grant pins the exact Connector, Connection or Vaulted Credential, capability set, scope, and contract digests that were approved. The Application receives a gateway bearer, not the Connection’s refresh token or Vaulted Credential.
This is why reconnecting an OAuth account creates a new Connection identity and why replacing a Vaulted Credential does not silently widen an old Grant. The next use must pass live checks against the same approved authority path.
Read Policies and approvals to see how Axec can further narrow authority that already exists.