AI agent governance exposes the gap between policy and runtime control

At a glance

What this is: Akto’s analysis says AI agent governance is shifting from reviewing outputs to controlling delegated action, because agents can execute tool chains and trigger consequences at machine speed.

Why it matters: That matters to IAM, PAM, and NHI teams because the control point moves from what an AI says to what it is allowed to do, when, and under whose authority.

Context

AI agent governance is the problem of controlling what an agent is permitted to do in production, not just what it is allowed to say. Traditional AI governance assumed a human stayed in the loop long enough to review outputs, but agents can now chain API calls, touch sensitive systems, and create side effects before review can happen.

The identity implication is direct: once an agent acts through service accounts, machine identities, or delegated API permissions, governance becomes an access and accountability problem as much as an AI problem. Akto’s article frames that shift clearly, and it is typical of the wider market gap between policy-led oversight and runtime control.

Key questions

Q: What breaks when agentic AI governance stops at policy approval?

A: Approval-only governance fails because it assumes the important risk is launch-time permission, when the real exposure happens during runtime decisions. Once an agent can act, adapt, and delegate, the organisation needs controls that constrain behaviour, record actions, and prove compliance after each task, not just a green status box at sign-off.

Q: How should SMEs choose an identity and access management approach that fits a limited budget without weakening security?

A: SMEs should start with core controls that address their highest risks, then expand as needs grow. Prioritise cloud-based IAM with subscription pricing, single sign-on, multi-factor authentication, user lifecycle management, and access control. These capabilities reduce upfront infrastructure cost, improve user experience, and support compliance without forcing a large custom implementation or unnecessary feature spend.

Q: How do security teams know if agent governance is actually working?

A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent. If any of those answers require manual reconstruction, governance exists on paper but not in operations.

Q: Should organisations separate agent permission checks from human approval checks?

A: Yes. Base permission checks decide whether the agent is allowed to attempt the action at all, while human approval decides whether a sensitive but permitted action should proceed. Mixing those layers creates false trust and makes it harder to explain why an action was allowed, denied, or expired.

Technical breakdown

Why policy-only governance fails for agentic systems

Policy-only governance breaks when the system being governed can make decisions and take actions between review checkpoints. In agentic environments, the control surface is no longer just model outputs, but tool invocation, API access, session scope, and task sequencing. That means a policy can look sound on paper while the runtime path still permits chained actions that exceed intended authority. The failure mode is timing as much as permission. If the control exists only before deployment or after an incident, it misses the moment when the agent actually acts. That is why governance must be embedded where the action occurs.

Practical implication: move governance checks into the execution path, not just the approval workflow.

How delegated authority becomes an identity problem

An agent that acts through credentials is effectively operating as a non-human identity, even if the business treats it as a tool. The moment it uses service accounts, tokens, or scoped API permissions, its risk profile depends on credential lifecycle, authorization boundaries, and revocation speed. This is why agent governance overlaps with IAM and NHI control: the question is not whether the model is smart, but whether the identity it uses can be constrained to the exact task. Without that bridge, oversight remains abstract while the agent has real access.

Practical implication: treat every production agent as an identity-bearing workload with explicit issuance, scope, and offboarding.

What runtime controls actually govern agent behaviour

Runtime controls govern the agent while it is acting, not after the fact. That includes monitoring prompts, tool use, API calls, memory access, and execution patterns, then applying dynamic policies, progressive rollout, kill switches, and rollback paths when behaviour drifts. The architecture matters because agent risk is often cumulative: one permitted action may be harmless, but a chain of permitted actions can produce an irreversible outcome. Continuous observability alone is not enough unless it is paired with enforcement. Governance becomes practical only when the system can block, pause, or narrow authority in the same runtime window in which the agent is operating.

Practical implication: couple observability with enforcement so anomalous agent behaviour can be stopped mid-task.

Threat narrative

Attacker objective: The objective is to induce an agent to perform unauthorized actions through trusted permissions and delegated access, creating business impact without needing direct human compromise.

1. Entry occurs when an AI agent is deployed with broad tool access or outside approved governance channels, giving it a legitimate path into enterprise systems.
2. Credential and authority abuse follow when the agent uses service accounts, tokens, or API permissions that exceed the task boundary and can be exercised without human review.
3. Impact emerges when chained actions, mis-scoped APIs, or prompt manipulation trigger unauthorized changes, data exposure, or irreversible downstream effects.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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

Policy-led AI governance is already insufficient for agentic systems. The article captures a real governance gap: traditional AI programmes were built to review outputs, not to control actions taken through tools, APIs, and delegated identities. Once an agent can act faster than human review, governance must move into runtime enforcement and lifecycle control. The practitioner conclusion is straightforward: policy without execution control is documentation, not governance.

AI agents become an identity problem the moment they act through credentials. A service account, token, or machine identity used by an agent is not just a technical detail, it is the governance boundary. This is where IAM, PAM, and NHI discipline meets AI security: scope, revocation, and auditability matter more than the label attached to the system. Practitioners should govern agents as identity-bearing workloads, not as passive software features.

Runtime control is the missing layer in agent governance architectures. The article’s strongest point is that visibility alone does not stop unauthorized action. Monitoring prompts and tool calls helps, but only if paired with enforcement mechanisms such as dynamic policy checks, kill switches, and rollback. That is the difference between observing agent behaviour and actually governing it. The practitioner conclusion is to design for intervention at the point of action, not after the damage is done.

Agent boundaries should be designed as blast-radius controls, not trust assumptions. The governance model has to assume that one agent decision may cascade into several system changes, because that is how agentic workflows behave. That shifts the centre of gravity from approval paperwork to constrained execution paths and task-scoped privilege. Practitioners should treat containment as the primary design goal, especially where agents can modify records, send communications, or trigger transactions.

Auditability must cover decisions, not just events. The article correctly emphasizes logs and lineage, but the deeper governance issue is whether a team can explain why an agent was allowed to act at all. That requires separating approval, execution, and accountability across different roles and records. In practice, if the organisation cannot reconstruct both the authorising decision and the runtime action, the governance model is incomplete.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

AI agent governance is becoming an identity governance problem with AI characteristics, not the other way around. The operational question is no longer whether the model is allowed to answer, but whether the agent is allowed to act through a scoped credential, and whether that credential can be revoked as quickly as it was issued. Security teams should expect governance pressure to move toward identity-bound runtime control, especially where agents touch APIs, records, or transactions.

Governance maturity will be measured by containment, not documentation volume. A policy library cannot stop a mis-scoped agent from chaining tool calls if enforcement only happens at the edges. Programmes that can detect drift, pause execution, and narrow privilege in real time will have materially better control over agentic risk than programmes focused mainly on pre-deployment review.

For practitioners

• Define runtime approval boundaries for every agent Specify which actions require human confirmation, which are pre-approved, and which are prohibited before the agent is deployed into production workflows.
• Inventory agent identities and credentials Track every service account, token, API key, and delegated permission used by production agents, then bind each one to a named owner and task scope.
• Add continuous monitoring for tool and API usage Watch prompt activity, tool calls, memory access, and outbound API requests so anomalous behaviour can be detected before it becomes a larger incident.
• Implement kill switches and rollback paths Give operators a way to stop agent execution or revert generated changes when behaviour drifts, permissions are abused, or downstream effects become unsafe.
• Separate approval from execution Use different approvers, reviewers, and operators for consequential agent actions so no single actor can both authorise and carry out the same change.

Key takeaways

• AI agent governance fails when teams treat policy as sufficient and ignore the runtime window in which agents can act.
• The central control problem is identity-bound authority, because agents increasingly operate through service accounts, tokens, and API permissions.
• Practical governance depends on live enforcement, auditability, and blast-radius reduction, not on output review alone.

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 control: Controls that enforce policy while an AI system is operating, rather than after the fact. For healthcare chatbots, runtime control includes data masking, output filtering, access scoping, and immutable logging so the organisation can defend the interaction itself.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Blast Radius Control: Blast radius control is the practice of limiting how far damage can spread when an identity, system, or workload is compromised. It uses segmentation, least privilege, isolation, and scoped credentials to contain impact. In identity security, it reduces lateral movement, privilege escalation, and data exposure after a breach or misuse.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, IAM, and secrets management. It helps security and identity practitioners translate governance intent into controls that work at runtime.