Agentic AI governance requires runtime control, not output review

At a glance

What this is: This is a framework for governing autonomous AI agents, with the key finding that action control must happen at runtime, at the identity and API boundary.

Why it matters: It matters because IAM, PAM, and governance teams need controls that contain agent actions, preserve accountability, and prevent delegated access from expanding beyond intended scope.

By the numbers:

• 98% have deployed or planning to deploy AI agents, but 79% of those organizations lack written policies for governing them.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Ory's guide to implementing agentic AI governance

Context

Agentic AI governance is the discipline of controlling what autonomous agents are allowed to do. The problem is not model quality alone. Once an agent can call APIs, move data, and trigger workflows, the governance question becomes who authorized each action and where that authorization is enforced.

Traditional AI oversight was built around output risk, review, and human judgment. Agentic AI governance sits inside the identity layer, where task scope, delegated authority, and runtime policy decide whether an action is permitted before the agent can complete it.

The article frames this as an operational identity problem, not a theoretical one. That is the right starting point for security teams because agent behaviour now overlaps with NHI governance, IAM, and PAM in the same control plane.

Key questions

Q: How should security teams implement runtime controls for AI agents in enterprise environments?

A: Start by enforcing policy at the point where the agent requests access, not only where the data lives. Bind each agent to a human owner, a defined task scope, and a limited set of downstream resources. Then log every decision so teams can trace when the agent exceeded scope or was blocked.

Q: Why do AI agents change IAM and PAM assumptions?

A: AI agents change IAM and PAM assumptions because they can act continuously, use tools directly, and execute without the human pacing that traditional review cycles expect. That makes static entitlements, delayed approvals, and post-hoc certification weaker controls. The programme has to govern runtime use, not just the assignment of access.

Q: What breaks when agents rely on shared credentials or borrowed user identities?

A: Auditability breaks first, followed by recertification and containment. Shared credentials make it difficult to prove which actor took which action, and borrowed identities let software inherit privileges that were never meant for autonomous use. That creates a governance gap where authentication succeeds but accountability fails.

Q: Who is accountable when an AI agent takes an unsafe action?

A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.

Technical breakdown

Agent identity and authentication for autonomous systems

An agent needs a unique identity because shared credentials destroy traceability and make revocation imprecise. In practice, this means treating each agent like a first-class machine identity with its own authentication material, lifecycle, and audit trail. OAuth 2.0 client credentials and OpenID Connect are common foundations because they let teams scope, rotate, and revoke access independently. The important point is not the protocol itself. It is that identity must map to one actor, one scope, and one revocation path.

Practical implication: issue separate identities per agent and eliminate shared credentials wherever multiple autonomous systems operate.

Runtime authorization at the API boundary

Agentic systems create risk when authorization lives outside the execution path. A policy in a wiki or a pre-deployment review cannot stop an agent from calling an unapproved API once runtime begins. That is why enforcement has to sit at the boundary, such as an identity-aware proxy or authorization layer in front of target services. Fine-grained authorization, including relationship-based access control, is what limits which resources the agent can touch and under what conditions. The control must survive a compromised or misbehaving agent.

Practical implication: enforce policy where the request is made, not after the fact in monitoring or documentation.

Continuous monitoring, kill switches, and agent drift

Agent governance is continuous because agent scope changes over time. As integrations expand and workflows accrete, the real access surface often outgrows the original approval set. That makes drift detection, logging, and immediate revocation central governance functions rather than optional telemetry. The article is right to treat the kill switch as a required control because irreversible actions can complete before a human reviewer intervenes. Audit trails matter, but only if they are paired with fast containment and a maintained inventory of what each agent can reach.

Practical implication: baseline agent behaviour, watch for scope drift, and keep revocation paths tested and available.

NHI Mgmt Group analysis

Agentic AI governance is a runtime authorization problem, not a model quality problem. Traditional AI governance controls output quality, bias, and review. Those controls do not stop an autonomous system from invoking an API, moving data, or triggering a workflow it was never authorized to use. The implication for practitioners is that governance must move to the action boundary, where identity and policy decide what the agent can do in real time.

First-class agent identity is the control that makes accountability possible. Shared or static credentials erase actor-level traceability, which means one compromised or misbehaving agent can contaminate the entire access model. Separate identities let teams revoke one actor without breaking the rest of the estate. That is a basic NHI governance requirement, and it becomes more urgent when autonomous behaviour can chain through multiple systems.

Runtime enforcement is the named concept this category now needs: policy that survives the agent. The article’s core lesson is that documentation and pre-launch approval are too far from execution to matter. Runtime enforcement at the API boundary is what preserves governance when the agent’s code, prompt, or orchestration changes mid-flight. Security teams should treat that as the dividing line between governance theatre and real control.

Autonomous action approval was designed for human-paced decision loops. That assumption fails when the actor can plan, select tools, and execute without human approval gates. The implication is not merely tighter control, but a rethinking of whether pre-authorized scope can still describe behaviour that evolves during execution.

Continuous governance is mandatory because agent permissions drift faster than review cycles. Agents accumulate integrations over time, which means their real access surface expands even when the original approval looks narrow on paper. Access reviews, recertification, and PAM governance need a live operational view of agent capability, not a periodic snapshot. Practitioners should assume the gap between approved and effective access will widen unless drift is actively monitored.

From our research:

• 98% have deployed or planning to deploy AI agents, but 79% of those organizations lack written policies for governing them, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, which shows how quickly deployment can outrun policy.
• For a broader control lens, see OWASP Top 10 for Agentic Applications 2026 for the runtime risks that policy must contain.

What this signals

Agentic AI governance will increasingly converge with NHI governance. Once an agent can act independently, the operational question is no longer only model safety. It becomes whether identity, authorization, and lifecycle controls can constrain machine action at runtime. Teams that already run mature NHI programmes will adapt faster because they understand scoped credentials, revocation, and traceability.

With 80% of organisations reporting that AI agents have already acted beyond intended scope in SailPoint’s research, the governance gap is no longer theoretical. That pattern points to a need for live inventory, drift detection, and revocation readiness across the agent estate.

The next control maturity step is not more documentation, but better runtime evidence. Practitioners should align agent governance with NIST AI Risk Management Framework thinking and use agent inventories, policy enforcement points, and audit trails as programme-level signals rather than isolated technical features.

For practitioners

• Define each agent’s delegated authority Document the exact tasks, tools, workflows, and autonomy level each agent is permitted to use before deployment. Scope must be specific enough that every action can be tested against it.
• Assign a unique identity to every agent Issue separate machine credentials per agent so traceability, revocation, and forensic review remain actor-specific. Never reuse the same identity across multiple autonomous systems.
• Enforce policy at the API boundary Place authorization controls in an identity-aware proxy or equivalent enforcement layer that sits in front of services the agent calls. Do not rely on the agent to self-limit.
• Set explicit human escalation thresholds Route irreversible or high-impact actions to human review based on impact and reversibility, especially for payments, external communications, and sensitive data access.
• Test kill-switch and revocation paths Verify that you can immediately revoke an agent’s access and stop execution without waiting for a workflow to complete. Include this in incident-response exercises.

Key takeaways

• Agentic AI governance is fundamentally about controlling actions, not reviewing outputs, so identity and authorization must move into the runtime path.
• Shared credentials and delayed review cycles cannot provide accountability for autonomous systems that can chain APIs, workflows, and data access in real time.
• Practitioners need unique identities, boundary enforcement, and immediate revocation paths before autonomous agents scale further inside the enterprise.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• 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.
• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• AI Agent Drift: AI agent drift is when an agent diverges from the authorised plan it was supposed to follow. The agent may not be compromised or malicious, but its actions no longer match the intended workflow, which creates governance, compliance, and operational risk in production environments.

What's in the full article

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

• The five-pillar implementation model with more detail on identity, policy, oversight, and monitoring choices
• Examples of runtime authorization patterns for agents calling APIs and handling sensitive actions
• The article’s discussion of Ory Hydra, Keto, and related identity components in the governance stack
• The standards references and product-specific implementation guidance that support the framework

👉 The full Ory article covers the implementation sequence, control layers, and standards context in more detail.

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 responsible for identity security strategy or governance maturity, it is worth exploring.