An offboarded contractor’s token still lives in a CI pipeline, adding to service account sprawl, and a nightly job uses that token to spin up test VMs. The VMs run a sub‑agent that inherits the same service account, and the sub‑agent then talks to internal databases, message queues, and storage. When the contractor leaves, the token is revoked at the identity provider, but the sub‑agent continues to act on its own, using the same credentials it inherited. The result is a ghost actor that can read data, write logs, and even launch new workloads, all without any human ever noticing.
This scenario illustrates the real, unsanitized starting state many organizations face. Sub‑agents are often deployed automatically by CI/CD systems, infrastructure‑as‑code tools, or third‑party SaaS integrations. Each deployment copies a service account into the sub‑agent’s runtime environment. Over time, dozens or hundreds of sub‑agents accumulate, each holding a long‑lived credential that never expires. The credentials are rarely rotated, and the audit logs live only on the host that launched the sub‑agent. No single team owns the lifecycle of those accounts, and the sprawl becomes invisible until a breach surfaces.
Why subagents amplify service account sprawl
Service account sprawl is a natural by‑product of treating sub‑agents as disposable compute units. Engineers grant a service account broad permissions once, embed the secret in a container image or a Terraform module, and then reuse the same secret across many environments. The convenience of a single credential outweighs the perceived risk, especially when the sub‑agent’s workload is short‑lived. However, each copy creates an independent attack surface. If any sub‑agent is compromised, through a vulnerable library, a mis‑configured network rule, or a malicious insider, the attacker instantly inherits the full permission set of the original service account.
Because the sub‑agents operate behind the scenes, existing monitoring tools often miss their activity. Traditional IAM dashboards show the service account as “in use,” but they cannot attribute which sub‑agent performed which operation. The lack of granular, per‑session visibility makes it impossible to answer questions such as “who read this row?” or “which job wrote this log entry?” This opacity is the core of the risk.
What a proper control surface looks like
The first step toward mitigating service account sprawl is to recognize that the setup, identity federation, token issuance, and least‑privilege grants, only decides who may start a request. Those mechanisms do not enforce any guardrails once the request reaches the target system. To close the gap, the enforcement point must sit in the data path, between the sub‑agent and the downstream resource. Only there can the system inspect each command, apply just‑in‑time approval, mask sensitive fields in responses, and record the full session for replay.
In practice this means placing a layer‑7 gateway that proxies every connection from a sub‑agent to a database, message queue, or storage bucket. The gateway validates the identity token, checks the requested operation against a policy, and, if necessary, routes the request for human approval before it proceeds. It also rewrites responses to hide personally identifiable information and writes an audit log entry that ties the action to the original user, the sub‑agent, and the time of execution.