Runtime Authorization for Agentic AI: Fixing the Three Breakpoints in Legacy IAM

This is a webinar recap featuring Ken Huang, Co-chair, AI Safety Working Group, Cloud Security Alliance. You can watch the recording below:

The enterprise architect and the AI platform owner sit through the same board deck. Autonomous agents in production, MCP tools in flight, sub-agents spawning across the pipeline, and one uncomfortable line item: “access controls under review.”

Their IAM stack handles humans logging in at 9am. The agents run at 3am, invoke tools, retrieve data, and delegate tasks to other agents that no policy ever explicitly authorized. So how do you extend identity-first security to agent behavior that shifts second by second?

The runtime authorization model below draws on Ken Huang’s MAESTRO framework, the Cloud Security Alliance’s agent identity work, the OWASP Agentic Skills Top 10, and PlainID’s own production deployments.

Legacy IAM Has Three Breakpoints for Autonomous AI Agents

OAuth and OIDC handle standard web logins well. They cover single sign-on, social login, and human authentication at scale. Autonomous agents break every assumption underneath them.

Human Consent Does Not Scale to Autonomous Agents

The OAuth designers built the protocol around a person clicking “approve” at the moment of consent. Agents run continuously. They act on their own schedules, initiate their own workflows, hand off work to sub-agents, and rarely pause for consent. No human sits at the browser to approve the moment of action.

Static Scopes Miss Identity, Context, and Intent 

OAuth scopes are coarse. A scope says “can read email” or “can post to calendar.” Here’s how Kobi Gol, PlainID’s VP Product, sums up the shared limit of OAuth and OIDC:

“You cannot express something very context-aware from a permission perspective through those protocols.” 

Coarse yes-or-no scopes cannot represent the identity, context, and intent behind a specific agent action.

Login-Time Tokens Ignore Runtime Context

OAuth issues a token at login. The token then covers whatever the agent does for the next hour or day, regardless of what the environment looks like when the agent finally acts. Runtime context does not enter the decision.

So the fix has three parts:

• Agents need their own verifiable identity, distinct from the human they operate on behalf of.
• Static scopes need to give way to decisions that weigh identity, context, and intent together.
• And enforcement has to happen at the moment of action rather than at login.

Everything else in the article follows from those three requirements. Ken Huang’s MAESTRO framework maps where each one lives in the agent stack.

MAESTRO’s Risk Lens for Agentic AI

Ken Huang, Co-chair of the AI Safety Working Group at the Cloud Security Alliance, spent last year trying to threat-model production agentic systems with the frameworks the industry already had, including STRIDE, PASTA, LINDDUN. None of them fit.

“I did threat modeling for agentic AI systems using traditional STRIDE and PASTA. They can’t really address the nondeterministic and autonomous agentic system. It also has a very complex identity delegation. That’s why I created the MAESTRO framework.” – Ken Huang

MAESTRO stands for Multi-Agent Environment, Security, Threat, Risk, and Outcome. Ken published it as a seven-layer reference architecture for the entire agentic stack.

The seven layers are:

1. Foundation Models,
2. Data Operations,
3. Agent Frameworks,
4. Deployment Infrastructure,
5. Evaluation and Observability,
6. Security and Compliance, and
7. Agent Ecosystem.

Each layer has its own threat model. The framework does one job better than STRIDE or PASTA: it forces cross-layer analysis.

Threats chain. A poisoned dataset at Layer 1 becomes a hallucinated tool call at Layer 3, which becomes an unauthorized data pull at Layer 2, which becomes a compliance exposure at Layer 6.

Authorization is the primary control across the middle layers. Data retrieval, agent-to-tool invocation, agent-to-agent delegation, and ecosystem access decisions all resolve to the same question: can this identity, in this context, take this action right now? Runtime authorization is the answer.

What a Good AI Agent Identity Looks Like

No formal standard exists yet. ITU and IETF are still working through it. The Cloud Security Alliance whitepaper Ken co-authored with a group including researchers from AWS, Salesforce, MIT, and CSA proposes a working answer.

The whitepaper builds on Decentralized Identifiers and Verifiable Credentials. Every agent gets a unique identifier. The identifier carries essential attributes: which model powers the agent, which framework it runs on (LangChain, Semantic Kernel, custom), which tools it can invoke, which behavioral scope it operates in, and the security posture it received at provisioning.

“You need the agent identity to solve how you do the attestation, provisioning, authentication, authorization, and the auditing. Eventually if something breaks you need to do an incident response, you can tie the identity, you can find it.” – Ken Huang

What happens when an agent’s model or attributes change mid-flight? Any change to the model or a key attribute should produce a different identity. The agent must go through provisioning again to receive a new identifier. The framework does not permit silent context switching.

Agent identity alone does not solve authorization, but it gives authorization something concrete to bind to. PlainID’s Agentic Identity Platform binds agent identity to the human identity it acts on behalf of, then evaluates the pair at every decision point.

The Multi-Hop Trust Problem in Multi-Agent Systems

Single-agent authorization is only the beginning. Production agentic systems delegate.

A planning agent kicks off an execution agent. The execution agent calls a retrieval agent, which invokes an MCP tool. Somewhere along the chain, the original human intent thins out. The default behavior of most agent frameworks over-provisions the whole chain. The child agent inherits the parent’s scope. Session context becomes a blanket authorization.

The answer is intent-based access control. Bind natural language intent to an enforceable policy through a domain ontology. For example, if someone tells an agent “I want to buy an apple,” the word apple could mean an iPhone, a fruit, or a flight to New York (The Big Apple). Only the domain resolves the ambiguity. In a cellphone-domain ontology, “apple” resolves to an iPhone.

The enforcement pattern that follows is revalidation at every hop. Each delegated call carries the original intent, the current identity chain, and the current context. Each hop asks the policy engine the same question again. There are no session-wide free passes.

Kobi reinforces the pattern from PlainID’s customer deployments:

“You need to figure out a way to control those actions at different points across the execution pipeline. At each hop of the execution pipeline you need to revalidate.” – Kobi Gol

PlainID’s Policy 360° includes a Map View that visualizes those decision paths, showing where each hop consulted the policy and what it decided.

Runtime Authorization Means Externalized Policy, Distributed Enforcement

The pattern of centralized management, distributed enforcement separates two problems that legacy IAM tends to conflate:

1. Policy authoring, governance, and lifecycle happen in one place. Every rule that matters for every part of the stack lives in a single control plane. Security teams write policy once, and auditors read the whole thing in one place. Business owners understand the decisions in plain language, and engineering no longer maintains inline permission checks scattered across every application.

2. Enforcement happens somewhere else entirely. Every runtime touchpoint runs its own decision, close to the code that actually does the work. It could be on an API gateway level, it could be on a microservice level, maybe on the Kubernetes stack on the infrastructure, or it could be on an applicative level, or in the database.

PlainID’s Agentic Identity Platform organizes the enforcement around four control points inside every agent interaction.

• First, the prompt itself. Block unauthorized questions before the agent processes them.
• Second, the data retrieval step. Filter data pre-retrieval based on the human and agent identity in play.
• Third, the tool invocation. Control which tools an agent can call, with the MCP Gateway intercepting each MCP call and enforcing policy in-flight.
• Fourth, the response. Mask sensitive fields before the answer leaves the agent’s execution path.

The threat surface underneath makes the four control points urgent. Ken Huang launched the OWASP Agentic Skills Top 10 project in Oslo earlier this year, and the first item on the list is malicious skills:

“The top vector is certainly the malicious skill, especially combined with the overprivileged identity. It can delete your email, it can delete your database, it can exfiltrate your sensitive data.” – Ken Huang

Runtime authorization that reaches every control point in the flow closes both halves of the equation at once.

The Policy Layer Needs Its Own Governance Model

Once policy runs the enterprise, the policy itself becomes a critical risk surface. But what happens if the policy definition is wrong, or does not cover a use case?

Let’s first look at a whitelist model that prohibits anything the policy does not explicitly permit. Deny by default cuts a large portion of the policy-gap risk before it ever materializes. Ambiguity always defaults to no.

We can also look at a policy lifecycle. Policies get the same treatment security teams give to critical code. Author, simulate, verify, review, approve, promote. Version control, rollback, and audit for every decision the policy engine makes.

This is wherePlainID’s Policy 360° sits. It gives security teams six views on every policy: Details, Rules, Code (with Rego editing), Native (vendor-specific formats), Audit (full decision trail), and Map (graphical decision paths across identity-to-asset relationships). Auditors, developers, engineering leads, and business owners each get a view that matches how they think.

The audit trail matters most when regulators ask. Authorization is also governance. Every decision produces evidence. When an incident happens, or when a supervisor comes asking, the trail is already there.

Map the Four Control Points Onto Your Agentic Pipeline

The gap between reading about runtime authorization and running it against your own production agent stack is where most enterprise programs stall. The webinar covered the model. The four control points, agent identity binding, multi-hop revalidation, and policy lifecycle are all live in PlainID production deployments today, including at Fortune 500 customers in banking, healthcare, telecom, and government.

The best way to test this model against your own agentic pipeline is to walk through it with the PlainID team. Bring your architecture, your active or planned MCP integration, and the constraints your board or regulator is putting on you. We’ll help you think through where the four control points fit, what runtime authorization looks like at your scale, and where other enterprise teams have started. Book a meeting with PlainID.

FAQs

Why don’t OAuth and OIDC work for autonomous AI agents?

The protocols assume a human clicks “approve” at consent time. They also issue coarse yes-or-no scopes and enforce them at login rather than at runtime. Autonomous agents run continuously and need fine-grained decisions based on identity and intent. They require enforcement at the moment of action. PlainID’s runtime authorization model addresses all three gaps.

What is the MAESTRO threat modeling framework?

MAESTRO stands for Multi-Agent Environment, Security, Threat, Risk, and Outcome. Ken Huang published it through the Cloud Security Alliance in February 2025 as a seven-layer reference architecture spanning foundation models to agent ecosystems. It surfaces cross-layer attack chains that traditional frameworks like STRIDE and PASTA cannot represent.

How does agent identity differ from human or service identity?

Agent identity carries essential attributes beyond a unique identifier: which model powers the agent, which framework it runs on, which tools it can invoke, and the behavioral scope it operates within. A change to any key attribute produces a different identity that requires re-provisioning. The framework rejects silent context switching.

What are the four control points in an agentic AI flow?

The four points are prompt input, data retrieval, tool invocation, and response generation. PlainID’s Agentic Identity Platform enforces authorization at each point, blocking unauthorized prompts, filtering data pre-retrieval, controlling MCP and native tool calls, and masking sensitive fields in the response. All four run against a single policy language.

What does centralized management, distributed enforcement mean in practice?

Policy authoring, governance, and lifecycle happen in one control plane. Enforcement happens close to the code that runs the workload, whether that is an API gateway, a microservice, a Kubernetes sidecar, an MCP gateway, or a database. Same policy across the stack, and the engine evaluates every decision at runtime with the local context it needs.

How does an MCP Gateway enforce authorization at tool-call time?

The MCP Gateway sits inline between the agent and the MCP tool. The Gateway intercepts every tool invocation before it executes. PlainID’s Gateway evaluates the request against the current policy using the agent identity, the human identity the agent acts for, the requested tool, and the runtime context, then approves, denies, or filters the call.

Why does the policy layer itself need lifecycle governance?

Once policy runs the enterprise, the policy becomes a critical risk surface. A gap in the policy is a gap in every enforcement point downstream. Policy 360° treats policies like production code: authoring, simulation, verification, approval, promotion, versioning, rollback, and full audit trail for every decision the engine makes.