Identity-layer control and runtime authorization for agentic systems

At a glance

What this is: NHI Mgmt Group's analysis, drawing on EnforceAuth's blog post: Separating agent identity governance from runtime action authorization shows why the two decisions are not interchangeable for AI agents.

Why it matters: IAM, IGA, and PAM teams need this distinction because agentic systems can be properly identified and still execute actions that violate business policy at runtime.

Context

Agentic systems create a control gap because identity approval and action approval are not the same decision. In practice, one layer decides which identities may reach tools, connectors, and resources, while another must decide whether a specific action should execute against live state and business rules.

That distinction matters most for AI agents because they operate at machine speed, carry delegated authority, and can trigger actions whose legitimacy depends on request semantics and current state. For identity and access programmes, this is a governance boundary, not a product feature debate.

The article frames the question as complementary control planes rather than a single authorisation stack. That is the right lens for teams trying to separate directory-backed access governance from per-action enforcement in agentic environments.

Key questions

Q: How should security teams separate AI agent access control from runtime action authorization?

A: Treat them as two different control planes. Access control decides whether an identity may reach a tool, connector, or resource. Runtime action authorization decides whether the specific operation, with its arguments and current state, should execute now. If you collapse the two, you can certify access correctly and still allow unsafe actions.

Q: Why do agentic systems need more than role-based access control?

A: Role-based access control is too coarse when the actor can choose actions at runtime. Agentic systems need enforcement at the tool layer and again at the data layer, because a role alone does not explain which action the agent will take or which resource it will touch next.

Q: What are the signs that identity governance is being asked to do runtime enforcement work?

A: A common sign is when audit evidence shows who authorised an agent and what it could access, but nothing shows whether the specific action was allowed at execution time. Another signal is repeated reliance on static scopes to control state-sensitive operations such as transfers, cross-tenant reads, or approval-dependent writes. That is a control boundary problem, not a logging problem.

Q: What should organisations do when a valid agent identity can still trigger an invalid business action?

A: They should keep the identity layer for reachability and attribution, then place a separate policy decision in the execution path for the business rule itself. The key question is not whether the identity is authenticated, but whether the specific action is acceptable in context. If the answer depends on live state, identity controls alone are insufficient.

Technical breakdown

Identity-layer authorization vs runtime action authorization

Identity-layer authorization answers whether an identity may reach a tool, connector, or resource. Runtime action authorization answers whether a specific operation, with these arguments and against this live state, should be allowed to execute right now. The two checks can both run per request, but they evaluate different decision objects. One is about reachability and attribution. The other is about action semantics, policy-as-code, and current system context. Treating them as the same control creates false confidence because a valid session or scoped token does not prove the business action is legitimate.

Practical implication: Map access governance to reachability and add a separate runtime policy decision for each high-risk action path.

Delegated authority and the agent decision boundary

Agentic systems inherit authority from humans, but inherited access does not define what the agent should do in a given transaction. That is why delegated identity controls, token issuance, and object relationships can be correct while the attempted action is still wrong. At runtime, the decisive inputs include request arguments, delegation chain, tenant context, and live application state. This is the boundary where identity-layer checks stop expressing enough semantics to judge whether a transfer, write, or cross-tenant read is acceptable.

Practical implication: Separate who is allowed to act from what that actor is allowed to do in a specific transaction.

Decision evidence vs attribution evidence

Identity platforms produce attribution evidence, which proves who authorized the agent, what it was allowed to reach, and which scopes were granted. Runtime authorization platforms produce decision evidence, which records the precise action, the policy version used, and the allow, deny, or step-up outcome. Both matter, but they answer different audit questions. Attribution evidence supports accountability. Decision evidence supports compliance with the actual business rule. In agentic environments, losing the second layer means audit logs can show access without showing whether the action should have happened.

Practical implication: Design audit trails so investigators can reconstruct both authorization of access and authorization of action.

Breaches seen in the wild

• Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic authorisation now requires two distinct control planes: identity-layer governance answers reachability, while runtime authorization answers execution legitimacy. Those are different computations with different inputs, and teams that collapse them into one control create a blind spot around live business state. The practitioner implication is that agent governance must be designed as layered decisioning, not as a single entitlement check.

Least privilege is no longer fully expressible at provisioning time: that assumption was designed for identities whose safe use could be bounded by static scope and object relationships. It fails when an agent's action must be judged against live transaction context, tenant state, and request semantics at the moment of execution. The implication is that least privilege for agents has to be rethought as dynamic decision scope, not just static access scope.

Attribution and enforcement are being asked to do different jobs: attribution evidence tells you who approved the agent and what it could reach, but it does not determine whether the act itself was permissible. This creates a governance gap for boards and auditors if they assume access certification covers runtime misuse. The implication is that identity governance, PAM, and policy enforcement must be evaluated as complementary, not substitutable, controls.

Runtime policy becomes the decisive control when agents interact with live state: action semantics, delegation chain, and current system state are the factors that separate a legitimate request from a prohibited one. Directory-centric controls cannot express every business predicate that matters in agentic workflows. The implication is that control owners need to define where reachability ends and executable business policy begins.

Decision-object design is the new architecture question: an authorisation stack should declare whether its unit of control is an identity, an object relationship, or an action with arguments. That naming discipline matters because it determines what can be enforced, audited, and explained. The practitioner implication is to stop measuring agent security by login-time checks alone and start mapping the exact decision object each control can truly govern.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

Decision-object clarity will become a core architecture skill: teams need to state explicitly whether a control governs identity reachability, object relationships, or the action itself. Without that distinction, agent governance collapses into a single access gate that cannot express live business rules.

Runtime policy will matter more as agents move closer to transaction systems: the closer an agent gets to payments, records, and production data, the less useful static entitlements become as the final word. The governance question shifts from who is allowed in to what is allowed to happen now.

Attribution is necessary but not sufficient: proving who authorised an agent does not prove the action was legitimate. Programmes that stop at attribution evidence will still miss the decision moment that matters most for agentic risk.

For practitioners

• Define the decision object for each agent workflow Document whether the control point governs tool reachability, object relationships, or the action itself. Use that boundary to prevent identity approvals from being mistaken for runtime business approval.
• Separate delegation checks from execution checks Keep directory, token, and ownership controls in the identity layer, then add a distinct policy decision for request arguments, live state, and transaction rules.
• Instrument decision evidence for high-risk actions Record the policy version, input context, and allow or deny outcome for transfers, writes, and cross-tenant operations so auditors can see the runtime verdict.
• Review where identity-layer controls stop expressing business policy Identify workflows where a valid identity, valid token, and valid scope still permit an action that the business would reject, then mark those paths for runtime enforcement.

Key takeaways

• Agentic security cannot rely on a single authorisation layer because reachability and execution are different control problems.
• Identity governance can prove ownership and access scope, but runtime policy is still needed to judge the legitimacy of a live action.
• The practical control boundary is the decision object, not the login event, and that boundary has to be explicit.

Key terms

• Decision Object: The unit a policy engine evaluates before allowing an action to proceed. In agentic systems, that object may be a tool, a record, a transaction, or the action itself with its arguments, which is why access and execution decisions cannot be collapsed into one control.
• Runtime Action Authorization: Authorization performed at the moment a request is executed, using live context rather than only pre-issued scopes or directory state. For agentic systems, this means evaluating the operation, parameters, tenant state, approvals, and business rules before the action completes.
• Attribution: Attribution is the ability to prove which identity performed a specific action, through which systems, and with what outcome. In agentic environments, attribution must span APIs, services, and workflow steps, because isolated logs are rarely enough to reconstruct decision chains or support audit and incident response.
• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.