When a CI/CD pipeline runs under a compromised service account, every build, test, and deployment can be recorded as legitimate activity. Auditors then see a clean trail, while the attacker has silently exfiltrated data or inserted back‑doors. The cost is two‑fold: remediation effort skyrockets and the organization loses confidence in its access review process.
Today many teams grant their build agents long‑lived credentials and let those agents push code, run migrations, and execute remote commands without a single checkpoint. The agent’s identity is often a static token stored in a repository or a secret manager, and the pipeline runs with that token for weeks or months. No one watches the exact commands the agent issues, and the logs that are kept are typically the raw console output, which can be filtered or tampered with before it reaches the audit store. In short, the current state gives attackers a wide attack surface and leaves access reviews blind to what really happened.
Why access reviews matter for agent impersonation
Access reviews are supposed to answer the question, “Did the right people have the right permissions at the right time?” When an agent is impersonated, the answer becomes unreliable. The review process may show that a service account was used correctly, but the underlying traffic could have been rerouted, commands altered, or sensitive fields masked to hide malicious activity. The gap is not the identity system – it is the lack of a control point that can see every request before it reaches the target.
The precondition we need to fix is the ability to observe and intervene on every command that flows through the pipeline. Even if we enforce strict token rotation and limit the scopes of service accounts, the request still travels directly to the database, Kubernetes cluster, or SSH host. Without a gateway that sits in the data path, there is no place to enforce real‑time masking, command blocking, or just‑in‑time approval. The request remains a black box for the review team.
Placing enforcement in the data path
The correct architectural answer is to insert a Layer 7 gateway between the pipeline agent and the infrastructure it talks to. The gateway validates the incoming OIDC or SAML token, maps the user or service account to a policy, and then inspects the protocol payload. This is the only place where enforcement can happen because the agent itself cannot be trusted to apply the policy.
hoop.dev provides that data‑path enforcement. It proxies connections to databases, Kubernetes, SSH, and HTTP services, and it adds four critical capabilities that directly support reliable access reviews:
- Session recording. hoop.dev records every request and response, providing an audit trail that reviewers can replay.
- Inline data masking. Sensitive fields such as passwords or tokens are redacted in real time, preventing accidental leakage.
- Command‑level blocking and approval. Dangerous commands are halted and routed to a human approver before execution.
- Just‑in‑time credential handling. The gateway holds the target credentials; the pipeline never sees them.
Because hoop.dev sits in the data path, all of these outcomes are guaranteed to occur regardless of how the pipeline is configured. If the gateway were removed, none of the above would be true – the pipeline would again have unchecked access.