Agentic AI that can run commands on production systems without a human in the loop creates a non-human identity risk that is a massive security liability.
Understanding non-human identity is essential for any organization that lets an AI interact with critical infrastructure.
Most organizations treat an AI assistant like any other piece of automation: they embed a long‑lived service account password in a configuration file, grant the account broad database and SSH privileges, and let the model call the underlying CLI directly. The credential is often shared across multiple pipelines, rarely rotated, and never tied to an individual user. When the model makes a mistake, issuing a DELETE statement, opening a reverse shell, or dumping a secret column, there is no independent audit trail, no way to intervene, and no evidence that the request originated from a non‑human process.
That unsanitized state leaves three critical gaps. First, the identity of the caller is opaque; the system logs only a generic service account name. Second, the request travels straight to the target database, Kubernetes API, or SSH daemon, bypassing any gate that could inspect the payload. Third, there is no built‑in mechanism to mask sensitive fields, require human approval for risky commands, or record the session for later review. The result is a blind spot that can be exploited for data exfiltration, privilege escalation, or inadvertent destructive actions.
Why non-human identity matters for agentic AI
Introducing a dedicated non-human identity solves the visibility problem. By issuing short‑lived OIDC tokens to the AI service, the platform can prove that the request came from a machine, not a person, and can attach attributes such as purpose, risk tier, and expiration. However, merely having a token does not close the other gaps. The request still reaches the backend directly, meaning the system cannot apply inline masking, enforce just‑in‑time (JIT) approval, or capture a replayable audit record.
The missing piece is a control point that sits on the data path, the exact place where the request leaves the AI runtime and enters the target service. Only a gateway positioned there can inspect the protocol, enforce policy, and produce evidence that the organization can rely on for compliance and incident response.
How hoop.dev provides the required data‑path enforcement
hoop.dev is built to be that gateway. It runs a network‑resident agent next to each protected resource and proxies every connection that originates from a non‑human identity. The gateway validates the OIDC token, extracts the AI’s attributes, and then applies a series of enforcement outcomes before the request ever touches the target:
- Session recording: hoop.dev captures the full command stream and response payload, creating a replayable log that ties every action to the originating non‑human identity.
- Inline data masking: Sensitive columns or fields in database responses are redacted in real time, preventing the model from seeing secrets it does not need.
- Just‑in‑time approval: High‑risk commands trigger a workflow that requires a human approver before the gateway forwards the request.
- Command blocking: Patterns that match destructive or suspicious operations are dropped, and the AI receives a safe error response.
All of these outcomes are possible only because hoop.dev sits in the data path. The setup phase, defining the AI’s OIDC client, assigning it appropriate scopes, and deploying the agent, decides who may start a session, but the enforcement itself happens inside the gateway.
Practical steps to adopt non‑human identity with hoop.dev
- Register the AI service as an OIDC client in your identity provider. Give it a short‑lived token lifespan and attach attributes that describe its intended use case.
- Deploy the hoop.dev gateway alongside each target (PostgreSQL, Kubernetes, SSH, etc.). The official quick‑start guide walks you through a Docker‑Compose deployment that includes built‑in OIDC verification.
- Configure a connection in hoop.dev for the resource. The gateway stores the credential, so the AI never obtains the underlying secret or private key.
- Define policy rules that match your risk appetite: which commands require approval, which fields to mask, and which operations are outright blocked.
- Enable session recording and point the logs to a secure storage bucket. The recorded sessions become the audit evidence you need for investigations.
For detailed instructions, see the getting‑started documentation and the broader learn section. Those pages show how to wire the OIDC client, launch the agent, and write policy rules without exposing any secrets to the AI.
FAQ
What exactly is a non‑human identity?
A non‑human identity is a machine‑issued credential, typically an OIDC token, that represents a service, script, or AI model rather than a person. It can carry attributes that inform policy decisions, such as risk level or allowed operations.
Can hoop.dev block a command after the AI has already sent it?
Yes. Because hoop.dev intercepts traffic at the protocol layer, it can examine the command payload before it reaches the backend. If the command matches a block rule, hoop.dev drops it and returns an error to the caller.
Do I still need to rotate credentials for the underlying resources?
hoop.dev stores the credentials centrally and rotates them on a schedule you define. The AI never touches the raw secret, so rotation does not require changes to the AI code.
By treating agentic AI as a first‑class non‑human identity and forcing every interaction through a gateway, organizations gain visibility, control, and auditability that would otherwise be impossible. hoop.dev makes that architecture practical and open source.
Explore the open‑source repository on GitHub to get started.
