The agent estate is arriving before the control system

The real warning is authority without ownership

That scene is illustrative, but the predicament is ordinary: organisations can create useful software faster than they preserve ownership, access boundaries, evidence and a safe retirement path.

Gartner has put scale around the concern, forecasting that the average global Fortune 500 enterprise could have more than 150,000 agents in use by 2028. The public material reviewed does not expose the forecast methodology, so the figure is better treated as a stress signal than a planning baseline.1

An embedded assistant, a persistent workflow, a temporary child agent and an individual execution may all be counted differently. Whatever the eventual total, informal governance, local spreadsheets and occasional access reviews become less credible as identities, permissions, versions and dependencies multiply.

The governing question is therefore not how many agents an organisation may have. It is whether it can identify, own, limit, observe and retire every agent that has authority to act.

That is the point at which agent sprawl stops being a fashionable security phrase and becomes an operating-model problem.

Organisations can tolerate surprisingly large inventories when authority is visible and bounded. They struggle with much smaller estates when ownership, dependencies and stop paths are opaque. The burden is uncertainty: security cannot revoke safely, operations cannot defend continued use, and leaders cannot tell whether the exposure is deliberate.

An agent does not need a name to create an identity problem

Borrowed authority is still authority

The phrase “every agent becomes an identity” is useful shorthand, but many agents do not operate as distinct, first-class identities. They may borrow a human session, inherit a service account, use an application identity or receive a delegated token. That does not remove the identity problem; it makes the authority harder to see.

Borrowed authority also blurs accountability. A human may appear in the audit trail even though the agent selected the action; a service account may show which application connected without revealing which agent, version or task made the decision. An organisation can have authentication without useful attribution.

Consider a simple sequence. An agent reads an incoming email, checks a customer record, decides that a refund meets policy and instructs a payment system to act. At each stage, the organisation needs to know:

• which software entity made the request;
• how that entity proved what it was;
• what it was authorised to do;
• on whose authority it acted;
• what information it used;
• whether a human approval was required;
• and whether the action can be reconstructed afterwards.

These are identification, authentication, authorisation, delegation and audit questions. They are not novel simply because an AI model is involved. What changes is that the software can select actions dynamically rather than merely execute a fixed sequence.

Standards are still catching up

NIST’s February 2026 concept paper is revealing because it is still framed as questions: what identity metadata an agent needs; whether identity should be fixed or task-dependent; how least privilege works when actions are not fully predictable; how delegated “on behalf of” authority is proved; and how actions and intent are logged in a tamper-resistant way.4

This is an early-stage standards signal, not a final operating manual. It confirms that the governance problem is real enough for the standards system to address.

Currentness check, 31 October 2026: NIST published proposed agent-identity design tenets on 27 October, after this article was written. They develop the same questions around distinct identification, delegated authority, short-lived and revocable access, policy separated from reasoning, monitoring and evidence. They are proposed design tenets, not a final standard.9

OWASP reaches the same territory from a threat perspective. Tool misuse, privilege compromise, memory poisoning and untraceable action chains become more consequential when an agent has broad permissions or combines legitimate tools in an unexpected way.5,6

“Every agent that can act becomes an identity and authorisation problem, even when the organisation has not given it a distinct identity.”

Sprawl is a relationship and lifecycle problem, not a headcount problem

Agent counts attract attention because they are easy to repeat. The harder problem is the network of identities, permissions and dependencies behind them.

One agent may have several credentials, tool connections, data stores, memories, versions, owners and dependencies. A multi-agent system may create temporary child agents with short-lived access, while an application vendor may add an embedded agent before the organisation has decided who owns it.

The estate therefore grows faster than the visible count.

A stale agent is not merely unused software. It may retain a live route into email, customer data, source code, finance systems or cloud infrastructure. The cheapest moment to define retirement is before deployment.

What is real - and what is not yet settled

Taken together, the material reviewed supports a disciplined split between controls that are already necessary and questions that remain open.2,4-6

This distinction matters because the correct response is neither complacency nor panic. There is enough evidence to act on ownership, inventory, access and observability now. There is not enough evidence to treat every forecast as fact or every emerging security category as procurement-ready.

Central policy cannot govern an application estate by itself

The central-to-local gap

In a 2025 Gartner survey of 360 IT leaders, 70 per cent reported a centralised AI strategy, but only 34 per cent said they could apply it to enterprise applications. Sixty-eight per cent struggled to keep pace as vendors added generative and agentic features; only 15 per cent strongly believed the right governance models were in place.2

These figures are directional, not a census. Respondents were already deploying or planning generative AI in selected application domains, and Gartner says the results do not represent the global market.2

A vendor-commissioned Cloud Security Alliance survey offered a similar signal: 78 per cent of respondents lacked documented policies for creating or removing AI identities, with unclear ownership and over-permissioned access among the leading concerns. Oasis Security financed and co-developed the work, so the figures are commercially interested indicators rather than neutral market facts.7

Rules need operational owners

The useful point is the failure pattern, not the precision of either survey. A central committee can set principles - least privilege, protected information and human accountability - but it cannot decide which fields a service agent may update, which finance actions require a second approval or when an embedded vendor feature should be disabled.

Those choices sit at application and domain level. Operational owners must work with security, data, risk and technology teams to turn general principles into enforceable controls.

Central governance can set the rules, but operational owners must make them real. Tools may help discover identities, enforce policies and monitor actions; they cannot supply the ownership model.

The practical goal is controlled permission to innovate: neither blanket restriction, which can push work into shadow AI, nor unrestricted experimentation, which creates a different form of sprawl.1,3

Meeting-ready artefact: the agent passport

An organisation does not need a new committee for every small automation. It does need a minimum control record before an agent receives live authority.

The following “agent passport” can sit behind an agent register, procurement review or application-governance process.

The passport is not a substitute for technical controls. It is the management layer that tells those controls what they are supposed to enforce.

Persistent agents and temporary agents need different treatment

A governance system that sends every task-specific agent instance to a human committee will collapse under its own weight.

Persistent agents normally need an individual record, named ownership and a review cycle. For temporary agents, the governed object may be the approved template, parent agent, delegation policy and credential rules rather than each short-lived instance.

That distinction is operationally important. A passport for every execution would bury teams in administration; a passport only for the parent can hide how authority was delegated. The workable middle is governed templates, bounded inheritance and evidence for each run.

The instance should still be attributable, task-bound, no more privileged than necessary, logged and automatically expired.

This is why NIST’s question about fixed versus ephemeral identity matters. The architecture may vary, but the principle should not: short life must not mean untraceable life.4

Govern by consequence, not by the word “agent”

The word “agent” covers too much. A read-only research assistant and an autonomous payments agent should not enter the same approval path.

A simple internal classification - not an industry standard - can help leaders match governance to consequence:

1. Observe. The agent can retrieve approved information but cannot change a system or communicate externally.
2. Advise. The agent can analyse, draft or recommend, but a person decides and executes.
3. Act with approval. The agent can prepare a transaction or system change, but a defined human authorises execution.
4. Act within bounded authority. The agent can execute reversible, low-consequence actions within explicit limits and exception rules.
5. High-consequence authority. The agent can affect money, production systems, regulated decisions, customers, public services, legal rights or other difficult-to-reverse outcomes.

Controls should rise with data sensitivity, external effect, reversibility, financial exposure, reputational consequence and the difficulty of detecting a bad action.

For high-consequence activity, human involvement should not be a ceremonial click. Approval needs enough information and independence to challenge the action. OWASP likewise emphasises least privilege, explicit authorisation for sensitive tools, human oversight, monitoring and separation between decision and irreversible execution.6

This avoids governance theatre: a read-only research agent should not face the same process as one that can change payroll, approve a claim or alter production infrastructure.

A product cannot supply ownership

The commercial temptation is to move directly from “agent sprawl” to “agent security platform”.

Products may help discover non-human identities, catalogue agents, rotate credentials, enforce policies, monitor actions and revoke access. These are valuable capabilities and may become necessary at scale.

They cannot decide why an agent should exist, which outcome justifies its authority, who is accountable when it is wrong, which actions require human judgement or when it should be retired.

Nor can a platform resolve the political question that appears when several functions benefit from an agent but no one wants to own its residual risk. That is an operating decision, not a missing software feature.

Buying a control product before defining the control model risks automating ambiguity.

Define the agent passport, consequence levels, ownership model and evidence requirements first; then ask suppliers how their technology discovers, implements or enforces them. The organisation’s requirements - not the demonstration - should define what must be proved.

What to ask vendors and internal teams

Use these questions with technology suppliers, application vendors, developers, security teams and operational owners.

Inventory, identity and access

1. What exactly do you count as an agent? Can the inventory distinguish persistent agents, approved templates, temporary child agents and individual executions? Look for a taxonomy that supports governance rather than an impressive total.
2. Through which identity does each agent act? Is it a distinct workload identity, a shared service account or delegated human authority? Can each action be traced through the delegation chain to an accountable owner or approver?
3. Can access be task-scoped and short-lived? Credentials and permissions should expire when a task finishes; long-lived shared secrets turn temporary work into durable exposure.
4. How is least privilege maintained when the agent chooses tools dynamically? Ask how read, write, execution and irreversible actions are separated, and how new tool access is approved.

Lineage, evidence and shutdown

5. Can parent and child agents be traced? The organisation should see lineage, inherited authority, purpose, cost and final status. Privilege should narrow, not expand silently, as work is delegated.
6. What evidence is retained about an action? Ask for the requesting identity, agent version, authority invoked, approvals, tool calls, data touched, result, exceptions and stop events - and how those records are protected.
7. Can access be revoked precisely and safely? Can one agent, credential, tool or task be stopped without breaking unrelated services? Can dormant agents and dependencies be identified before retirement?
8. What testing shows that the controls work in the deployed version? Look for abuse cases, permission failures, prompt-injection tests, approval and denial behaviour, timeouts, circuit breakers, cost limits and accepted residual risks. A policy statement is not a tested control.

What leaders should do now

Start with one operational domain

Choose a function where agents are already being built, enabled by vendors or discussed seriously. Map persistent agents, embedded features, templates, temporary instances, identities, credentials, tools and data connections.

Assign ownership before expanding authority

Require an accountable operational owner and a technical custodian. Complete the agent passport before an agent gains write access, external communication rights or the ability to trigger consequential actions.

Set restrictive defaults

Default to read-only access, short-lived credentials, automatic expiry, bounded tools, separation of sensitive actions and explicit approval for difficult-to-reverse outcomes. Exceptions should be deliberate and recorded.

Make actions observable and stoppable

Create a logging and incident path before live deployment. Confirm that the organisation can attribute actions, identify the authority used, detect anomalous behaviour and revoke access at the appropriate level.

Measure the health of the estate

Useful measures may include:

• the proportion of agents with a named owner and current passport;
• the proportion using short-lived rather than persistent credentials;
• the number of dormant or unaccounted-for agents;
• the time required to revoke an exposed credential or stop an agent;
• the proportion of high-consequence actions receiving independent approval;
• and the number of cost, retry, recursion or tool-chain exceptions.

The action framing is mixed but clear. Act now on inventory, ownership, permissions, logs and retirement. Test products against an internally defined control model and keep watching the standards work. Do not wait for a perfect framework or let vendor urgency substitute for evidence.

Capability should not outrun accountability

The exact future agent count is not the governing insight. Creation, embedding and delegation are becoming easier; every reduction in friction increases the importance of ownership, identity, authority, evidence and retirement.

The mature organisation will not be the one that can say it has the most agents. It will be the one that can answer, without a search party:

• which agents exist;
• why they exist;
• what authority they carry;
• what they have done;
• when their authority expires;
• and who can stop them.