Seven Questions Every Enterprise Should Be Able to Answer About Their AI Agents - And Why 86% Can’t Answer Even One.

The 2026 CISO AI Risk Report surveyed 235 large-enterprise security leaders and found that 86% do not enforce access policies for AI identities.

Not 86% who haven’t gotten around to it yet. 86% who have thought about it, assessed their infrastructure, and found that enforcing access policies for AI agents is something their current stack cannot do.

That finding is the context for the seven questions that follow. They are not trick questions. They are not advanced security questions that only mature programs can answer. They are the baseline questions that every enterprise deploying AI agents in consequential workflows should be able to answer - today, for any agent in their environment, within an hour.

Most enterprises cannot answer any of them. That is not a criticism. It is a description of where the governance infrastructure market actually is. And it is the starting point for understanding what needs to be built.

Question 1: What AI agents are actually running in your environment right now?

Not what was approved. Not what IT provisioned. What is actually running.

The gap between the approved list and the actual list is one of the most consistent findings across enterprise AI security research. Only 14.4% of AI agents go live with full security and IT approval. The other 85.6% are deployed by employees solving problems, SaaS vendors enabling new features, or engineering teams moving fast. They exist in your environment regardless of whether your governance program knows about them.

You cannot govern what you have not found. This question comes first because everything else depends on it. An incomplete inventory is not a partial governance program. It is a governance program with unknown blind spots that cannot be quantified, remediated, or audited.

What answering it requires: discovery infrastructure that finds agents without depending on self-registration. The baseline should have visibility into local AI activity combined with connector-based integration across your existing security stack. Not a one-time scan. A continuously updated inventory of every agent that actually exists.

Question 2: What is each agent allowed to do - and how was that decision made?

Every agent in your environment has an effective permission scope. The question is whether that scope was deliberately defined or inherited by default.

The most common authorization approaches for enterprise AI agents both result in overpermissioning: granting the agent the human user’s full standing access, or giving agents persistent long-lived access without session-level scoping. Both give agents more access than they need for any specific task. Neither requires anyone to make a deliberate decision about what the agent should actually be allowed to do.

“51% of organizations cite over-permissioned access as a top NHI pain point, and 78% have no documented policy for creating or removing AI identities.” If there is no documented policy for creating an agent identity, there is almost certainly no deliberate decision about what that identity should be permitted to access.

What answering it requires: organizational intent capture - a structured definition of what each agent was built to do, what systems it should reach, what data it should handle, and what actions it is authorized to take. A machine-readable, role-based definition that becomes the authorization baseline for every governance decision that follows.

Question 3: When this agent delegates to another agent - who is still accountable?

This is the chain accountability question. And it is the one that most governance programs have no answer to.

In a single-agent deployment, accountability is straightforward: the agent has an owner, and the owner is responsible for what the agent does. But enterprise AI deployments are rarely single-agent. A supervisor agent delegates to a worker agent, which invokes a sub-agent, which accesses a sensitive system. At each hop, the original human authorization context degrades.

By the time an action executes at hop three, the human whose authority started the chain may have no idea their authorization has traveled this far. The action is technically within the delegated permissions. The human accountable for it has been entirely abstracted from the transaction.

Existing governance programs assign accountability at provisioning time: this agent is owned by this person. What they cannot tell you is whether that accountability holds when the agent is three hops into a chain nobody explicitly designed.

What answering it requires: cross-chain authorization integrity - a traceable record that travels with the chain from its point of origin, ensuring that every action can be mapped back to the human authorization that permitted it, regardless of how many delegation hops occurred in between.

Question 4: What data did the agent access - and should it have?

This question has two distinct parts that most audit trails conflate.

The first part - what data did the agent access - is a logging question. Most security tools can answer it, at least partially.

The second part - should it have accessed that data - is a governance question. It requires knowing not just what the agent accessed, but whether that access was consistent with the agent’s organizational intent and the specific task it was executing in that session.

An agent with permission to access financial data that queries the HR system is doing something its logs will record. Whether it should have done it, whether that query was consistent with what the agent was built to do, is a question the log cannot answer without context.

This matters because overpermissioned agents routinely access data they are technically permitted to access but were never intended to reach. The access is logged. The permission is valid. The governance violation is invisible to any audit that looks only at permissions.

What answering it requires: data access evaluation against organizational intent, not just permission validation but intent consistency evaluation that assesses whether the data being accessed aligns with the agent’s defined purpose and the context of the current session.

Question 5: What evidence exists that this agent operated within its authorized boundaries?

This is the audit and compliance question. It is the one that most enterprises are least prepared to answer when a regulator, an auditor, or a board asks.

Most enterprise AI deployments produce logs. Logs tell you what happened. They do not, on their own, prove that what happened was authorized. Proving authorization requires a traceable record from every agent action back to the human authorization that permitted it - across every delegation hop in a multi-agent chain, maintained in tamper-evident form.

The EU AI Act requires documented decision-making and clear lines of accountability. FINRA’s 2026 oversight requirements demand human checkpoints for agents that can act or transact. The Zylos Research buyer-side governance analysis found that kill switch requirements and agent termination windows are now headline items in enterprise RFPs; buyers require the ability to stop a production agent in under five minutes, and agents with transaction authority in under one minute.

None of these requirements can be satisfied with standard log files. They require purpose-built accountability infrastructure: tamper-evident audit trails that capture not just what the agent did, but what it believed it was authorized to do, in what context, and whether that behavior was consistent with the intent baseline established at provisioning.

What answering it requires: immutable audit trails structured for compliance - capturing prompts, tool calls, data accessed, tokens consumed, and behavioral context in a format that answers the accountability question, not just the activity question.

Question 6: Who owns the governance process - and what happens when they disagree?

This question exposes the most common organizational failure mode in enterprise AI governance.

When CISO, Legal, Compliance, HR, and business units all own a piece of AI governance, no one owns enforcement. In many organizations, AI governance exists on paper but not in practice, and risk accumulates in the gaps between teams.

The CISO is responsible for security risk. Legal controls contracting language. Compliance defines regulatory requirements. HR writes acceptable use policies. Business units own the workflows agents run. In most enterprises, none of these stakeholders has a clear mandate to own the governance of an agent that touches all five domains simultaneously.

The accountability gap is not just technical. It is organizational. And it is why governance programs that look complete on paper fail in production, because when an agent’s behavior raises a question, there is no clear owner to answer it.

The organizational ownership model - every agent has a documented human owner accountable for its behavior - is the right starting point. What remains genuinely unsolved is the enforcement layer: when an agent’s behavior raises a governance question, what mechanism ensures the right human sees it, acts on it, and is held accountable for the outcome? Most enterprises have defined the ownership. Few have built the enforcement infrastructure that makes that ownership meaningful in real time.

Question 7: Can you stop this agent in under 60 seconds if something goes wrong?

This is the question that has moved from nice-to-have to headline requirement in enterprise AI procurement.

The Zylos Research buyer-side governance analysis found that kill-switch and emergency-stop capabilities are now standard items in enterprise RFPs, with buyers specifying termination windows under five minutes for production agents and under one minute for agents with transaction authority. ServiceNow added agent kill switches to its AI Control Tower in May 2026 in response to exactly this requirement.

The question is not just “can you turn the agent off.” It is: can you stop it cleanly, without leaving dependent workflows in inconsistent states, without losing the behavioral context needed for the subsequent investigation, and fast enough to contain the blast radius of whatever triggered the stop?

For most enterprises, the honest answer is: we cannot do it quickly, risk-free, and with full forensic preservation simultaneously.

At a foundational level, a system that enables the accountable human to receive and respond to real-time alerts - giving the agent owner visibility into behavioral deviations before they produce outcomes nobody authorized.

But the more complete answer goes further. A Guardian Agent kill-switch and quarantine capability that stops the agent independently of the agent itself - not waiting for a human to manually intervene - while preserving the full behavioral trail needed for forensic reconstruction. Critically, this containment has to be precise rather than blunt: mapping dependent workflows before execution so that stopping one agent doesn’t silently break the downstream processes that depend on it.

The difference matters. A kill switch that terminates an agent mid-workflow without understanding its dependencies can turn a governance intervention into an operational incident. Real containment is surgical - stopping what needs to stop, preserving what needs to be investigated, and leaving everything else running.

My Assessment

Seven questions. All of them baseline requirements for governing AI agents in consequential enterprise workflows.

86% of large-enterprise security leaders do not enforce access policies for AI identities. Most cannot answer questions two, four, or five. 92% lack full visibility into their AI identities, which means most cannot fully answer question one. And the organizational ownership question, question six, is unresolved in the majority of organizations that have thought carefully about it.

This is not an indictment of the security leaders asking these questions. It is a description of where the infrastructure market actually is. The tools built for human identity and machine credentials were not designed to answer these questions for AI agents. The frameworks built for traditional access governance were not built for identities that reason, adapt, and operate autonomously.

Seven questions. None of them advanced. All of them baseline requirements for governing AI agents in consequential enterprise workflows.

But here is what organizations deploying AI agents at scale have figured out that those still running pilots haven’t: Answering these seven questions is not the cost of governing AI agents. It is the unlock for deploying them.

Every question answered is a constraint removed. Every gap closed is a workflow an agent can be trusted with that it couldn’t be trusted with before. Enterprises that can answer all seven can build, test, and deploy agents at scale, because they have the visibility, accountability, and containment capability that make expanding agent scope a confident decision rather than a risky one.

Seven questions. The ones that can answer them deploy with confidence. The ones that can’t keep running pilots.

Chen Pipek is CPO and Co-Founder of aizome, an Enterprise AI Agent Identity Fabric Platform. He previously co-founded and led AxoniusX within Axonius and has held product and security leadership positions for over 20 years.