A Reference Architecture for Continuous Authorization of AI Agents

Something strange is happening inside large enterprises right now. Security architects have been asked, often with very little warning, to secure AI agents that somebody in platform engineering already put into production. The board wants a one-pager. Compliance wants a line-by-line mapping to NIST AI 800-4 and the EU AI Act. The platform team has already shipped seven agents and is planning seventeen more, which makes the one-pager feel less like a summary and more like a retroactive apology. Everyone is pointing at each other, and everyone is asking the same question.

What is the reference architecture?

And the honest answer, in April 2026, is that one doesn't really exist. There are vendor diagrams. There are analyst quadrants. There are NIST documents with useful language and no implementation detail. What is missing is a layered, buildable reference model that shows how continuous authorization actually plugs into an enterprise stack when the workloads asking for access are no longer humans.

So we built one. Here is the EnforceAuth Continuous Authorization Reference Architecture, the reasoning behind each layer, and the gaps it is designed to close.

Why Does AI Authorization Need a New Reference Architecture at All?

The short answer: every assumption inside the old IAM stack was built for humans signing into applications. AI agents violate those assumptions in ways that are not cosmetic. They are structural.

Human IAM assumes a session. A person logs in once, a token lives for eight hours, and the network trusts that token until it expires. AI agents do not have sessions in any recognizable sense. A single agent can execute thousands of discrete actions per minute, each one against a different resource, each one with different risk characteristics. Trust the authentication event, wave everything through afterward, and you end up with an agent provisioned for ticket triage quietly pulling PHI from a clinical data lake.

Human IAM also assumes an identity directory. Okta, Entra, Ping. These tools were designed around employees and contractors. They are catching up on workload identity, but the center of gravity is still humans. Meanwhile the non-human identity population in most Fortune 500 environments is now 10 to 50 times larger than the human one, and growing faster every quarter as agentic frameworks ship to production.

And human IAM assumes that authorization is mostly a role-binding problem. Sales gets Salesforce. Finance gets NetSuite. Done. Agents don't map to roles cleanly, because their scope shifts per task and the set of resources they need to touch is shaped by the prompt they just received, not by an HR record. A reference architecture for AI authorization has to be decision-centric, not role-centric.

That framing shapes everything below.

The Five Layers

The reference architecture has five layers plus a regulatory spine. Each layer answers a specific question about the lifecycle of a single authorization decision. If you remove any one of them, the remaining four stop producing useful security outcomes and start producing audit noise.

Layer 1: Identity Assertion

Before you can authorize anything, you need to know who is asking. For AI agents, that is much harder than it sounds. An agent is not a user. It's a workload, possibly spawned by another agent, possibly executing on behalf of a human who authenticated four hours ago, possibly delegating half its work to a downstream tool via MCP that it discovered at runtime. None of that fits into the identity assumptions your existing IAM stack was built around.

Identity Assertion at this layer has three components:

• SPIFFE workload identity. A cryptographically verifiable identity for the agent itself, issued at workload instantiation. Not borrowed from a service account credential sitting in a vault.
• Delegation chain. The full trail of who asked for what on whose behalf. When a finance analyst asks an agent to reconcile accounts, and that agent invokes three downstream tools, the delegation chain is what lets the policy engine reason about the original principal and their actual authority.
• Autonomy metadata. A declaration of how much independent judgment this workload is permitted to exercise. An agent running with human-in-the-loop approval for every action is a very different risk posture than one operating fully autonomously at 3 AM. The architecture should know the difference before the first policy check runs.

Most enterprises skip this layer entirely and attach agents to long-lived API keys or shared service accounts. That is where the chain of custody breaks. We covered the mechanics of this failure in why authenticated machine identities forgot to authorize.

Layer 2: Context Assembly

Identity alone is not enough to make a good authorization decision. The engine needs context. And not just any context, the right context, assembled fast enough that the decision itself still lands under 50ms.

A context payload for a single AI agent action should include:

• Agent identity (from Layer 1)
• Resource sensitivity. Is this a logging endpoint or a table full of PHI?
• Action type. Read, write, delete, execute, invoke another agent?
• Session history. Has this agent done anything unusual in the last five minutes?
• Delegation chain. Who does this action ultimately trace back to?
• Time and location. Is the agent running from the region it was provisioned for, at a time that makes sense?

Context assembly is where most homegrown authorization layers collapse. Teams build something that checks identity and resource, then ship it, then discover six months later that they cannot explain to an auditor why a specific decision was made because half the context was never captured. The reference architecture treats context as a first-class input, not a debugging afterthought.

Layer 3: Policy Evaluation, the AI Security Fabric

This is the core of the architecture. The Continuous Authorization Engine takes the assembled context and answers one question per request: allow, deny, or escalate.

Four capabilities sit inside this layer:

• Policy-as-Code. Policies are Rego (OPA-native), versioned in git, tested in CI/CD, rollbackable, auditable. A policy is a pull request. Not a ticket to the security team.
• Decision Engine. Per-action evaluation with behavioral baseline checks. An allow, deny, or escalate decision on every request, every time. No cached trust.
• Compliance Libraries. Pre-built policy packs for HIPAA, DORA, SOX, the EU AI Act, and FERPA. Writing policy from scratch for every regulation is how compliance deadlines slip.
• NHI Lifecycle. Provisioning, rotation, privilege management, and deprovisioning for non-human identities. Authorization logic that cannot reason about credential rotation or agent retirement is going to fail in the middle of an incident.

Why OPA? Because policy portability matters more than policy novelty. When you commit to policy-as-code on a widely-adopted engine, you get something that survives vendor consolidation, acquihires, and roadmap changes. Your policies are your IP.

And why add Cedar and Zanzibar compatibility on top? Because enterprises rarely get to pick a single policy language in real life. Different teams have different patterns, different existing investments, and different appetites for rewrite work. The architecture accommodates that. It doesn't demand a clean slate.

Layer 4: Decision Enforcement Across Four Domains

A policy decision that is not enforced at the point of action is a suggestion. The reference architecture enforces across four domains because a single AI agent workflow will cross all of them in one task.

• Applications. EHR, CRM, SaaS, internal apps. Enforcement happens at the API gateway with a per-request policy check before the request reaches the app.
• Infrastructure. AWS, Azure, GCP, Kubernetes. Workload-level enforcement, consistent across clouds. An agent that is allowed to scale one service is not automatically allowed to rotate IAM roles.
• Data. Databases, data lakes, PHI stores. Row and column-level policies, plus context-aware data masking. The same agent asking the same query can get different results depending on the delegation chain that led to the query.
• AI Workloads. Agent-to-agent calls, tool calls, model API access, MCP protocol enforcement. This is the domain most architectures entirely miss. It's why agents end up with quiet access to each other nobody has ever authorized.

Fragmented enforcement is what you get when each of these four domains is owned by a different team with a different policy language. It is the status quo at most Fortune 500s today. It is also the reason most incident post-mortems read like four separate teams discovering they each owned a fraction of the problem.

Layer 5: Unified Audit and Monitoring

Every decision the engine makes generates a log. That log is the raw material for detection, forensics, and compliance reporting. The reference architecture centralizes this into a single audit layer rather than scattering it across the four enforcement points.

The audit layer carries:

• Decision logs. Who asked, what they asked for, what the engine decided, which policy drove the decision, and why.
• Behavioral anomaly detection. The same agent doing unusual things relative to its own baseline.
• Compliance reporting. Pre-formatted output for HIPAA, DORA, SOX, EU AI Act, and FERPA audits.
• Incident forensics. Fast, accurate reconstruction of what an agent was doing before, during, and after an incident.
• NIST AI 800-4 coverage. The six-category monitoring requirements mapped to the decision stream.

This layer is what turns the first four layers from a control mechanism into an auditable control mechanism. Regulators, boards, and incident responders all want the same thing: a single, tamper-evident story about what an agent did and why it was allowed to.

How Does This Architecture Map to NIST, the EU AI Act, and DORA?

Reference architectures that ignore regulation are shelfware. We designed this one so every layer has a defensible mapping to at least one active regulatory framework.

The EU AI Act's high-risk system obligations take full effect in August 2026. That's four months away. DORA is already live for financial services in the EU. NIST AI 800-4 is the federal monitoring baseline that U.S. agencies are being held to right now. None of these are optional for Fortune 500s operating in regulated industries, and all of them assume the existence of a runtime authorization layer that most organizations have not yet built.

What Existing Approaches Miss

A few patterns show up repeatedly when we review existing authorization designs at large enterprises. Each of them looks reasonable in isolation. In combination with agentic workloads, each one breaks.

Pattern 1: Extending RBAC to agents. This is the most common shortcut. Define a role called ai-agent-finance, map it to a set of permissions, and attach agents to the role. The problem is that agents don't fit into stable roles. Their scope shifts per task, and the role sprawl required to represent real agent behavior becomes its own compliance problem inside six months.

Pattern 2: API gateway policies only. Enforcing at the API gateway is necessary but not sufficient. Gateways do not see data-layer operations, they do not see agent-to-agent calls made directly over internal networks, and they do not see MCP tool invocations happening inside a single runtime. A gateway-only architecture leaves three of the four enforcement domains uncovered. That's not a gap. That's a wide-open door.

Pattern 3: Point solutions per domain. Separate tools for app-level access, infrastructure permissions, database governance, and AI safety. Each tool does its job. None of them share a policy language, a decision log, or a definition of identity. When something goes wrong, forensics takes weeks, because the story has to be stitched together from four systems that weren't designed to tell a story together.

Pattern 4: Governance platforms without enforcement. Observing what AI does is valuable. It is not the same as controlling what AI is allowed to do. We wrote about this distinction in detail. The short version: governance without authorization is observation without control.

The reference architecture is designed as a direct response to each of these failure modes.

How Do You Actually Adopt This?

Reference architectures are only useful if they can be phased in. No Fortune 500 is going to replace four enforcement domains in a single quarter. Nobody should try. Here is the adoption sequence we recommend, in order, based on how it has played out at the enterprises that are furthest along.

1. Inventory non-human identities. You cannot authorize what you cannot see. Start with a real count of the agents, service accounts, and machine credentials in production.
2. Establish Layer 1 identity assertion for new agents. Every new workload gets SPIFFE-based identity and a declared delegation model. Do not try to backfill every existing agent at once.
3. Pilot Layer 3 policy evaluation on one domain. Applications is usually the fastest win because API gateway integration is well-understood.
4. Expand enforcement domain by domain. Data is typically second because of compliance pressure. Infrastructure and AI workloads follow.
5. Turn on the unified audit layer early. Even before full enforcement coverage, centralized decision logs give security teams visibility they did not have before.

The sequence matters. Teams that try to stand up enforcement before identity assertion is in place end up rewriting policies twice.

Common Questions About Continuous Authorization

What is continuous authorization for AI agents?

Continuous authorization is the practice of evaluating an authorization policy on every single action an AI agent takes, in real time, with full context. It replaces the legacy model, where an identity is authenticated once and then trusted for the duration of a session. Sessions don't fit agents. For workloads taking thousands of actions per minute across different resources, per-action evaluation is the only model that produces meaningful control.

How is this different from traditional IAM?

Traditional IAM authenticates users and maps them to static roles. Continuous authorization authenticates workloads, assembles context per request, and evaluates a policy decision for every action. The inputs, the frequency, and the identity model are all different. Attempting to retrofit agents onto human IAM produces the authorization gap most enterprises are dealing with today.

Why does the architecture need five layers instead of one unified policy engine?

The policy engine is necessary but not sufficient. Without identity assertion, the engine doesn't actually know who is asking. Without context assembly, it can't reason about risk. Without enforcement across four domains, decisions are advisory. Without unified audit, forensics and compliance both fall apart the moment a regulator asks for evidence. Remove any one layer and the other four stop producing useful control.

How does this align with NIST AI 800-4 and the EU AI Act?

NIST AI 800-4 requires continuous monitoring across six categories, which maps directly to the unified audit layer. The EU AI Act requires runtime controls and auditable decisions for high-risk systems, which is what the policy evaluation and enforcement layers deliver. DORA, COSAiS, and the NCCoE guidance map to identity assertion and enforcement across infrastructure. The reference architecture was designed to produce defensible compliance evidence by construction.

What is the first thing a Fortune 500 security team should do?

Inventory your non-human identities. Most teams discover the count is three to ten times higher than they expected, and that a meaningful percentage have production access through credentials with no clear owner. Everything else in the architecture depends on knowing what you are authorizing in the first place.

Where This Goes Next

The reference architecture is not finished. It will evolve as NIST publishes more guidance, as the EU AI Act's enforcement patterns become clearer, and as agentic frameworks continue to ship faster than governance catches up. What matters right now is that security architects have a coherent starting point instead of a blank whiteboard.

If your team is trying to figure out what continuous authorization actually looks like in your environment, come talk to us. And if you want the short version of why this problem is urgent, AI agents are already inside the building is where we'd start.

The authorization gap does not close itself. Architectures do.