A clean audit trail that shows exactly who did what, even when agents run on behalf of users, is the foundation of reliable security. When every command, query, and file transfer can be tied back to an individual identity, investigations are fast, compliance evidence is solid, and the blast radius of a breach stays limited.
In practice, many teams hand over long‑lived service accounts to automation scripts, CI pipelines, or third‑party bots. Those agents authenticate once and then act for weeks or months, often without a human in the loop. The result is a single credential that performs dozens of distinct tasks, and the logs that come out of the target system simply record the service account name. Nothing in the log tells you which engineer triggered a particular deployment or which automated job fetched a sensitive row.
This state of affairs is common on AWS. Engineers spin up an EC2 instance, install an agent that holds an IAM role with broad permissions, and then let that instance execute commands on other instances via SSH or invoke AWS CLI calls. The same role also powers Lambda functions and runs database migrations. Because the role never changes, the audit trail shows a flat line of activity under one principal, regardless of the true origin of each request.
When an incident occurs, the lack of granular attribution makes root‑cause analysis a guessing game. Auditors ask for evidence that a specific user accessed a particular S3 bucket or executed a destructive SQL statement. The only evidence available is the service account identifier, which fails to satisfy most compliance frameworks and leaves organizations exposed to regulatory penalties.
Why the existing setup falls short
Identity providers and IAM policies do a good job of deciding who may start a session. An OIDC token or an assumed IAM role tells the gateway that the request originates from a known principal. That decision point, however, lives before the actual connection reaches the target resource. The request still travels directly to the database, the SSH daemon, or the AWS CLI endpoint without any additional checks.
Because the request travels directly to the target, there is no built‑in mechanism to capture the full session for later replay or forensic analysis. This creates three critical gaps:
- There is no real‑time verification that the command matches the user’s intent.
- Sensitive response fields flow back to the caller unfiltered, so credentials or personal data can be exposed.
- Without a tamper‑evident log, post‑mortem analysis is difficult.
Those gaps exist even though the initial authentication step is strong. In other words, the setup decides who can start, but it does not enforce what happens after the connection is established.
Putting a gateway in the data path
hoop.dev solves the problem by inserting a Layer 7 gateway between the authenticated identity and the AWS resource. The gateway becomes the only place where traffic can be inspected, approved, or altered. Because every packet passes through hoop.dev, the system can enforce policies that were impossible in the direct‑connect model.
When an engineer launches an SSH session, hoop.dev first validates the OIDC token, then proxies the connection to the target host. While the session is active, hoop.dev records each command and its output, creating a complete audit trail that attributes every line to the original user. If a command attempts to read a secret file, hoop.dev can mask that field in the response before it reaches the client.