AI Agent Authorization: A Practical Architecture

An AI agent can plan and call tools, but neither ability answers the authorization question: which software may act, for which user, against which upstream account, and within what boundary? Treating an agent as a trusted extension of a user collapses those questions into one bearer token. A safer architecture represents each link explicitly and validates it when a tool is called.

Axec is an authorization and credential-governance layer between client applications and upstream systems. It authenticates the calling Application, collects user consent, selects an approved upstream credential, and exposes the resulting authority through MCP. It does not make the model itself a security principal or infer permission from a prompt.

The Authority Chain

A useful agent authorization model has distinct records for distinct facts:

In Axec, an Application Connector attachment sets the administrator-owned ceiling. Consent may narrow that ceiling, never expand it. A Grant then pins the exact Application Credential, Connector attachment, Connection or workspace Vaulted Credential, scopes, capabilities, and contract digests that were approved.

This separation prevents a common confused-deputy failure: possession of a user token no longer automatically means that every agent in the environment can use it.

A Request Flow That Preserves Context

For user-delegated access, the browser and token flows should retain the same resource and client bindings end to end:

1. The client creates a PKCE verifier and opens Axec authorization for an exact MCP resource.
2. Axec resolves the client Application, its active credential, the gateway, and attached Connectors.
3. The user authenticates and connects an upstream account if no usable Connection exists.
4. Axec presents a backend-owned consent projection describing credential source and capabilities.
5. Acceptance creates a durable Grant and a one-use authorization code.
6. The client redeems the code with its verifier and the same resource.
7. Each MCP request presents the resulting gateway bearer.
8. Axec reloads current authority, restricts tools, decrypts the selected credential only for execution, and invokes upstream.

A representative authorization request is:

GET /oauth2/authorize?response_type=code
  &client_id=agent-client
  &redirect_uri=https%3A%2F%2Fclient.example%2Fcallback
  &resource=https%3A%2F%2Faxec.example%2Fg%2Fresearch%2Fmcp
  &scope=mcp%3Ainvoke
  &code_challenge=BASE64URL_SHA256_VERIFIER
  &code_challenge_method=S256
  &state=OPAQUE_CLIENT_STATE

The resource prevents a token intended for one gateway from becoming a general token. PKCE protects authorization-code redemption for public clients. Neither mechanism replaces consent or capability enforcement.

Enforce Authority at Tool-Call Time

Admission checks at login are insufficient for autonomous work that may continue after a credential, connection, or grant changes. A gateway bearer should be a signed reference to authority, not a frozen copy of every permission.

Axec evaluates the live authority graph on every MCP request. Revoking an Application Credential, disabling a gateway, removing a Connector attachment, revoking a Connection, or revoking a Grant can therefore stop later calls without waiting for all access tokens to expire. Reconnecting creates a new Connection identity; old Grants do not silently inherit the replacement credential.

Tool filtering also matters. The agent should see only capabilities allowed by the active attachment and Grant. Validate tool arguments separately because capability authorization does not prove that every parameter is safe. A narrowly authorized send_message tool can still leak data if recipients and content are unconstrained.

Practical Recommendations

Start with the smallest authority graph

Attach only required Connectors to an Application gateway. Request selected providers rather than eagerly including all attachments when the workflow knows what it needs. Prefer session Grants; permit offline access only for a concrete unattended workflow with an owner and revocation path.

Make consent specific

Show the Application, upstream account or workspace credential source, capabilities, duration, and consequence. Consent text should describe an action such as “read issues and create comments,” not a vague category such as “access workspace.” Revalidate the exact displayed snapshot before acceptance so configuration cannot change underneath the user.

Preserve evidence without storing secrets

Record client identity, Grant identity, decision, capability, and upstream outcome correlation. Do not log bearer tokens, refresh tokens, personal API keys, decrypted payloads, or arbitrary tool arguments. Evidence should support incident review without becoming a second credential store.

Security Caveats

Authorization cannot make an unsafe tool safe. Upstream APIs still require input validation, rate controls, and their own audit protections. Prompt injection can influence which authorized tool an agent chooses, so separate authorization from model intent and add human confirmation for irreversible or unusually consequential actions.

Workspace credentials also deserve explicit disclosure: the requesting Application may use approved authority through Axec, but should not receive the underlying credential. Finally, application-principal access is not delegated user access. In Axec, a client_credentials Application may use only its own gateway and active vaulted or no-auth Connector attachments; it cannot use a user’s Connection.

FAQ

Is an agent a new identity type in Axec?

No. Agent is product terminology for an Application doing agentic work. The Application remains the software principal, and its credential authenticates it to Axec.

Does OAuth scope alone authorize a tool call?

No. Scope is one boundary. Effective authority also depends on the target resource, active gateway attachment, consented capabilities, pinned credential source, and live status of every dependency.

Should every action require a human prompt?

No. Routine, reversible operations can run within a clear Grant. Require fresh human approval for authority expansion, credential connection, and high-impact actions rather than adding approval theater to every read.

Primary References

• OAuth 2.0 Security Best Current Practice (RFC 9700)
• OAuth 2.0 Authorization Server Issuer Identification (RFC 9207)
• Resource Indicators for OAuth 2.0 (RFC 8707)
• Model Context Protocol specification