Four questions every CISO will be asked about AI agents in 2026

Boards, auditors, regulators, and customers have started asking one question out loud. When an AI agent takes an action inside your environment, who is accountable, what authority did it have, and can you prove it?

That single question splits into four. By the end of 2026, every CISO at a meaningful enterprise will be asked all four. Most cannot answer them today.

1. Who authorized this agent to operate in our environment at all?
2. On whose behalf is the agent acting right now?
3. What is the smallest privilege this agent needs for the task in front of it?
4. Can we prove what the agent actually did, after the fact?

None of the four are MCP questions, OAuth questions, or model questions. They are governance questions about any piece of software acting on a human's behalf at machine speed. Whether the agent reaches your systems through MCP, a vendor SDK, a browser extension, a custom LangChain pipeline, a scripted RPA bot, or a direct LLM API call, the four questions are the same. If you cannot answer them, the protocol underneath does not save you.

Question 1. Who authorized this agent to operate in our environment?

Not who installed it. Not who clicked Allow All on an OAuth prompt nine months ago. Who, inside your organization, made the explicit decision that this agent, with these scopes, for this purpose, until this date, should be operating inside your systems.

The Vercel breach answered the version of this question that nobody wants to answer in a deposition. An individual employee, on their own, connected a consumer AI extension to their Google Workspace. No procurement review. No security review. No identity team in the loop. The agent's access was approved, just not by anyone who would have approved it if asked.

For most enterprises today, an answer to this question requires a multi-week project across IT, identity, security, and procurement. By 2026 it has to be a query.

Question 2. On whose behalf is the agent acting right now?

This question has the sharpest edge because most environments cannot answer it at all.

When an AI agent makes a call into your CRM, your code repository, your data warehouse, or your finance system, who is the human accountable for that specific action? Not the human who set up the integration last spring. The human whose intent this action is meant to represent, in this moment.

If your audit log says “the agent did it,” you do not have an answer. You have a blank space where accountability is supposed to live. When the regulator, the auditor, or the plaintiff's counsel asks who authorized the action, the agent is not a legally meaningful party. The human behind the agent is.

The technical name for this is on-behalf-of semantics. The business name is accountability. They are the same thing, and most environments do not produce either.

Question 3. What is the smallest privilege this agent needs for the task in front of it?

Not what scopes you granted it. For the specific task the agent is performing in this specific second, what is the minimum access required to complete it, and is that what the agent is actually carrying?

The honest answer for most organizations is that the agent is carrying everything it was ever granted, for every task it will ever perform, for the entire life of the integration. The credential was granted once and has been reused on every call since. The agent walks into a finance query with the same authority it walked into a calendar lookup. The Mexico Claude Code campaign exploited this exact failure mode at machine speed across multiple government systems.

Least privilege used to be a policy ideal. In the agent era it is a runtime requirement.

Question 4. Can we prove what the agent actually did, after the fact?

Every breach response, every audit, every regulatory inquiry, every customer escalation eventually arrives at the same question. Show me what happened. For human identities, organizations have spent twenty years building the machinery to answer it. SIEM pipelines, IdP logs, access reviews, forensic timelines.

For AI agents, that machinery does not yet exist in most environments.

Agents operate at machine speed across many systems, often through composite calls that chain through gateways, MCP servers, vendor APIs, and downstream services. A single user request can fan out into hundreds of downstream actions, each one attributed to the agent. When the incident review starts, the question is not whether the agent did something bad. The question is which action, by which agent, on behalf of which human, at what moment, with what authority.

If your environment cannot reconstruct that chain in minutes, you are operating an agent estate you cannot defend in front of anyone who matters.

Why AI agent governance matters in 2026

These four questions are not invented. They are the questions that the last twelve months of AI-adjacent incidents have already forced into the open. The pattern is consistent across very different agent types.

The OpenAI Atlas browser agent demonstrated what happens when the AI you deploy turns into a shadow identity on your network, with no agent-aware audit trail. The Vercel breach showed the same gap in reverse, when an AI tool your vendor deploys becomes the door an attacker walks through. The Mexico Claude Code campaign showed what an attacker does when machine-speed agents meet identities that hold persistent, broad, unsegmented privilege. The OpenClaw and Moltbook exposures showed that consumer AI agents installed by employees produce the same blast radius without anyone calling it a breach yet.

Different agent architectures. Different protocols. The same four questions, unanswered.

The structural cause is the same in every case. The identity stack most enterprises run was built for human users. One human, one credential, one session, one audit log. Agents shatter every one of those assumptions, regardless of whether they reach your systems through MCP, OAuth, a browser, a custom integration, or a vendor SDK. The vocabulary of “user logged in, user clicked, user saved” does not survive contact with a multi-hop agent chain.

What identity and security leaders should do this week

• Pick the three highest-privilege AI agents in your environment, regardless of how they connect. MCP servers, browser extensions, LLM API integrations, vendor copilots, custom agents. For each one, write down the answer to all four questions on a single page. If you cannot, that is your first finding.
• Look at any AI integration that holds long-lived, broadly-scoped credentials of any kind into your IdP, code host, data platform, or collaboration suite. Long-lived plus broad-scoped is the failure mode every recent agent-adjacent incident has exploited. Force re-consent, narrow scopes, or rotate to short-lived credentials wherever you can.
• Talk to your auditors and your legal team this quarter, not next year, about what they will need from you when an agent-mediated incident happens. The conversation is easier to have before the incident than after.
• Stop treating AI agents as software. Software has a vendor and a contract. Agents have an identity, an actor, and a chain of action. The governance model has to match what the thing actually is.

Frequently asked questions

What is AI agent governance?

AI agent governance is the practice of treating AI agents as identities, not as software, and applying the same controls every other identity in the enterprise carries. Authorization, on-behalf-of semantics, least privilege at the task level, and a defensible audit trail. It applies to any agent acting on a human's behalf, whether the agent uses MCP, OAuth, custom APIs, browser automation, or any other protocol.

Who is accountable when an AI agent takes an action?

The human on whose behalf the agent was acting. Legally, regulatorily, and operationally, an agent is not a meaningful party. Accountability runs to the human whose intent the action was meant to represent. The job of the identity layer is to make that link verifiable in the audit trail at the moment of the call, not reconstructable weeks later.

How do you govern AI agents that do not use MCP or OAuth?

The same way. The four questions (who authorized it, on whose behalf, with what privilege, can we prove it) are independent of the wire protocol the agent uses. Whether the agent uses a vendor SDK, a browser extension, a direct LLM API call, an RPA framework, or a custom pipeline, governance has to enforce the same answers. The mechanism changes. The questions do not.

The bigger pattern

Every named AI-adjacent incident of the last year has surfaced the same underlying gap. The model was not the problem. The prompt was not the problem. The identity the AI was operating under, and whether anyone could answer the four questions about it, was the problem every time.

By the end of 2026, every CISO at every meaningfully complex enterprise will be asked those four questions by someone who is not optional to answer. We have spent the last several months building the answer. More on that soon.

‍