AI agent fleet governance: why per-agent controls break down at scale

What an agent fleet actually is

An agent fleet is not one AI assistant with a chat window.

It is tens, hundreds, or (per Gartner's forecast that the average global Fortune 500 enterprise will run more than 150,000 agents by 2028, up from around 15 in 2025) eventually thousands of autonomous processes, spread across hosts, cloud accounts, and teams, each holding its own credentials, calling its own tools, and taking its own actions without a human reviewing every step (Gartner, "Gartner Identifies Six Steps to Manage Artificial Intelligence Agent Sprawl," April 2026).

The fleet framing matters because it is a different management problem to "does this one agent behave correctly." A fleet has a population that changes weekly, ownership that gets lost as teams reorganise, and a blast radius that is the sum of every agent's permissions, not any single agent's.

Cloud Security Alliance research puts the non-human identity to human identity ratio at 45:1 on average and as high as 144:1 in cloud-native environments, with 51% of organisations reporting no clear ownership of their AI identities (Cloud Security Alliance, "The Non-Human Identity Governance Vacuum," 2026). That is the fleet, whether or not anyone has decided to manage it as one.

Why per-agent governance does not scale

Most organisations still govern agents the way they governed the first one: a human reviews its prompt, checks its tool list, and signs off. That works for agent one. It does not work for agent one thousand, for four structural reasons.

Identity sprawl. Only 22% of teams treat agents as independent identities; the rest still rely on shared API keys and service accounts (Gravitee, "State of AI Agent Security Report 2026"). When agents share credentials, you cannot tell which agent did what, so per-agent review is fiction from the start, there is no "per-agent" to review.

Credential reuse and over-privileging. CSA's whitepaper found that one in twenty non-human identities carries full administrative privileges, and 47% of AI-related credentials had not been reviewed or rotated in over a year.

Separately, 70% of organisations grant AI systems more access than they would give a human doing the same job, and systems with least-privileged access showed a 17% incident rate against 76% for over-privileged ones (Cloud Security Alliance, 2026; nhimg.org summary of CSA's State of Non-Human Identity Security survey, 2026). A one-off manual review at deployment does not catch privilege that accumulates afterwards.

Policy drift. Rules set at an agent's launch do not stay enforced as the agent is modified, redeployed, or copied into a new pipeline by someone who never saw the original review.

GitGuardian's 2026 State of Secrets Sprawl report recorded AI-service-related secret leaks rising 81% year over year to over 1.27 million exposed secrets, with eight of the ten fastest-growing leak categories tied to AI infrastructure, orchestration layers, RAG pipelines, vector stores, that did not exist when the original controls were written (GitGuardian, "The State of Secrets Sprawl 2026," blog.gitguardian.com).

Point-in-time review cannot keep pace with infrastructure that is added continuously.

No aggregate evidence. Even where individual agents are reasonably governed, most organisations cannot answer fleet-level questions: which agents touched a given system last month, which credentials are still live, which agent caused an incident.

Only 19.7% of organisations say all their agents are fully secured and governed before going live (Gravitee, 2026), and 88% report a confirmed or suspected AI agent security incident in the past year (same report). Sixteen percent of organisations do not even track the creation of new AI-related identities (Cloud Security Alliance, 2026).

Per-agent sign-off produces per-agent paperwork, not fleet-wide evidence, so when an incident happens the honest answer to "show me what every agent with this permission did" is often that nobody knows.

OWASP's Top 10 for Agentic Applications for 2026 names this directly as ASI03, Identity and Privilege Abuse: agents inherit credentials such as user sessions, API keys, and OAuth tokens, and attackers exploit trust and delegation chains to escalate access or execute unauthorised actions through that inherited credential (OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications for 2026").

NIST's own risk framework, built around Govern, Map, Measure, and Manage, was written for a single AI system's lifecycle and extended for generative AI risks in NIST AI 600-1; it does not, on its own, give you a mechanism for treating a fleet as a population with aggregate state (NIST, "AI Risk Management Framework," nist.gov/itl/ai-risk-management-framework).

What fleet-level governance actually requires

Scaling from per-agent review to fleet governance means shifting from "did we check this agent" to "can the fleet, as a whole, prove what happened and stop what is happening." That requires five things working together, not any one of them alone.

Per-agent identity, not shared credentials. Every agent needs its own identity, distinct from any human's and from any other agent's, so that an action in a log traces to exactly one accountable principal. CSA recommends a centralised registry recording each agent's identity, owning team, business purpose, accessed systems, and privilege scope (CSA, 2026). Without this, "which agent did that" is unanswerable.

Scoped, time-limited credentials. CSA's recommendation is zero standing privilege: just-in-time access scoped to a specific task, with credential lifetimes measured in hours for ephemeral agents and days or weeks even for persistent ones, automatically revoked on expiry (CSA, 2026). This bounds the damage of any single leaked or misused credential instead of relying on nobody misusing a permanent one.

Central policy with local enforcement. Policy needs to be written and updated in one place but enforced at the point where each agent actually acts, so a rule change reaches every agent immediately rather than only the ones someone remembers to re-review. CSA frames this as attribute-based access control evaluating the agent's current task context at request time, not a static permission set fixed at deployment (CSA, 2026).

A fleet-wide kill switch. More than a third of organisations admit they could not shut down a rogue AI agent today (TechTarget, "Why businesses need an AI agent kill switch," 2026).

A credible kill switch is layered, not a single button: session termination, scoped permission revocation, circuit breakers on spend or action rate, and full deactivation, operating outside the agent's own reasoning loop so a misbehaving agent cannot reason its way past its own shutdown (TechTarget, 2026).

It has to work at the fleet level, revoking a class of agents or a shared credential at once, not one agent at a time.

Aggregate audit evidence. The fleet needs to produce evidence as a byproduct of operation, not as a special exercise after something goes wrong: who did what, under which credential, approved by whom, retrievable across the whole population rather than reconstructed agent by agent.

CSA's target for revocation is minutes, not hours, and that timeline is only achievable if the evidence needed to decide "revoke this" already exists in aggregate form when the question is asked (CSA, 2026).

How to evaluate a fleet governance solution

When assessing a product or approach against this, ask specifically:

• Does every agent get a distinct, non-shared identity by default, or is that an opt-in feature bolted on later?
• Are credentials scoped and time-bound, or does the product manage long-lived keys more conveniently without shortening their life?
• Is policy enforced locally, at the point of action, or only checked centrally in a way an agent can bypass by acting directly against a downstream system?
• Can you revoke access for a class of agents (a team, a credential, a task type) in one action, and how long does that revocation take to take effect everywhere?
• Can you produce, without manual reconstruction, a record of every action a given agent (or every agent with a given permission) took over a stated period, verifiable independently of the vendor's own dashboard?

Vendor demos tend to show the last of these as a nice dashboard. The harder and more telling question is whether the underlying evidence is tamper-evident and checkable by a party other than the platform that generated it, because a governance record that only the governed system can vouch for is not independent evidence.

Where Quox fits

This is the same reframe our own AI governance hub argues for and our enterprise page builds: govern AI agents at scale, not one agent at a time. Quox's approach to this problem is built around four protocols, filed as individual IETF Internet-Drafts (not standards, and without IETF endorsement; the current drafts expire 4 March 2027 unless refreshed): AEE, AOCL, VOLT, and WARD.

AEE (Agent Envelope Exchange) establishes message causality between agents, so an action can be traced back through the chain of messages that led to it.

AOCL (Agent Orchestration Control Layers) is a control and audit stack modelled on OSI-style layering; its gates hold actions for named human approval before they execute, which is one concrete answer to the "central policy, local enforcement" requirement above, the same policy gate every agent in an estate inherits from day one.

VOLT (Verifiable Operations Ledger & Trace) produces evidence bundles for agent actions that verify offline, meaning a bundle can be checked without a live connection back to the platform that issued it. WARD (Write-once Append-only Receipt Digests) publishes signed hash-chain tips to external witnesses, so the audit trail's integrity does not depend solely on the platform's own say-so.

Taken together, these give a fleet operator per-agent traceability (AEE), a mechanism for human-in-the-loop control over specific action classes (AOCL), portable and independently verifiable evidence (VOLT), and externally witnessed tamper evidence (WARD). None of this is a certification or a standard; it is a specific set of mechanisms, currently documented as expiring drafts, aimed squarely at the aggregate-evidence and local-enforcement gaps described above.