Configuring AI coding agents access to Entra with non-human identity

When a new AI‑powered code‑review bot is added to a CI pipeline, the team often copies a long‑lived service account key into the repository so the bot can fetch secrets from the cloud. The key lives in the code base, can be checked out by anyone with repo access, and never expires. The bot can then call any downstream service that trusts the account, including the organization’s Entra‑protected APIs. Because the bot is using a non-human identity that is not scoped or audited, the result is a credential that is both over‑privileged and impossible to trace.

Why non‑human identity matters for AI coding agents

AI agents need an identity that is not tied to a human user, but the identity must still be verifiable, revocable, and scoped to the exact set of actions the bot requires. A non‑human identity issued by Entra provides a token that proves the agent’s membership in a service‑account group. However, Entra alone does not enforce runtime policies such as just‑in‑time (JIT) approval, command‑level blocking, or session recording. Those enforcement points must sit on the path between the token and the target infrastructure.

How hoop.dev enforces policies for Entra‑issued identities

hoop.dev acts as the Layer 7 gateway that sits between the AI agent and the resources it reaches, databases, Kubernetes clusters, SSH hosts, or internal HTTP services. The gateway performs three distinct roles:

• Setup: Entra authenticates the agent and issues a non‑human token. hoop.dev validates that token and extracts the group membership, which determines whether the request may start.
• Data path: All traffic from the agent to the target flows through hoop.dev. This is the only place where policy can be applied because the agent never sees the downstream credentials and cannot bypass the gateway.
• Enforcement outcomes: While the connection passes through hoop.dev, the gateway can require a JIT approval before a risky command is executed, mask sensitive fields in responses, block prohibited commands, and record the entire session for replay. Those capabilities exist only because hoop.dev sits in the data path.

For example, when the AI bot attempts to run a kubectl exec against a production cluster, hoop.dev checks the token’s groups, prompts an authorized engineer for approval, and only then forwards the request. If the command contains a forbidden pattern, hoop.dev blocks it and logs the attempt. Every step is captured in an audit trail that can be queried later.

Implementing the gateway for AI agents

Begin with the getting started guide. Deploy the hoop.dev gateway using the provided Docker Compose file or the Kubernetes manifest; both options place the gateway on the same network segment as the resources the AI agents will access. The deployment includes an agent that holds the credentials for each target, so the agents never need to embed secrets.

Next, register Entra as the identity provider in hoop.dev’s configuration. This tells hoop.dev to accept OIDC or SAML tokens issued by Entra, verify their signatures, and read the group claims. Create a service‑account group in Entra that contains the AI bot’s client ID. Assign the minimal set of permissions to that group, only the namespaces and databases the bot needs.

Finally, define the policies that the gateway should enforce. In the UI or via the declarative policy file, specify which commands require JIT approval, which response fields must be masked (for example, API keys returned from a secret‑management service), and the retention period for session recordings. Because the policies are attached to the gateway, they apply uniformly to every connection the AI agent makes, regardless of the underlying target.

When the AI bot runs, it authenticates to Entra, receives a short‑lived token, and connects to hoop.dev with its standard client (e.g., the hoop.dev CLI or a regular kubectl wrapper). hoop.dev validates the token, enforces the policies, and forwards the request to the target. The bot never sees the target’s credential, and every action is auditable.

Key benefits of the approach

• Least‑privilege tokens: Entra issues short‑lived, scoped tokens for the AI agent, eliminating long‑lived keys.
• Just‑in‑time approval: hoop.dev forces an engineer to approve risky operations, reducing accidental damage.
• Inline data masking: Sensitive fields are redacted before they reach the AI agent, protecting secrets.
• Full session audit: Every command and response is recorded, enabling replay for investigations.
• Zero credential exposure: The AI agent never handles the downstream credentials; the gateway’s agent does.

Next steps

Review the learn page for deeper explanations of each enforcement feature. When you are ready to try it in your environment, clone the open‑source repository and follow the deployment instructions.

Explore the open‑source repository on GitHub to see the full configuration options and contribute improvements.

FAQ

Can I use existing service accounts without changing them?

hoop.dev requires the downstream credential to be stored in the gateway’s agent. Existing service accounts can be imported, but the agent will present them to the target, not the AI bot.

What happens if the Entra token is compromised?

The token is short‑lived and scoped by group membership. Even if an attacker obtains it, hoop.dev will still enforce JIT approval and masking before any privileged command is allowed.

Do I need to modify my AI bot’s code?

No. The bot continues to use its normal client libraries; the only change is the endpoint it connects to, now the hoop.dev gateway.