Do you know whether a shared service account or a purpose‑built non-human identity is really protecting your AI agents?
Most internal SaaS teams hand a static credential to every automation script, chatbot, or LLM‑powered assistant. The credential lives in a config file, a CI secret store, or even a hard‑coded string. When an AI agent needs to read a database or invoke a Kubernetes API, it simply presents the same username and password that every human operator also uses. The result is a single point of failure: any compromise of that credential grants unrestricted access to every downstream system, and the organization loses visibility into who ran what command.
That reality is uncomfortable, but it is the starting point for most organizations. The question is whether swapping the credential for a non-human identity solves the problem, or whether additional controls are still required.
Current practice: shared service accounts
In the shared‑account model, the team creates one service account per application or per environment. The account has a set of permissions that cover the broad range of tasks the application performs. Engineers copy the secret into deployment pipelines, and AI agents inherit the same secret from the same pipeline.
The benefits are clear: provisioning is simple, and the same secret works across multiple tools. The drawbacks, however, are severe. Because the same credential is used for every request, the system cannot distinguish a legitimate AI‑generated query from a malicious one. Auditing tools see only the service‑account name, not the originating identity. No inline data masking occurs, and there is no way to pause a risky command for human approval. If the secret leaks, the attacker gains the same level of access that the AI agent would have, and the breach can spread quickly across databases, Kubernetes clusters, and internal HTTP services.
Introducing non-human identity
Non-human identity replaces a static secret with a token that is issued to a specific automation entity. The token is typically obtained via an OIDC flow, where the AI agent authenticates as a machine client and receives a short‑lived JWT that encodes its group membership and intended scopes.
This approach improves credential hygiene. Tokens expire, can be revoked centrally, and can carry fine‑grained claims that limit the agent to a subset of operations. From an identity perspective, the system now knows which agent is making the request.
Nevertheless, the request still travels directly to the target service. The gateway that sits between the agent and the resource does not intervene. The target sees only a valid JWT and honors the claims, but it does not record the exact query, mask sensitive fields, or enforce a just‑in‑time approval workflow. In other words, non-human identity fixes the authentication surface but leaves the enforcement surface untouched.
Why a data‑path gateway is required
Effective risk mitigation for AI agents demands more than identity verification. The organization must be able to:
- Audit every command that an agent issues, including the exact query text and the result set.
- Mask personally identifiable information or secrets that appear in responses, so downstream logs never expose them.
- Block dangerous commands, such as destructive schema changes, before they reach the database.
- Require a human approver for high‑risk operations, creating a deliberate pause that prevents accidental damage.
- Record the entire session for replay, enabling forensic analysis after an incident.
All of these controls must sit on the data path – the exact point where traffic flows from the agent to the target. If the enforcement sits elsewhere, the target can be bypassed, or the agent could modify the payload before it reaches the guardrails.
How hoop.dev provides the missing enforcement
hoop.dev acts as a Layer 7 gateway that intercepts every request after the non-human identity has been verified. The gateway runs an agent inside the customer network, so the target never sees the credential directly. hoop.dev then applies the following policies:
- Session recording: hoop.dev records each interaction, storing a replayable log that auditors can review.
- Inline masking: Sensitive fields such as credit‑card numbers or API keys are redacted in real time before they are written to logs or returned to the caller.
- Command blocking: Dangerous statements, like DROP DATABASE or destructive Kubernetes deletes, are intercepted and rejected.
- Just‑in‑time approval: When a request matches a high‑risk policy, hoop.dev routes it to an approver who must explicitly allow the operation.
- Scoped access: The gateway enforces the least‑privilege claims embedded in the non‑human identity token, ensuring the agent cannot exceed its intended scope.
Because hoop.dev sits in the data path, all of these outcomes are guaranteed. Removing hoop.dev would eliminate the masking, approval, and recording capabilities, even though the non‑human identity token would still be valid.
When each approach is enough
If an organization only needs to rotate credentials regularly and does not store sensitive data in responses, a non‑human identity may be sufficient. The short‑lived token reduces the blast radius of a leak, and the identity provider can enforce basic scopes.
However, most internal SaaS platforms expose logs, query results, or configuration files that contain secrets. In those environments, the lack of inline masking and session replay creates compliance gaps. The risk of an AI agent unintentionally issuing a destructive command also remains high without a gatekeeper that can block or require approval.
Therefore, the safe default is to combine non‑human identity with a data‑path gateway. The identity layer authenticates the agent, while hoop.dev enforces the runtime policies that protect the resource.
Getting started
To experiment with this pattern, follow the getting started guide for hoop.dev. The documentation explains how to register a non‑human identity, configure a connection to your database or Kubernetes cluster, and enable masking and approval policies. For a deeper dive into the feature set, see the learn page.
Explore the source code on GitHub: https://github.com/hoophq/hoop.
