Agent Sprawl: Know What Is Acting on Your Business

Marketing has an assistant preparing campaign briefs. Finance has a workflow classifying invoices. Operations has a scheduled agent updating job notes. Each was introduced to solve a local problem. Nobody can now say with confidence which credentials they use or what happens if the employee who created them leaves.

That is the practical risk of agent sprawl. The problem is not merely a large number of agents. It is a growing set of actions and dependencies without a reliable account of ownership, authority, and continuing purpose.

Inventory the work, not just the chatbot

A list of product names is not enough. One product may run several workflows with different data access. A scheduled automation may have no conversational interface at all. A connector may be the component that actually changes the business record.

For each use case, record its business purpose, owner, users, inputs, outputs, actions, credentials, model or service version, external dependencies, evaluation status, and disable procedure. Include temporary experiments and the date they should be reviewed.

NIST's Generative AI Profile recommends organizational inventory practices. An inventory is useful evidence, but it does not prove that the discovered systems are appropriately authorized or that every undiscovered workflow has been eliminated.

An illustrative shared-drive assistant

Imagine a sales team creates an assistant that reads a shared folder and prepares renewal summaries. Initially, one manager checks every draft. Over time, a scheduled integration begins posting the summaries into the customer system.

The original manager changes roles, the folder gains confidential acquisition materials, and the integration still uses a broad personal credential. The workflow's purpose appears unchanged, but its effective access and operating responsibility have shifted.

A proper review identifies the approved folder subset, the permitted customer records, the service identity, the reviewer, and the exact write operation. Credentials are scoped to the task. New content does not automatically inherit permission to be processed merely because it appears in a convenient location.

The workflow is either accepted under the new boundary, returned to draft-only operation, or retired. The decision and its evidence are recorded. The system should not remain active because nobody wants to interrupt something that seems useful.

Give agents identifiable authority

Using an employee's broad login makes it difficult to distinguish that person's actions from automated actions. It also creates fragile dependencies on password changes, departures, and access reviews.

NIST's identity guidance emphasizes identifiable agents and appropriate entitlements. The implementation should preserve who requested an action, which workflow performed it, and which authority permitted it.

An agent's identity does not automatically grant authority. The downstream service still checks whether that identity can perform the requested action on the particular record. A role description or agent name is not an access-control policy.

Centralize standards without centralizing every idea

A central team can supply approved identity patterns, connectors, logging conventions, evaluation support, and procurement guidance. Local operators can still identify problems and test bounded solutions.

The balance should depend on risk. A read-only experiment using public information may need a light process. A workflow changing customer entitlements or financial records needs stronger review. Treating every experiment identically either creates unnecessary delay or gives consequential systems too little scrutiny.

Make the approved path easier to use than improvised credentials and hidden integrations. A registry that only adds paperwork will not resolve the operating incentives behind sprawl.

Discovery also needs a practical, non-punitive route. Ask teams which recurring tasks depend on a personal automation, shared account, or provider connection, and help move useful work into a supported arrangement. If reporting a helpful experiment only results in immediate shutdown, people have an incentive to keep dependencies hidden. Separate urgent unsafe access from improvements that can be regularized under a clear owner.

Review change and retirement

Access reviews should consider actual permissions and observed use, not only the original business justification. Check whether the owner still owns the process, whether the workload remains in scope, and whether provider or connector changes require renewed testing.

When retiring a workflow, revoke credentials, disable schedules, reconcile in-progress work, and preserve necessary audit records under the applicable retention policy. Verify that dependent work has another path. Deleting a prompt does not necessarily stop an external integration.

Useful measures include workflows without owners, overdue reviews, unused permissions, failed retirement checks, and unresolved exceptions. The goal is not the smallest possible agent count. It is an operating environment where the business can explain what is acting, why it is allowed, and how to stop it when the need changes.