The question no one is asking yet
When a security incident involves a human employee, the investigation follows a well-established path. Access logs show which systems the employee accessed. Change management records show what modifications were approved. Authentication records show when and from where the employee logged in. The CISO can reconstruct a timeline, identify the scope of impact, and present findings to the board with confidence.
When a security incident involves an AI agent, the same investigation hits an immediate obstacle. There is no single, authoritative record of what the agent did. The agent's actions are distributed across LLM provider logs (which may be controlled by a third party), tool invocation records in various downstream systems, application-level telemetry, and whatever custom logging the development team chose to implement. Each of these sources captures a partial view. None of them is authoritative. None of them was designed to serve as evidence.
This is the blind spot. Most organisations deploying AI agents have instrumented them for observability, the ability to monitor performance, debug failures, and understand behaviour. Very few have instrumented them for accountability, the ability to prove what the agent did, in what order, under whose authority, with evidence that would satisfy an auditor or a regulator.
The CISO is the person who will be asked to explain the difference.
Why is this a governance gap and not a logging gap?
The instinct when confronted with this problem is to add more logging. Instrument the agent more thoroughly. Capture every LLM call, every tool invocation, every intermediate decision. Aggregate it all in a centralised logging platform and build dashboards.
More logging does not close the gap. The gap is structural. A system of record is the authoritative source for a specific category of data, the source that is canonical, contemporaneous, tamper-evident, and complete. When there is a discrepancy between the system of record and any other source, the system of record wins. Logs, however comprehensive, do not meet this standard.
Logs are written asynchronously. There is a window between the action and the log entry in which the action exists without a record. Logs can be rotated, truncated, or overwritten by retention policies. Logs from different systems may use different timestamp sources, making causal ordering ambiguous. And critically, most logging infrastructure provides no cryptographic guarantee that the records have not been modified since creation.
An auditor examining a log-based reconstruction of agent activity will ask reasonable questions. How do you know this log entry corresponds to this action? How do you know no log entries were lost during aggregation? How do you know the timestamps are synchronised across systems? How do you know the logs have not been altered? The honest answer, for most agent deployments, is that you do not know. You believe it is accurate. Belief is not evidence.
The governance gap is the distance between "we can probably reconstruct what happened" and "we can prove what happened." Every organisation deploying agents into production systems exists somewhere on that spectrum. The CISO's job is to know where.
The accountability question for agent actions
When an agent modifies a production system, three questions arise simultaneously. What did the agent do? Under whose authority did it act? Was the action within the scope of that authority?
Traditional security infrastructure answers the first question reasonably well, through observability tooling and log aggregation. It answers the second question poorly, because the delegation of authority from human to agent is typically implicit (embedded in service account permissions provisioned at deployment time) rather than explicit (recorded as a verifiable delegation chain for each action). It does not answer the third question at all, because evaluating whether an action was within scope requires knowing what the scope was, which requires a record of the authority grant that most systems do not maintain.
This is the gap that keeps the CISO up at night, or should. An agent with a broadly provisioned service account can perform any action within its role's permissions. If it performs an action that is technically permitted but operationally inappropriate, the organisation has no record showing that the specific action was within the intended scope of delegation. The permissions allowed it. The audit trail (if one exists) shows it happened. But no record connects the action to a specific human decision to authorise that specific category of action.
The audit trail problem and the authority problem are two faces of the same governance gap. Without an authoritative record of actions, you cannot prove what happened. Without an explicit record of delegated authority, you cannot prove it was authorised. Without both, you have agents acting in production without accountability.
What regulators will ask
The EU AI Act introduces specific obligations for high-risk AI systems, including requirements for logging, traceability, and human oversight. SOC 2 Type II requires organisations to demonstrate that they maintain controls over system access and changes. ISO 27001 requires an information security management system that includes access control, audit logging, and accountability measures.
Each of these frameworks will be interpreted and applied to agent systems as deployments scale. The specific requirements vary, but the common thread is clear: the organisation must be able to demonstrate that it maintained authoritative records of consequential actions, that it controlled access to systems through appropriate mechanisms, and that it can attribute actions to specific actors under specific grants of authority.
The CISO who says "we have comprehensive observability" will be asked to demonstrate that observability constitutes an authoritative record. The CISO who says "we control agent permissions through IAM" will be asked to demonstrate that the permissions granted were appropriate for the specific actions taken, not just that the role had sufficient privileges. The CISO who says "we can reconstruct the timeline" will be asked why the record needed to be reconstructed rather than retrieved.
These are the standard questions that auditors ask about any system that modifies production data. The only difference is that the actor is an agent rather than a human, and the existing infrastructure was not designed for that distinction.
What closing the gap requires
Closing the governance gap for agent systems requires three structural capabilities that most deployments currently lack.
The first is a system of record for agent actions, an authoritative, contemporaneous, immutable record of what each agent did, with cryptographic integrity guarantees. This record must be created at execution time, as part of the execution, with no asynchronous gap between action and record. Covia's Grid creates this record as a first-class product of every agent execution.
The second is explicit, verifiable delegation of authority. When an agent acts, the record must include not just what it did but under whose authority it acted, with a cryptographic proof chain connecting the action to a human decision. This is what scoped authority mechanisms like UCAN tokens provide: a verifiable chain from the human who authorised the action, through any intermediate delegation, to the agent that performed it.
The third is runtime policy enforcement, the ability to evaluate governance rules before the agent acts. If the governance check happens after the action, the check is diagnostic rather than preventive. Enterprise deployments require governance that prevents violations.
The conversation the CISO needs to have
The typical agent deployment today follows a pattern. An AI team builds an agent, provisions it with a service account, instruments it with logging, deploys it to production, and monitors it through dashboards. The security team reviews the architecture, ensures the service account permissions are reasonable, and approves the deployment. Everyone moves on.
The conversation that needs to happen, and usually does not, is about the gap between what the security infrastructure captures and what an auditor will require. The logging captures events. The auditor will require evidence. The IAM controls capture permissions. The auditor will require authority chains. The monitoring captures anomalies. The auditor will require proof of policy enforcement.
This conversation is uncomfortable because it exposes the fact that the organisation's agent governance posture, regardless of how sophisticated its observability stack, may not survive an audit. The agents are already acting in production. The governance infrastructure has not caught up. And the person who will be asked to account for that gap is the CISO.
The question is whether this conversation happens proactively, while there is time to close the gap, or reactively, after an incident makes the gap visible to everyone outside the security team.