An offboarded contractor’s CI job still runs a Docker container that launches a second‑stage script, which in turn spins up a temporary SSH tunnel to an internal database. The tunnel is created by an automation agent that the contractor once configured, and that agent now calls a second‑party monitoring agent inside the same network. Because the original credentials were never revoked, the nested chain can pull rows of customer data and push them to an external bucket, creating a classic case of data exfiltration.
Nested agents are any process that authenticates on behalf of another process and then spawns a further agent to reach a target system. In practice this pattern appears in CI pipelines that hand off secrets to a build‑time scanner, in security tools that delegate log collection to a lightweight sidecar, or in AI‑driven assistants that invoke a remote execution service. Each hand‑off expands the trust boundary: the first agent must trust the second, and the second must trust the third, and so on. When any link in that chain retains long‑lived credentials, the entire sequence becomes a conduit for data exfiltration.
How data exfiltration can travel through nested agents
The danger is not the mere presence of multiple agents but the lack of visibility and control at the point where the outermost agent talks to the protected resource. Attackers can hide inside a legitimate job, let a downstream agent issue a query, and then exfiltrate the response before the original request completes. Typical warning signs include:
- Credentials that outlive the role or person that created them.
- Automation jobs that invoke external scripts without explicit approval.
- Network flows that bypass the organization’s normal bastion or proxy layer.
- Long‑running sessions that are not recorded or periodically audited.
Because the traffic is encrypted end‑to‑end between the outer agent and the database, traditional network‑level IDS cannot see the payload. The only reliable way to stop data exfiltration is to place an inspection point on the actual data path, where the request is proxied before it reaches the target.
Placing a gateway in the data path
When a Layer 7 gateway sits between the outermost agent and the infrastructure, it becomes the sole authority that can enforce guardrails. The gateway can:
- Record every command and response for replay and audit.
- Mask or redact sensitive fields in query results before they leave the protected system.
- Require just‑in‑time human approval for high‑risk operations.
- Block commands that match known exfiltration patterns.
These controls are only possible because the gateway intercepts the protocol itself, not because the identity provider or the underlying credential is changed. The setup that decides who may start a session (OIDC tokens, service accounts, least‑privilege roles) remains necessary, but it does not provide the enforcement outcomes on its own.
How hoop.dev enforces controls for nested agents
hoop.dev implements the data‑path gateway described above. It runs a lightweight agent inside the same network as the protected resource and proxies all connections, whether they originate from a CI runner, a monitoring sidecar, or an AI assistant. Because hoop.dev sits in the protocol layer, it can apply inline masking to query results, block suspicious commands, and require an approval workflow before a write operation is allowed. Every session is recorded and stored for replay, giving security teams a complete forensic trail.