Deterministic authorisation for AI agents is now a governance issue

At a glance

What this is: This is Ory's analysis of why AI agent authorisation must be deterministic and in-loop when vulnerability discovery becomes an API-driven action path.

Why it matters: It matters because IAM, PAM, and NHI programmes need to govern agent decisions as runtime identity events, not just authentication outcomes or static entitlements.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Ory's analysis of AI agent authorisation and deterministic policy

Context

AI agent identity is no longer a theoretical edge case when a model can trigger security-relevant actions through APIs. The governance gap is simple: many control planes still assume the actor requests access, while agentic systems can decide and execute within the same runtime loop.

In that environment, probabilistic classification is not the same as authorisation. Identity teams need to separate model output from policy decision, otherwise the organisation ends up delegating access control to a system that cannot explain or deterministically bound its own next move.

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 AI agents create a different authorisation problem from ordinary automation?

A: Ordinary automation follows predefined rules, so the access path is known before execution starts. AI agents can choose actions, tools, and timing within the session, which means least privilege has to hold during runtime, not just at provisioning. That changes authorisation from a static setup task into a live governance control.

Q: What breaks when a classifier is used as the approval layer for agent actions?

A: The organisation loses deterministic control. Classifiers are useful for triage, but they produce confidence scores, not enforceable authorisation decisions. If the approval layer is probabilistic, two identical requests can be treated differently, and the audit trail no longer proves that policy, not model output, governed the action.

Q: Who should be accountable for AI agent security incidents?

A: Accountability should sit with the team that owns the agent's business function and permission model, not with a single security tool owner. If the organisation cannot name who approved the agent's scope, who can revoke it, and who reviews runtime exceptions, the governance model is incomplete.

Technical breakdown

Deterministic authorisation for AI agents

Agent authorisation is the control layer that decides whether a runtime action may proceed. For agentic systems, that decision must be deterministic because the actor can choose tools, sequence actions, and time execution within the same session. A probabilistic classifier can help with risk scoring, but it cannot substitute for policy because policy must produce the same answer for the same inputs. In practice, that means authorisation has to be in-loop, context-aware, and tied to a stable policy engine rather than inferred from model confidence.

Practical implication: separate risk scoring from enforcement so the model never becomes the authoriser.

Why API-driven vulnerability discovery changes the identity model

When vulnerability discovery becomes an API call, the identity event is not just who logged in. The important question is which agent identity can invoke discovery, what tools it can chain, and what downstream permissions those tools inherit. That turns the agent into a governed executor, not a passive caller. If the policy layer cannot distinguish discovery, verification, and remediation actions, the system can over-expand privilege at runtime and blur the boundary between observation and execution.

Practical implication: classify each agent action path separately and bind each one to a distinct policy rule.

Probabilistic classifiers are useful signals, not control decisions

A probabilistic classifier can flag risk, rank intent, or detect suspicious combinations of prompts and tools. It cannot on its own prove that an action should be allowed, because confidence scores are not the same as authorisation logic. This matters most in AI agent governance, where the same session may contain discovery, retrieval, and execution in rapid succession. The control objective is not to predict what the agent might do. It is to decide what it may do with traceable, deterministic rules.

Practical implication: use classifiers for triage and monitoring, not for approve-or-deny decisions.

Threat narrative

Attacker objective: The objective is to convert a narrow discovery capability into broader security-relevant execution without a stable authorization boundary.

1. Entry occurs when an AI agent receives legitimate API access to a vulnerability discovery workflow and begins operating with delegated credentials.
2. Escalation occurs if the workflow lets the agent chain discovery into adjacent tools or permissions without deterministic policy gates between actions.
3. Impact occurs when the agent reaches actions that expose, alter, or trigger security-relevant state outside the intended scope of the original request.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Deterministic authorisation is now the baseline requirement for agentic identity. Once an AI system can decide its next action at runtime, a probabilistic layer is no longer enough to govern access. Identity control must answer the same inputs with the same decision every time, or the organisation has no enforceable boundary. The implication is that agent governance has moved from scoring behaviour to enforcing policy.

The NHI governance assumption that access decisions are externally initiated was built for non-autonomous systems. That assumption fails when the actor can initiate its own action sequence, because the identity no longer waits for a human or workflow prompt to define the next step. The implication is that least privilege cannot be reasoned about only at provisioning time once runtime choice enters the control path.

Agent authorisation should be treated as a separate control plane from model output. The article points to a failure mode that security teams already know from NHI sprawl: when execution and entitlement blur, policy drift follows. AI agent identity needs explicit boundaries for discovery, retrieval, and execution, not a single broad permission envelope. The implication is that governance teams must map action classes before they map prompts.

The named concept here is runtime authorisation drift. This is the gap between a model's changing runtime choices and a static policy assumption that one approval can cover the whole session. It is especially dangerous when vulnerability discovery becomes one API call among many, because the access surface expands faster than review cycles can react. The implication is that control design must follow session behaviour, not static role design.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why runtime controls cannot rely on development discipline alone.
• For a broader identity lens, see the State of Secrets in AppSec for how fragmentation and behaviour gaps combine into persistent exposure.

What this signals

Runtime authorisation drift: as more AI systems gain access to operational APIs, the governance problem shifts from who authenticated to what the actor is allowed to do next. Teams should expect policy engines, audit trails, and session boundaries to matter more than model quality alone.

The practical signal for practitioners is that AI agent governance will start to look closer to PAM and NHI lifecycle control than to traditional application security. The teams that can map action classes, policy decisions, and revocation paths will have the clearest control over autonomous execution.

With 43% of security professionals already worried that AI systems can learn and reproduce sensitive information patterns from codebases, the authorisation debate is no longer isolated to one workflow. It is becoming part of the broader identity stack, including secrets handling, role design, and runtime oversight.

For practitioners

• Separate risk scoring from enforcement Use classifiers to rank agent behaviour, then pass only deterministic policy decisions into the enforcement layer. Do not let model confidence become the approval signal for runtime access.
• Map agent actions to distinct policy rules Treat discovery, retrieval, verification, and remediation as different action classes with different permissions and audit expectations. Bind each class to a separate policy rule so one grant does not cover the whole chain.
• Review every AI agent for in-loop authorisation Check whether an agent can request, combine, and execute actions without a human or policy gate between steps. If it can, the current control model assumes a lower autonomy level than the system actually has.
• Log authorisation decisions as identity events Capture the exact policy decision, input context, and permitted action for each agent step. That audit trail is what lets IAM, PAM, and security teams prove the boundary later.
• Limit broad discovery privileges Avoid giving a single agent identity one permission set that covers searching, validating, and acting. Narrow the scope so discovery cannot silently expand into execution authority.

Key takeaways

• AI agent authorisation fails when probabilistic scoring is mistaken for deterministic policy enforcement.
• Runtime access decisions now matter more than static entitlements because agentic systems can chain actions within a session.
• Identity teams need separate controls for discovery, retrieval, and execution if they want auditable boundaries for autonomous behaviour.

Key terms

• Deterministic Authorization: Deterministic authorization means the same request, policy, and context always produce the same decision. That property matters because security teams need access controls they can reproduce during audits, investigations, and incident response. It is especially important when AI is involved upstream but not at the decision boundary.
• Agent Authorization: Agent authorization is the decision process that determines whether a software agent may take a specific action at runtime. It evaluates context, delegated authority, and resource sensitivity at the moment of execution, not only at login or provisioning time.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

What's in the full article

Ory's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact authorisation pattern Ory describes for agent actions inside the Ory Keto control model
• The practical distinction between probabilistic classification and deterministic policy enforcement in agent workflows
• Implementation context for agentic AI and MCP security that this analysis only frames at the governance level
• The product-level identity and permissions architecture behind Ory's approach to agent authorisation

👉 Ory's full post covers the control-model detail behind agent authorisation and policy enforcement.

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 or NHI governance programme, it is worth exploring.