Subagents are the hidden conduit for lateral movement across your environment.
In many organizations a privileged service account launches a helper process – a subagent – on a host to perform routine tasks. That subagent inherits the parent’s credentials, often a static token or a long‑lived SSH key. Because the subagent runs with the same privileges, any compromise of the host instantly grants the attacker the ability to reach any other service the parent could access. Teams typically trust the parent process to stay honest, so they never instrument the subagent with independent audit or approval. The result is a blind spot: commands issued by the subagent are not logged, data returned is not inspected, and no one can intervene before a dangerous operation is executed.
This reality satisfies the immediate need to get work done, but it leaves three critical gaps. First, the identity that initiated the request is lost once the subagent takes over. Second, the network path from the subagent to downstream resources bypasses any central control point, so policies cannot be enforced. Third, there is no immutable record of what the subagent did, making forensic analysis impossible after an incident.
Why lateral movement matters for subagents
Lateral movement is the technique attackers use to expand their foothold after an initial breach. When a subagent can talk directly to databases, Kubernetes APIs, or internal HTTP services, it becomes a perfect vehicle for that expansion. The subagent inherits the parent’s permissions, which are often broader than any single user needs. Without a gate that inspects each request, the subagent can issue a SELECT * FROM users query, pull secrets from a vault, or execute a kubectl exec on a critical pod, all without triggering an alert.
Even legitimate automation can suffer from this problem. A CI pipeline may spin up a subagent to run integration tests against a staging database. If the pipeline is compromised, the attacker can reuse that subagent to read production data, because the same credentials are reused across environments. The lack of per‑request visibility means security teams cannot differentiate between a benign test run and a malicious data exfiltration attempt.
How hoop.dev stops lateral movement at the data path
hoop.dev inserts a Layer 7 gateway between every subagent request and the target resource. The gateway becomes the only place where traffic is inspected, policies are applied, and evidence is recorded. Because hoop.dev sits in the data path, it can enforce the same controls that a firewall cannot – command‑level approval, inline masking of sensitive fields, and real‑time blocking of dangerous operations.
When a subagent attempts to open a connection, hoop.dev first validates the user’s OIDC or SAML token. This setup step determines who the request is and whether it may start, but it does not enforce any guardrails on its own. The actual enforcement happens inside hoop.dev. The gateway records each subagent session, captures every command, and stores the transcript for replay. If a command matches a risky pattern, hoop.dev blocks it before it reaches the downstream service. For queries that return personally identifiable information, hoop.dev can mask the fields in real time, ensuring that downstream systems never see raw data.
Because hoop.dev controls the flow, it also enables just‑in‑time approval. An engineer can request access to a sensitive database, and the request is held at the gateway until an authorized approver grants it. The subagent never sees the credential; hoop.dev presents a short‑lived token that expires when the session ends. This eliminates the need for long‑lived shared secrets and reduces the blast radius of any single compromised host.
Key enforcement outcomes
- hoop.dev records every subagent interaction, providing a complete audit trail for investigators.
- hoop.dev masks sensitive response fields, preventing accidental leakage of secrets.
- hoop.dev blocks dangerous commands in real time, stopping lateral movement before it happens.
- hoop.dev requires just‑in‑time approval, ensuring that privileged access is granted only when needed.
These outcomes exist only because hoop.dev occupies the data path. Without the gateway, the subagent would connect directly to the target, and none of these controls could be applied. Together they shrink the attack surface that subagents can expose.
Getting started with a secure subagent architecture
Begin by deploying the gateway using the official getting started guide. The quick‑start sets up an OIDC‑enabled instance and a network‑resident agent that runs next to your resources. Register each subagent‑enabled service as a connection in hoop.dev, and configure the gateway to hold the credentials. From that point on, any subagent traffic is forced through the gateway, where the controls described above take effect.
For deeper insight into masking policies, session replay, and approval workflows, explore the learn section. The documentation walks through the policy model, explains how to define risk rules, and shows how to integrate with existing identity providers.
By moving the enforcement point to the data path, you turn a blind spot into a visible, controllable channel. Subagents no longer provide an unchecked path for lateral movement; instead, they become audited, approved, and safe conduits for legitimate automation.
Ready to see the code in action? View the open‑source repository on GitHub.
