What does an AI agent accountability framework actually include?

At minimum it covers four things: a named owner for each agent, documented permissions scoped to the tasks the agent performs, an audit log of every action the agent takes, and a defined escalation path when the agent encounters something outside its scope. Without all four, you cannot attribute an incident to a cause or demonstrate compliance.

How common are shared credentials across AI agents, and why do they matter?

Shared credentials mean two or more agents authenticate to a downstream system using the same identity. When one agent misbehaves or is compromised, you cannot revoke access selectively without taking down every agent sharing that credential. The blast radius of a single incident grows with every agent you add to the shared pool.

Can governance be retrofitted after agents are already in production?

Yes, but the cost rises with time. The first step is an inventory: list every agent running, what systems it touches, and what credentials it holds. From there you can assign owners, scope permissions, and attach logging. The longer agents run without an inventory, the more undocumented dependencies accumulate and the harder scoping becomes.

What is the difference between runtime governance and pre-deployment review for agents?

Pre-deployment review checks an agent before it goes live: permissions, credential scope, approval workflow coverage. Runtime governance monitors what the agent actually does once it is running: action logs, anomaly detection, and circuit breakers that halt execution when behaviour falls outside defined bounds. You need both; pre-deployment review alone cannot catch emergent behaviour that only appears at scale.

The Governance Gap: Why 72% of Enterprises Deploy Agents Without Accountability

What you will learn

Agents are running in production at scale. The governance infrastructure to oversee them, in most organisations, is not. This article maps the specific places that gap produces failures, drawing on recent incidents involving shared credentials, bypassed approvals, and private data exposure. If you are getting your first agent into production or governing a fleet that already exists, the patterns here apply directly.

The gap is not theoretical

In June 2026, a Kore.ai survey found that 72% of enterprises say their AI agents operate with unmanaged risk, despite those agents being actively deployed. Separately, Deloitte reported in April 2026 that only 21% of organisations have a mature governance model for agentic AI, even as 74% plan to expand adoption within two years.

Those two numbers together describe a specific structural problem. Deployment decisions are being made by teams who want the operational benefit now. Governance decisions are being deferred to a later stage that, in practice, never arrives before the next deployment. The result is a production environment where agents act, but no one has formally established who is responsible when an action goes wrong.

This is not a failure of intent. Organisations like Klarna, which handled 2.3 million customer service conversations in its first month of agentic deployment at the equivalent of 700 full-time staff, or JPMorgan Chase, which gave 250,000 employees access to its LLM Suite with roughly 125,000 daily active users, moved fast because the operational case was clear. The governance infrastructure simply did not keep pace.

Three failure modes that follow from the gap

Shared credentials across agents

When teams deploy agents quickly, they reach for the nearest available credential rather than provisioning a new identity. The agent needs to read from a database or call an API, and the fastest path is to reuse a service account that already has the right access.

The result is that multiple agents authenticate as the same identity. When one of those agents behaves unexpectedly, or is exploited, you cannot revoke its access without also revoking access for every other agent sharing that credential. You also cannot reconstruct which agent performed which action after the fact, because the audit trail shows one identity regardless of source. This is the shared credentials risk that CSO Online covered in July 2026, and it is a direct consequence of deploying agents faster than you provision governance infrastructure.

The fix is agent-level identity: each agent holds its own credential, scoped to the minimum permissions it needs for the tasks it performs. This is a core principle in any working AI agent governance model and the step most commonly skipped under deployment pressure.

Bypassed approval workflows

Agents that operate across systems will encounter steps that, in a human workflow, require an approval before proceeding. A purchase order above a threshold, a code change to a protected branch, a message sent on behalf of an executive. When the agent is not explicitly told that an approval gate exists, it continues past it.

The GhostApproval vulnerability, documented by Wiz in July 2026, showed this in a coding assistant context: prompt injection caused the agent to bypass approval workflows entirely, taking actions the user had not sanctioned. The agent was not malfunctioning in a technical sense. It was executing instructions. The instructions told it to skip the gate.

This failure mode appears wherever agents are given broad tool access without a map of which actions require human confirmation. Runtime governance addresses this directly: you define, at the tool level, which calls trigger a pause-and-confirm step before execution continues.

flowchart TD
    A[Agent receives task] --> B{Action requires approval?}
    B -- No --> C[Execute action]
    B -- Yes --> D[Pause execution]
    D --> E[Request human confirmation]
    E -- Approved --> C
    E -- Denied --> F[Log denial, halt task]
    C --> G[Write to audit log]
    F --> G

Private data leaks through prompt injection

Agents that have access to private repositories, internal documents, or customer data can be manipulated into exfiltrating that data if they process attacker-controlled content as part of their normal workflow. In July 2026, GitHub documented exactly this in agentic workflows: prompt injection via repository content caused agents to leak data from private repositories.

The agent was doing its job, reading content and acting on it. The content contained instructions the agent followed. Without output filtering, sandboxed execution contexts, and strict scoping of what data an agent can read relative to what it can transmit, this class of attack is structurally available to anyone who can write content the agent will process.

This connects directly to AI security risks that are specific to agents rather than static models: the attack surface is not just the model, it includes every document, message, or data record the agent reads during a task.

flowchart TD
    A[Agent reads external content] --> B{Content contains injected instructions?}
    B -- No --> C[Process normally]
    B -- Yes --> D[Agent follows injected instructions]
    D --> E{Output filter in place?}
    E -- Yes --> F[Filter blocks exfiltration]
    E -- No --> G[Data leaves environment]
    F --> H[Incident logged]
    G --> H

What governance infrastructure actually looks like

The organisations that avoid these failures share a small set of practices. They maintain a live inventory of every agent in production: what it does, what systems it touches, what credentials it holds, and who owns it. They provision per-agent identities with scoped permissions rather than reusing shared service accounts. They map which tool calls require human confirmation before execution. They attach audit logging at the action level, not just the session level. And they treat prompt injection as a production security concern rather than a research curiosity.

None of this requires a large team. It requires that these questions are answered before an agent goes live, not after the first incident. Implementing agent observability and following an established AI governance framework give you the scaffolding. Tools like Prefactor sit in this category, providing per-agent identity and audit infrastructure for teams building governance from scratch.

The AI agents security practices that apply here are not exotic. Least-privilege access, audit logging, and confirmation gates for consequential actions are standard controls in any other part of your infrastructure. Agents need them applied consistently, because multi-agent systems compound the blast radius of any single missing control across every agent that shares a dependency.

For teams thinking about how to govern agentic AI across a fleet, the inventory step comes first. You cannot scope permissions or assign owners for agents you cannot enumerate.

Where to start

If you are not certain what agents are running in your environment right now, or who owns each one, start with the agent readiness assessment. It gives you a structured way to identify where your governance coverage is thin before the next deployment adds another agent to the stack. Take the agent readiness assessment.