When an automated build or deployment job runs with a static credential, a single leak can give an attacker unfettered access to production databases, Kubernetes clusters, or internal services. Treating every non-human identity as a permanent key is a recipe for disaster. Because these jobs rely on a non-human identity, the financial impact of a breach, the downtime of a compromised pipeline, and the erosion of trust across teams are all too common. Organizations that treat service accounts like permanent keys often pay for the consequences later.
Non-human identities, service accounts, CI tokens, and AI agents, are essential for modern code execution, but they also expand the attack surface. A bot that can push code, run migrations, or invoke internal APIs must be tightly scoped, monitored, and revocable. Without proper controls, a compromised token can execute arbitrary commands, read sensitive data, and persist across environments.
Why the usual setup falls short
Most teams provision a service account in the cloud console, grant it broad permissions, and embed the secret in CI configuration files. The setup decides who the request is, typically a CI runner or automation script, but it does not enforce any boundary once the request leaves the identity provider. The connection goes directly to the target database or Kubernetes API, meaning:
- There is no real-time audit of which command was run or which data was returned.
- Sensitive fields are sent in clear text to the automation process.
- Any compromise of the credential bypasses approval workflows.
- Revoking access requires rotating the secret and updating every pipeline.
In short, the setup is necessary to identify the caller, but it is never sufficient to protect the data path.
Placing enforcement in the data path
The only reliable place to enforce policy is the gateway that sits between the non-human identity and the target service. By inserting a Layer 7 proxy, every request can be inspected, approved, masked, or blocked before it reaches the backend. This approach ensures that:
- Each command is recorded for replay and forensic analysis.
- Sensitive response fields are masked in real time, preventing downstream scripts from storing raw secrets.
- Just-in-time approval can be required for high‑risk operations, such as schema changes or cluster admin commands.
- Access can be revoked instantly at the gateway without touching the underlying credential.
Those enforcement outcomes exist only because the gateway controls the data path. Without it, the service account would continue to have unchecked, direct access.
How hoop.dev fulfills the requirement
hoop.dev is an open-source identity-aware proxy that sits in the data path for code execution workloads. It authenticates each non-human identity via OIDC or SAML, reads group membership, and then applies policy at the protocol level. When a CI job or AI agent initiates a connection, hoop.dev:
- Records every session, including the exact commands issued and the responses received.
- Masks configured fields such as passwords, API keys, or personally identifiable information before they reach the automation process.
- Requires just-in-time approval for privileged actions, routing them to an authorized human reviewer.
- Blocks dangerous commands that match a denylist, preventing accidental destructive operations.
- Enforces least‑privilege by mapping identity groups to fine‑grained permissions on the target service.
Because hoop.dev is the only component that can see and intervene in the traffic, the enforcement outcomes are guaranteed to happen. If hoop.dev were removed, the service account would again have direct, unmonitored access.