An on‑premises AI pipeline continues to run a nightly model‑training job after the contractor who wrote it left the company. The job authenticates with a static service account credential that was never rotated. When the model produces a new artifact, an autonomous agent picks it up and pushes it to internal storage, still using the same shared secret. The artifact contains personally identifiable information, yet no one can tell which run accessed it or whether the data was redacted.
Relying on non-human identity for these agents would seem to solve the problem, but the reality is more nuanced. In practice, most organizations rely on two patterns:
- Shared service accounts, a single secret that many scripts, CI jobs, and AI agents reuse.
- Non‑human identity, a token or service principal issued by an identity provider for a specific automation workload.
Both patterns improve the setup phase. Non‑human identity replaces a password with an OIDC or SAML token, allowing the identity provider to enforce MFA, expiration, and group‑based scoping. However, the token is still presented directly to the target system. The request reaches the database or HTTP endpoint without an intervening enforcement point. Consequently, the organization still lacks:
- Real‑time approval before a risky query runs.
- Inline masking of credit‑card numbers or SSNs in query results.
- Session recording that can be replayed for forensic analysis.
- Granular, just‑in‑time access that expires the moment the job finishes.
Those missing controls are not solved by identity alone. The missing piece is a data‑path gateway that can observe and act on every protocol exchange. That is where hoop.dev fits.
Why non‑human identity matters for AI agents
Non‑human identity gives the organization visibility into who is authenticating. The identity provider can issue a distinct token for each CI pipeline, each model‑training job, and each autonomous agent. This eliminates credential sharing and enables revocation at the token level. The token also carries group membership, allowing policies such as “only agents in the ml‑training group may query the training_data database”.
But without a gateway, the token is simply handed to the downstream system. The downstream system validates the token and then executes the request. No additional checks occur, and the system does not retain a centrally managed audit log. If the downstream system is compromised, an attacker can reuse the token until it expires.
Why shared service accounts remain a liability
Shared service accounts hide the identity of the caller. All automation appears as a single user, making it impossible to attribute actions to a specific pipeline or job. Auditors cannot answer “which job accessed PII on March 12?” because the logs only show the generic account. Permissions are typically over‑provisioned to avoid breaking existing jobs, expanding the blast radius of a breach.
Even if an organization adds a vault to rotate the password, the core problem persists: the credential is still a static secret that any compromised process can reuse indefinitely.
hoop.dev as the enforcement point in the data path
hoop.dev sits between the identity layer and the target infrastructure. When an AI agent presents a non‑human identity token, hoop.dev validates the token, then proxies the protocol (PostgreSQL, HTTP, SSH, etc.) to the backend. Because the gateway is the sole conduit, it can enforce the following outcomes: