An offboarded contractor still has a CI pipeline that pushes Docker images using a hard‑coded service account token, creating a classic case of agent sprawl. The token lives in a Jenkins secret, the secret is copied into multiple build jobs, and every job can spin up a temporary shell inside production containers. The same pattern repeats for internal bots that run nightly database migrations: a static credential is baked into a cron definition, and the credential is never rotated. Teams rely on the convenience of a single secret, but the result is a sprawling network of agents that can reach any internal host without any visibility, approval, or revocation path.
This situation is the textbook definition of agent sprawl. Every runtime that needs to act on behalf of a service ends up with its own credential, often duplicated across repositories, CI definitions, and ad‑hoc scripts. The immediate benefit is speed – engineers push code, bots run, and services talk to each other without a ticket. The hidden cost is a massive attack surface: a compromised secret instantly grants unrestricted access to every downstream system the agent can reach. Because the agents talk directly to the target, there is no central point that can observe what commands are executed, mask sensitive fields in responses, or enforce just‑in‑time approval.
Understanding agent sprawl in runtime environments
Agent sprawl originates from three intertwined practices. First, identities for non‑human actors are often created as long‑lived service accounts. Second, those identities are embedded directly in the connection strings or environment variables of the runtime. Third, the deployment model places the credential close to the code, so the runtime can authenticate without an external check. The result is a direct line from the agent to the database, Kubernetes API, SSH daemon, or HTTP service, bypassing any enforcement layer.
From a security perspective, this model fails three essential requirements:
- Visibility: No log captures the exact statement an automated job sent to a database, nor the sequence of commands an SSH session executed.
- Least‑privilege enforcement: The credential often has broad permissions because rotating it per job is impractical.
- Dynamic approval: There is no workflow to pause a risky operation for a human reviewer before it runs.
Because the enforcement point is missing, the organization cannot answer basic audit questions such as “who queried customer PII at 03:00?” or “which job performed a destructive schema change?” The answer is always “the system does not record it.”
The missing enforcement layer
Identity and token management – the setup – decides who the request is and whether it may start. It can enforce that only a specific service account exists, that the account is federated through OIDC, and that the token has a short TTL. However, the setup alone does not inspect the actual traffic flowing to the target. The request still reaches the database or Kubernetes API directly, with no audit trail, no inline masking of sensitive fields, and no opportunity for a just‑in‑time (JIT) approval step.
To close that gap, a gateway must sit in the data path – the only place where enforcement can happen. The gateway intercepts the wire‑level protocol, applies policies, and then forwards the request. Without such a data‑path component, the organization is left with a network of unchecked agents.