The agent sprawl problem

In January, a mid-size fintech company discovered that an autonomous agent deployed by their marketing team had been scraping competitor pricing data, storing it in an unencrypted S3 bucket, and feeding it into a report that was shared with three external partners. The agent had been running for four months. Nobody in security knew it existed.

This isn't an edge case. It's the new normal.

Gartner projects that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. A LangChain survey of 1,300 professionals found that 78% of organisations have agent pilots running, but only 14% have reached production scale with proper governance. The gap between those two numbers is where the risk lives.

What agent sprawl actually means

Shadow IT was the problem of the 2010s: employees signing up for SaaS tools without IT approval, creating data silos, compliance gaps, and security blind spots. Agent sprawl is the 2026 version, and it's worse.

The difference is agency. A SaaS tool stores data. An agent acts on data. It reads your database, calls your APIs, sends emails, modifies records, and makes decisions, all at machine speed, with whatever permissions its creator happened to give it.

“

Shadow IT was about access. Agent sprawl is about execution. When an unmanaged tool leaks data, you have a breach. When an unmanaged agent acts on data, you have an incident you might not discover for months.

The anatomy of sprawl

Notice the core shift: the exact same agent capabilities become far safer when identity, routing, and action boundaries are centralized instead of inherited ad hoc.

We've audited agent deployments at four companies in the past six months. The pattern is remarkably consistent.

Why traditional security fails

Enterprise security teams have spent two decades building frameworks for managing human access to systems. Identity and Access Management (IAM), role-based access control (RBAC), single sign-on (SSO), multi-factor authentication (MFA). These frameworks assume a fundamental property: the entity being governed is a person who authenticates, makes decisions at human speed, and can be held accountable.

Agents break every one of these assumptions.

// Traditional IAM: a human authenticates

const user = await auth.verify(credentials);

// user.id → traceable to a person

// user.permissions → reviewed quarterly

// user.actions → logged at human-comprehensible velocity

// Agent "IAM": what actually happens today

const agent = new Agent({

// Who is this agent? A string someone typed.

name: "marketing-pricing-bot",

// Whose permissions does it use? The person who deployed it.

credentials: process.env.JANES_API_KEY,

// What can it do? Everything Jane can do.

permissions: "inherited",

// Who reviews its actions? Nobody.

monitoring: undefined,

});

NIST's Centre for AI Standards and Innovation (CAISI) launched an agent-specific standards initiative in February 2026, identifying three fundamental gaps in traditional identity management:

1. Binding: agents need identities linked to the humans who authorised them, establishing a chain of accountability.
2. Scoping: agents need task-bound, time-limited permissions, not the broad persistent access their creators have.
3. Verification: systems that receive requests from agents need mechanisms to verify the authenticity of the authorisation behind each action.

The governance architecture

After helping four companies recover from sprawl incidents, we've converged on an architecture with four layers. Each layer addresses a distinct failure mode.

Layer 1: The agent registry

You cannot govern what you cannot see. The first requirement is a centralised inventory of every agent operating in your environment.

interface AgentRegistration {

id: string;                  // Unique, immutable identifier

name: string;                // Human-readable name

owner: string;               // Person accountable for this agent

department: string;          // Organisational unit

purpose: string;             // What this agent does, in plain language

model: string;               // Which LLM it uses

tools: ToolPermission[];     // Every tool it can access

dataSources: DataSource[];   // Every data source it reads from

writeTargets: WriteTarget[]; // Every system it can modify

schedule: Schedule;          // When it runs (continuous, cron, triggered)

createdAt: Date;

lastAuditedAt: Date;

status: "active" | "suspended" | "decommissioned";

}

interface ToolPermission {

toolId: string;

operations: ("read" | "write" | "delete")[];

rateLimit: number;           // Max invocations per minute

dataClassification: "public" | "internal" | "confidential" | "restricted";

}

The registry isn't a spreadsheet. It's an API that enforces registration at deployment time. If an agent isn't registered, it doesn't get credentials. If its registration expires, its credentials are revoked automatically.

Layer 2: Scoped identity

Every agent gets its own identity, separate from its creator. This identity has permissions scoped to exactly what the agent needs (and nothing more) with time-bound access that requires periodic renewal.

interface AgentIdentity {

agentId: string;

// Who authorised this agent to exist

authorisedBy: string;

// When the authorisation expires

expiresAt: Date;

// Permissions are task-specific, not role-based

permissions: TaskPermission[];

}

interface TaskPermission {

resource: string;        // e.g., "crm.contacts"

actions: string[];       // e.g., ["read", "update"]

conditions: Condition[]; // e.g., only contacts in the agent's assigned region

maxActionsPerHour: number;

requiresApproval: boolean; // Human-in-the-loop for high-risk actions

}

// At runtime: every tool call is validated against permissions

async function executeToolCall(

agent: AgentIdentity,

tool: string,

action: string,

params: unknown

): Promise<ToolResult> {

// Check: is this agent allowed to use this tool?

const permission = agent.permissions.find(

  p => p.resource === tool && p.actions.includes(action)

);

if (!permission) {

  audit.log("denied", { agentId: agent.agentId, tool, action });

  throw new PermissionDenied(agent.agentId, tool, action);

}

// Check: has the agent exceeded its rate limit?

if (await rateLimiter.isExceeded(agent.agentId, tool)) {

  audit.log("rate_limited", { agentId: agent.agentId, tool });

  throw new RateLimitExceeded(agent.agentId, tool);

}

// Check: does this action require human approval?

if (permission.requiresApproval) {

  await requestHumanApproval(agent.agentId, tool, action, params);

}

// Execute and log

const result = await tools.execute(tool, action, params);

audit.log("executed", { agentId: agent.agentId, tool, action, params });

return result;

}

Layer 3: Real-time observability

Every action an agent takes is logged to an immutable audit trail with enough context to reconstruct the full decision chain after the fact. This isn't optional instrumentation. It's a governance primitive.

interface AgentAuditEvent {

// Identity

traceId: string;

agentId: string;

authorisedBy: string;

// Action

timestamp: Date;

action: "tool_call" | "decision" | "data_read" | "data_write" | "escalation";

tool?: string;

input: SanitisedInput;  // PII stripped, but semantically complete

output: SanitisedOutput;

// Context

reasoning?: string;     // Why the agent chose this action

confidence?: number;    // Model's self-reported confidence

alternatives?: string[]; // What other actions were considered

// Governance

permissionUsed: string;

dataClassification: string;

piiDetected: boolean;

anomalyScore: number;   // Statistical deviation from normal behaviour

}

The anomaly detection layer is critical. It monitors patterns like: an agent that normally makes 50 API calls per day suddenly making 5,000. An agent accessing a data source it has never touched before. An agent's error rate spiking from 2% to 40%. These patterns trigger automatic suspension and human review before damage compounds.

Layer 4: The kill switch

Every agent must be instantly suspendable. Not "suspendable after a deploy" or "suspendable after someone finds the right Kubernetes pod." Instantly. One API call. The agent stops, in-flight actions are cancelled where possible, and all credentials are revoked.

// Governance dashboard action

async function suspendAgent(

agentId: string,

reason: string,

suspendedBy: string

): Promise<SuspensionResult> {

// 1. Revoke all credentials immediately

await credentialStore.revokeAll(agentId);

// 2. Cancel in-flight actions where possible

const inflight = await actionQueue.getInFlight(agentId);

const cancelled = await Promise.allSettled(

  inflight.map(action => action.cancel())

);

// 3. Update registry

await registry.updateStatus(agentId, "suspended");

// 4. Notify stakeholders

await notify.send({

  to: [registry.getOwner(agentId), "security-team"],

  subject: `Agent ${agentId} suspended`,

  body: `Reason: ${reason}. Suspended by: ${suspendedBy}.`,

  severity: "high",

});

// 5. Immutable audit log

audit.log("agent_suspended", {

  agentId,

  reason,

  suspendedBy,

  inflightCancelled: cancelled.length,

  timestamp: new Date(),

});

return { agentId, status: "suspended", cancelledActions: cancelled.length };

}

The coordination problem

There's a failure mode that no amount of individual agent governance solves: conflicting agents. When two agents with overlapping scopes operate on the same data, they can produce contradictory outcomes without either agent doing anything individually wrong.

Takeaway: local correctness is not system correctness. Two individually valid agents can still create destructive loops without a global conflict policy.

The solution is an explicit coordination layer: a registry of which agents can act on which resources, with built-in conflict detection.

interface ResourceClaim {

agentId: string;

resource: string;

operations: string[];

priority: number;             // Higher wins in conflicts

conflictStrategy: "block" | "queue" | "escalate";

}

function detectConflicts(

claims: ResourceClaim[]

): Conflict[] {

const conflicts: Conflict[] = [];

for (let i = 0; i < claims.length; i++) {

  for (let j = i + 1; j < claims.length; j++) {

    const a = claims[i];

    const b = claims[j];

    if (

      a.resource === b.resource &&

      a.operations.some(op => b.operations.includes(op))

    ) {

      conflicts.push({

        agents: [a.agentId, b.agentId],

        resource: a.resource,

        overlappingOps: a.operations.filter(

          op => b.operations.includes(op)

        ),

        resolution: a.priority !== b.priority

          ? "priority"

          : "requires_human_review",

      });

    }

  }

}

return conflicts;

}

The governance checklist

If you're shipping your first 10 agents to production, here is the minimum viable governance surface:

The chart above shows the percentage of sprawl incidents that each layer would have prevented, based on our analysis of 31 incidents across four companies. The registry alone prevents the majority of problems because most sprawl incidents stem from agents that nobody knew about.

The uncomfortable truth

Agent sprawl isn't a technology problem. It's an organisational problem. The technology for governance exists today: registries, scoped credentials, audit trails, anomaly detection. The challenge is that governance feels like friction, and the teams deploying agents are optimising for speed.

The companies that get this right treat agent governance the way they treat cloud governance. Not as a gate that blocks deployment, but as a platform that makes deployment safe and auditable by default. You don't ask developers to "remember to log things." You give them infrastructure that logs everything automatically.

“

The goal isn't to slow down agent adoption. It's to make ungoverned agents the harder path. When the governed path is faster and more reliable than the ungoverned path, sprawl fixes itself.

Sources

• Gartner projection on enterprise agent adoption (2026 forecast).
• LangChain survey (n=1,300) on pilot-to-production governance gaps.
• NIST AI Risk Management Framework and CAISI agent-identity initiative materials (2026).
• Internal incident analysis sample: 31 sprawl incidents across four companies.

Your company will have 50 agents by the end of 2026. The question isn't whether to govern them. It's whether you build the governance architecture before or after the first incident. The math strongly favours before.