Reference architecture · Version 0.1
Enterprise AI Agent Authorization Reference Architecture
A vendor-neutral control model for identity, delegated task authority, per-action enforcement, bounded credentials, approval and end-to-end evidence.
AI-agent identity is rapidly becoming a first-class capability in enterprise IAM. Microsoft Entra Agent ID, for example, now distinguishes autonomous agents from agents acting on behalf of users and provides dedicated lifecycle and governance constructs for agent identities. Microsoft Learn
Identity alone, however, does not answer the full runtime question:
Should this agent, under this task authority, perform this exact action against this resource right now?
This reference architecture shows one way to preserve existing IAM, IGA, PAM and policy infrastructure while introducing a mandatory authorization boundary around agent tool execution.
Open the image for full resolution, or download without signing up.
The model
1. Identity remains authoritative. Humans, workloads and agents receive governed identities through the enterprise identity plane. Agent ownership, sponsorship and lifecycle stay visible to governance systems.
2. Task authority is explicit. An agent should not infer its authority solely from whatever credentials happen to be available. A bounded task expresses the issuer, acting agent, permissible actions/resources, expiry and delegation constraints.
3. Every consequential tool call is authorized. Before execution, a Policy Enforcement Point canonicalizes the requested action and resource and sends the exact request context to the Policy Decision Point.
4. Credentials are brokered, not permanently exposed. Where the downstream system requires credentials, the preferred pattern is bounded or short-lived access rather than reusable standing credentials.
5. Approval binds to the exact action. Human approval should authorize the specific request being executed rather than becoming a blanket elevation for subsequent actions.
6. Evidence extends beyond the IAM decision. The authorization decision, grant, downstream request ID and target-system result should be correlated so investigators can reconstruct what was requested, authorized and actually executed.
7. There must be no bypass path. If the agent can reach the target directly with another credential or route, the enforcement architecture is incomplete.
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, execution controls and evidence around agentic workloads.
Where this becomes difficult
The hard operational questions appear as agent environments scale:
- How is task authority created and governed?
- Where should the PEP live: agent runtime, MCP gateway, API gateway or resource?
- How is delegation bounded across agent-to-agent handoffs?
- How are exact actions represented consistently across heterogeneous tools?
- How do policy and task context remain synchronized as workflows change?
- How do organizations prove that what the target executed matches what IAM authorized?