Four questions every CISO will face on AI agent governance

At a glance

What this is: This is an analysis of why AI agents create identity governance gaps, centring on four questions about authorization, on-behalf-of accountability, least privilege, and audit proof.

Why it matters: It matters because IAM, PAM, and governance teams must be able to govern agent behaviour as an identity problem, not treat it as ordinary software integration.

👉 Read Oleria Security's analysis of the four AI agent governance questions CISOs will face

Context

AI agent governance is the discipline of controlling what an agent is allowed to do, on whose behalf it acts, and how that action is evidenced after the fact. The article argues that existing identity programmes are failing because they were built around human users, not entities that operate at machine speed across many systems.

That gap affects both NHI governance and human accountability models. When an agent is connected through MCP, OAuth, browser automation, or a vendor SDK, the protocol changes but the governance questions do not. The article says enterprises need a queryable answer set, not a multi-week investigation, before agent usage can be considered governable.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What breaks when AI agent access is reviewed only after the fact?

A: After-the-fact review leaves a gap between action and containment. If an agent can already reach a dataset, API, or SaaS system, the damage may be done before a human sees the alert. Runtime checks reduce that gap by stopping unauthorized actions before they execute.

Q: Who is accountable when an AI agent makes a risky decision?

A: Accountability should rest with the organisation that authorised the agent, the human owner of the workflow, and the control process that allowed the behaviour. If an agent can act independently, the programme must preserve attribution, action logs, and policy decisions so audit and remediation are possible after the event.

Technical breakdown

Why AI agent identity breaks human-centric audit models

Traditional IAM assumes a stable relationship between a person, a session, and an audit record. AI agents do not fit that pattern cleanly because they can act repeatedly, across systems, with actions that chain through tool calls and downstream services. The resulting log trail can say an agent acted, but not necessarily who it represented, what scope it held at the moment, or whether the privilege matched the task. That is an identity governance problem, not a logging problem. The important shift is from post-event reconstruction to runtime accountability.

Practical implication: treat agent identity as a governable subject with explicit attribution requirements, not as an integration detail.

On-behalf-of semantics and least privilege for AI agents

On-behalf-of semantics means the system can prove which human intent an agent action represented at the moment of execution. Without that link, accountability collapses into a vague system-level record that does not satisfy audit, legal, or operational needs. The same applies to least privilege. For AI agents, least privilege cannot be a one-time provisioning decision if the agent keeps using broad scopes indefinitely. Privilege has to be assessed at task level, because a single agent can move from low-risk lookup work to high-risk data or finance actions within the same integration.

Practical implication: require task-scoped privilege and provable human attribution for every material agent action.

Why protocol choice does not solve agent governance

MCP, OAuth, direct APIs, browser extensions, custom pipelines, and vendor SDKs are all transport layers. They may change the mechanics of how an agent reaches a resource, but they do not change the core governance challenge. If the organisation cannot answer who authorized the agent, what it may access, and what it actually did, the protocol underneath is irrelevant. This is why agent governance sits above the integration layer. Security teams need controls that can evaluate the identity, authority, and evidence chain regardless of the route the agent takes.

Practical implication: build protocol-agnostic policy and evidence controls that apply consistently across all agent entry points.

Threat narrative

Attacker objective: The objective is to operate through an AI agent in a way that expands access and obscures responsibility, making the resulting action hard to challenge or reconstruct.

1. entry: The agent enters through a legitimate integration path such as MCP, OAuth, a browser extension, or a direct API connection, which gives it access that appears sanctioned.
2. escalation: The agent retains broad or long-lived privilege beyond the immediate task, allowing it to perform actions outside the narrow intent of the original authorisation.
3. impact: The organisation is left with an incomplete audit trail and ambiguous accountability, which weakens incident response, legal defensibility, and governance oversight.

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

Identity governance for AI agents fails when organisations keep treating them as software. Software can be inventoried by vendor and contract, but an agent needs an authority model, an accountability chain, and an evidence trail. Once an agent can act on behalf of a human across multiple systems, the governance unit is no longer the tool. The governance unit is the actor. Practitioners should reframe agent onboarding as identity lifecycle management, not application procurement.

On-behalf-of attribution is the real control boundary for agentic access. The article is right to force the question of who the agent represented at the moment of action, because that is where auditability either exists or fails. A log that says the agent did it is not a control, it is an admission that accountability was not encoded. This is where human IAM, PAM, and NHI governance intersect. The practical implication is that AI agent action must be attributable at execution time, not reconstructed after the incident.

Least privilege becomes a runtime condition when the actor can take autonomous actions at machine speed. The old assumption that access can be reviewed after provisioning was built for human-paced change, not for rapid tool-chaining and repeated calls. That assumption fails when the actor can keep operating with the same scopes across unrelated tasks. The implication is that privilege governance for agents needs task-bound scope, not static approval.

Protocol diversity does not change the governance problem, which is why MCP is not the control plane. Whether the agent reaches the environment through MCP, OAuth, browser automation, or a custom pipeline, the same four questions remain. The article correctly surfaces a broader identity lesson: transport security and identity governance are separate layers. Practitioners should stop looking for a protocol fix to a governance failure.

AI agent sprawl will force boards to ask for evidence, not reassurance. The decisive issue is whether the organisation can prove who authorized the agent, what authority it had, and what it did. That requirement will move agent governance from an engineering concern to a board-level accountability issue. Security leaders should assume these questions will be asked during the next audit or incident review.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap reinforces why readers should also use the Ultimate Guide to NHIs for lifecycle and governance context.

What this signals

Agent governance will force identity teams to move from periodic review to continuous evidence generation. If an AI agent can make several decisions inside one session, a quarterly access review is no longer a meaningful control boundary. The organisation needs evidence that is bound to the action itself, not just the asset inventory, and that shifts identity governance closer to runtime policy enforcement than traditional recertification.

On-behalf-of attribution will become a programme requirement, not a logging enhancement. Once boards and auditors ask who the agent represented, the answer has to be machine-readable and operationally enforceable. That is a governance design problem that spans IAM, PAM, and NHI lifecycle processes, and it should be aligned with the identity lifecycle guidance in the Ultimate Guide to NHIs.

The practical signal to watch is whether your environment can produce an actor, authority, and action chain in minutes rather than days. If it cannot, then your AI agent estate is already bigger than your current identity controls can explain.

For practitioners

• Inventory every production AI agent as an identity subject Record who approved it, what systems it can reach, what human it represents, and when that approval expires. If the answer requires a project instead of a query, the governance model is already behind the environment.
• Enforce task-scoped privilege for agent actions Replace standing broad scopes with short-lived, purpose-bound access for the exact operation the agent is performing. Review privilege at the call level, not only at onboarding, so low-risk and high-risk tasks do not share the same authority.
• Make on-behalf-of attribution mandatory in logs Require every material agent action to carry a human accountability reference that can survive audit, legal review, and incident response. If the audit trail cannot tie the action to a person or approved role, the control failed.
• Standardise governance across all agent entry points Apply the same identity and audit requirements to MCP, OAuth, browser extensions, vendor SDKs, direct APIs, and RPA-style automations. Protocol choice should not change the control model.

Key takeaways

• AI agents are now an identity governance issue, not just an integration issue, because they act across systems on behalf of humans.
• The hardest control gap is accountability: organisations must prove who authorised the agent, what it represented, and what it actually did.
• Identity teams should move to task-scoped privilege, explicit attribution, and protocol-agnostic governance before agent sprawl outpaces auditability.

Key terms

• On-behalf-of semantics: The rule that an AI agent's action must be tied to the human or approved role it represents at the moment of execution. For autonomous or semi-autonomous systems, this is the bridge between authorisation and accountability, and without it the audit trail cannot support operational or legal review.
• Session-scoped privilege: Access that exists only for the current task or execution window and is removed when the session ends. For autonomous or agentic systems, this reduces standing privilege but also shifts the burden to runtime controls, because the identity may not persist long enough for traditional review cycles.
• Agent subject identity: A non-human principal that exists in the directory under its own identity, lifecycle, and audit trail. For autonomous systems, this is the governance model that allows independent revocation, clear attribution, and least privilege without pretending the human operator is always the real actor.

What's in the full article

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

• The full breakdown of the four governance questions CISOs will be asked about AI agents in 2026.
• The incident examples behind agent-authorisation failures, including the Vercel case and related AI-adjacent exposures.
• The practical framing for accountability, on-behalf-of semantics, and auditability across common agent entry points.
• The source article's discussion of how boards, auditors, regulators, and customers are already changing expectations.

👉 The full Oleria Security post covers the Vercel example, the audit problem, and the governance questions in more depth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity controls for modern enterprise environments, it is worth exploring.