Imagine a fleet of autonomous agents that can act on behalf of your organization, each carrying a non-human identity that is auditable, revocable, and scoped to the exact resources it needs. In the ideal state, those agents never see long‑lived secrets, every command they issue is recorded, sensitive data is hidden from logs, and any risky operation must be approved in real time before it runs.
Today many teams ship agents with static API keys or embed service‑account credentials directly in code. Those secrets are copied across repositories, stored in CI pipelines, and often shared among multiple services. When an incident occurs, it is hard to tell which agent performed which action, and the lack of real‑time approval means a malicious or buggy agent can cause damage before anyone notices.
Using Entra as the identity provider gives you a non-human identity token that tells the system who is making a request. However, the token alone does not prevent the agent from connecting straight to the target, bypassing any guardrails. The request still reaches the database, Kubernetes cluster, or SSH host without an audit trail, without inline masking of sensitive fields, and without a chance to halt a dangerous command.
hoop.dev solves this gap by sitting in the data path between the Entra‑issued token and the infrastructure resource. The gateway verifies the non-human identity, then inspects every protocol message. It can mask sensitive columns in a database response, block destructive shell commands, route suspicious queries to a human approver, and record the entire session for replay. Because hoop.dev is the only point where traffic passes, all enforcement outcomes are guaranteed to happen.
Why non‑human identity matters for Entra
Non‑human identities let you grant permissions without tying access to a person’s credentials. They are ideal for automation, CI/CD pipelines, and AI‑driven agents. Entra can issue short‑lived OIDC tokens that carry group membership and attribute claims, enabling fine‑grained policy decisions. Yet without a gateway, those tokens simply act as bearer credentials, giving the holder unrestricted network access to the target.
How hoop.dev enforces policy in the data path
The enforcement flow begins with the Entra token. hoop.dev validates the token, extracts the identity, and checks the requested operation against policies that you define. If the operation is allowed, it is forwarded to the target; if it requires approval, hoop.dev pauses the request and notifies an approver. When the response returns, hoop.dev can mask fields such as credit‑card numbers or personal identifiers before they reach the agent. Every request and response is logged, and a replayable session record is stored for later audit.
Because the gateway holds the credential for the downstream resource, the agent never sees the password, private key, or IAM role used to connect. This eliminates credential sprawl and reduces the blast radius of a compromised agent.
Capturing the audit trail you need
Every session that passes through hoop.dev is persisted with metadata that includes the non‑human identity, timestamp, source IP, and the exact command or query executed. This data satisfies internal compliance checks and provides the evidence required for external audits. The replay feature lets you reconstruct the exact sequence of actions, which is essential for forensic investigations.
Implementing the solution
Start by deploying the hoop.dev gateway in the same network segment as the resources you want to protect. The quick‑start guide walks you through a Docker Compose deployment that includes built‑in OIDC validation against Entra. Register each target, PostgreSQL, Kubernetes, SSH, etc., and configure the gateway to store the downstream credentials. Then define policies that tie Entra group claims to the actions you want to allow, mask, or require approval for.
When an autonomous agent runs, it presents its Entra token to hoop.dev. The gateway handles the rest: authentication, policy enforcement, masking, approval, and recording. No changes to the agent’s code are required; it continues to use its standard client libraries.
FAQ
- Do I need to modify my existing agents? No. Agents continue to use their native clients (psql, kubectl, ssh, etc.). hoop.dev intercepts the traffic transparently.
- Can I use hoop.dev with other identity providers? Yes. The gateway supports any OIDC or SAML provider, but the example here shows Entra because it is a common source of non‑human identities.
- What happens if an approval is denied? hoop.dev aborts the request and returns an error to the agent, preventing the operation from reaching the target.
For a step‑by‑step walkthrough, see the getting‑started guide. The full source code and deployment manifests are available on GitHub. Additional details about policy configuration and masking can be found in the learn section.
