Itential details how “agent sprawl” extends “script sprawl”

The vendor blog argues that “agent sprawl” will create a governance and access-control challenge similar to prior “script sprawl,” but with a larger range of actions due to agent-driven decisions. For enterprise IT and security leaders, the post frames governance, RBAC, and approved workflow reuse as the controls to manage that risk.

Research Overview

The post is built around a comparison between past network automation practices and emerging agent-based approaches. It links the earlier issue of unmanaged, engineer-created automation scripts to the expectation that comparable uncontrolled growth will occur with agents.

It also references a podcast conversation with Pete Pizzatello and highlights that the discussion covered script sprawl and the need for guardrails when agents select tools and act on systems. The author extends one point made during that conversation.

Key Findings

The blog’s core claim is that agents can expand the range of potential outcomes because they reason, choose tools, and determine which devices, workflows, or external interfaces to use. The post contrasts this with scripts, which the author describes as limited to what they were written to do.

It asserts that multiple engineers building agents without consistent controls will increase variability in access, connected interfaces, and definitions of what is “safe.” The author says this inconsistency is visible in the broader community when governance questions get minimal responses.

Technical Breakdown

The post describes script sprawl as a pattern seen in network automation teams: multiple versions of scripts living in shared folders, inconsistent functionality, and dependence on specific individuals to maintain or operate critical automation. It attributes the pattern to automation tooling that made it easy to build individual scripts while leaving governance unaddressed.

For agents, the post explains that the expanded “surface area of what could go wrong” comes from decisions made outside the immediate control of a human operator at the time of execution. It describes agents selecting tools, determining targets, initiating workflows, and calling external interfaces through MCPs, depending on what each agent is configured to do.

Operational Impact

The blog outlines a three-part approach it says mirrors what was needed in the script era but applies more directly to agent deployments. It calls out governance as documented authorization with an audit trail rather than personal “constitution” files on developer machines.

It further states that agents should inherit the access controls used for human users, including limits on privileged capabilities. It also emphasizes reuse: tested and approved workflows should be callable tools for other agents, reducing the likelihood that multiple engineers create closely related versions.

The post includes an operational prompt for network engineers and automation leads to inventory how many agents were built in the prior 90 days, where those agents run, who can run them, and what happens when the original builder is unavailable. It presents unclear answers as indicators of agent sprawl.

It concludes by reiterating that governance should be implemented by design rather than by accident, and it points readers to the referenced podcast for additional discussion of guardrails and related topics.

This Blog Signals brief is a fact-based summary of a vendor blog post arguing that “agent sprawl” will mirror script sprawl while increasing risk through agent-driven choices, and it presents governance, RBAC inheritance, and workflow reuse as the operational controls for managing agent proliferation.