Reference architecture · Version 0.2

Enterprise AI Agent Authorization Reference Architecture

A vendor-neutral control model for identity, delegated authority, runtime governance, per-action enforcement, credential isolation and tamper-evident evidence.

AI-agent identity is becoming a first-class enterprise control, but authenticating an agent does not determine whether a particular action is appropriate within its current task and session.

The runtime question is:

Should this agent, under this task authority, perform this exact action against this resource right now?

Version 0.2 preserves existing IAM, IGA, PAM, API and target-system controls while adding a mandatory authorization and evidence boundary around routed agent tool execution.

identity → authority → runtime governance → enforcement → evidence

Version 0.1 agent authorization reference architecture: control plane, initiator and agent zone, tool adapter PEP, policy decision, grant broker, target resource, and evidence correlation — Open or download the version 0.1 diagram without signing up.
Download v0.1 PNG Download v0.1 PDF

The model

1. Identity remains authoritative. Humans, workloads and agents receive governed identities through the enterprise identity plane. The runtime control layer validates those identities; it does not create a parallel source of lifecycle truth.
2. Task authority is explicit. Effective authority is the intersection of identity entitlement, agent registration, assigned connections, bounded task, policy, session constraints and target authorization. Possession of a credential is not authority.
3. Runtime context changes the decision. The policy input includes authoritative session state such as prior calls, rows read, data classes encountered, approvals and external writes. Individually valid actions can become unsafe in combination.
4. Every consequential tool call crosses a PEP. Before dispatch, a Policy Enforcement Point canonicalizes the exact action and asks a Policy Decision Point for ALLOW, DENY, CONSTRAIN or REQUIRE APPROVAL. Missing mappings and unavailable policy fail closed.
5. Upstream credentials remain isolated. The agent authenticates to the gateway, while the gateway separately holds the upstream MCP authorization. Tokens and secrets are resolved only after a permitting decision and are never returned to the agent.
6. Approval binds to the exact action. Human approval covers the bound actor, task, connection, tool, canonical arguments, constraints, policy version and expiry. A materially changed retry is a new authorization request.
7. Evidence is correlated and tamper-evident. Receipts correlate request, context, decision, dispatch status, target request and result. Chaining or external anchoring should reveal mutation or reordering, while its trust and retention limits remain explicit.
8. PEP coverage is a measurable invariant. Tool discovery, calls, constrained dispatch and post-approval retries use the same enforcement path. If an agent can reach the target directly with another credential or route, coverage is incomplete.
9. Connections are upstream MCP servers. The gateway federates approved MCP servers rather than rebuilding each SaaS API. It discovers and namespaces tools, exposes only assigned capabilities and applies one governance lifecycle to every routed call.

How effective authority is composed

The gateway may narrow authority, but it cannot create access the target system would deny. The effective set is the intersection of the controls below:

IdP entitlement ∩ agent registration ∩ assigned connections ∩ task authority ∩ policy ∩ session constraints ∩ target authorization

The upstream MCP connection model

Northbound, an agent authenticates to a governance gateway and sees only tools from its assigned connections. Southbound, each connection is an approved upstream MCP server reached over a supported transport. The gateway discovers and namespaces tools, converts each call into a canonical action, evaluates policy, then injects the separately held upstream credential only when dispatch is permitted.

This model avoids rebuilding every SaaS API, but it does not make an upstream server trustworthy by default. Operators still need to review its provenance, deployment, scopes, tool schemas and update path. A changed or unmapped consequential tool should fail closed until policy coverage is restored.

Evidence and its limits

A receipt should bind the canonical request, session summary, decision, policy version, approval, effective arguments, dispatch status, target correlation and result. Hash chaining, signatures or external anchoring can make retained evidence tamper-evident.

Tamper-evident does not automatically mean immutable, independently timestamped or non-repudiable. The evidence design must state who controls signing keys, what deletions can be detected, how long records are retained and which target facts are independently verifiable.

What this architecture is not

This is not another identity provider.

It does not assume Entra, Okta, CyberArk, Delinea, Axiomatics, SGNL or existing governance platforms need to be replaced.

It is an architectural pattern for composing identity, policy, task authority, runtime context, execution controls and evidence around agentic workloads. It governs only actions routed through an enforced path; direct credentials and alternate routes remain bypasses until separately removed or controlled.

Where this becomes difficult

The hard operational questions appear as agent environments scale:

Who creates, narrows, expires and revokes task authority?
Which agent actions bypass the selected PEP, including direct SDK or target access?
How is delegation bounded across agent-to-agent handoffs?
How are exact actions represented consistently across heterogeneous tools?
Which session facts are authoritative, and how are concurrent actions ordered?
How are upstream MCP servers, tool-schema changes and their credentials governed?
How do organizations prove that what the target executed matches what IAM authorized?