What happens to your blast radius when a single agent can launch other agents across AWS?
Many organizations rely on bastion hosts, jump boxes, or automation scripts that start an agent on one instance and then use that agent to reach additional workloads. The initial connection often uses a shared SSH key or a static IAM credential that is copied to the first host. From there, the same credential is reused to open further sessions, copy binaries, or invoke remote commands. The result is a chain of trust that spreads far beyond the original point of entry.
In practice, engineers treat the first hop as the security boundary. The bastion is audited, the key is rotated periodically, and access is granted through a privileged group. Once the agent is on the host, however, the subsequent hops are invisible to the original policy engine. The downstream connections inherit the same privileges, bypass any approval workflow, and leave no record of who actually executed the final command. In a breach scenario, an attacker who compromises the first host can pivot to dozens of services without triggering any alert.
This pattern inflates the blast radius dramatically. A single compromised credential can affect every workload that the initial agent can reach, and because the traffic never passes through a central control point, there is no way to mask sensitive fields, enforce command‑level policies, or capture a replayable session for forensic analysis. The organization ends up with a sprawling attack surface that is difficult to contain.
The root cause is a missing enforcement layer between the identity that started the session and the target resources. Identity‑based authentication (OIDC, SAML, IAM roles) decides who may begin a connection, but the request still travels directly to the target instance. Without a gateway that inspects each request, the system cannot apply just‑in‑time approvals, inline data masking, or command blocking.
hoop.dev fills that gap by acting as a Layer 7 gateway that sits in the data path for every connection. The gateway is deployed as a network‑resident agent inside the customer’s VPC. Users authenticate with their corporate IdP, and hoop.dev validates the token, extracts group membership, and then decides whether the request may proceed. Crucially, every packet travels through hoop.dev before reaching the target, allowing the platform to enforce policies in real time.
Blast radius and nested agents
When a nested agent tries to reach another host, hoop.dev intercepts the request and applies the same policy checks that were used for the original session. The gateway can require a fresh just‑in‑time approval for each hop, ensuring that privilege escalation is always visible to an authorized reviewer. If the downstream command contains a pattern that matches a blocklist, hoop.dev stops it before it reaches the target. For data that flows back to the user, hoop.dev can mask fields such as passwords or tokens, preventing accidental leakage.
Because the enforcement happens in the data path, the blast radius is limited to the scope defined in the policy. Even if an attacker compromises a host, they cannot silently launch new agents without hoop.dev granting explicit permission. Each new connection is recorded, providing a complete audit trail that can be replayed later for investigation.
How the architecture isolates risk
- Setup: Identity providers (Okta, Azure AD, Google Workspace) issue OIDC or SAML tokens. hoop.dev verifies those tokens and maps them to roles that define which resources a user may access.
- The data path: All traffic to databases, Kubernetes clusters, SSH endpoints, or HTTP services is proxied through hoop.dev. This is the only place where enforcement can occur.
- Enforcement outcomes: hoop.dev records each session, masks sensitive response fields, requires just‑in‑time approvals for risky commands, and blocks disallowed operations. These outcomes exist only because hoop.dev sits in the data path.
In a typical nested‑agent scenario, the initial user authenticates, hoop.dev grants a short‑lived session token, and the user’s client connects to the first host through the gateway. When that host attempts to start a second agent, the request is again routed through hoop.dev, which evaluates the policy, logs the attempt, and, if necessary, pauses for approval. The second agent cannot bypass the gateway because the network topology places hoop.dev as the sole egress point for the VPC.
Getting started with hoop.dev
To protect your environment, start by deploying the gateway using the getting‑started guide. Configure your IdP, define role‑based policies, and register the AWS resources you want to protect. The documentation on hoop.dev/learn walks you through policy design, just‑in‑time approval workflows, and session replay.
FAQ
Does hoop.dev eliminate the need for bastion hosts?
No. Bastion hosts can still be useful for network segmentation, but hoop.dev adds a policy enforcement layer that the bastion alone cannot provide. The gateway ensures that every connection, even those initiated from a bastion, is subject to the same controls.
Can I use hoop.dev with existing IAM roles?
Yes. hoop.dev can be configured to assume an IAM role that has the minimum permissions required for the target service. The role is stored in the gateway, so users never see the credentials.
What happens to data that contains secrets?
hoop.dev can mask configured fields in real time, preventing secrets from being exposed in logs or to the client. The masking policy is defined in the gateway configuration.
Explore the source code, contribute improvements, and see how the platform evolves on GitHub.
