Non-human identity for AI coding agents on Entra

During a nightly build, an AI‑powered code‑generation agent pulls a service‑principal token from Entra and immediately begins issuing database queries. The token was created for a broad data‑science workload and carries read‑write rights across multiple schemas. When the agent mis‑interprets a generated snippet, it runs a destructive command that drops a table, and the incident goes unnoticed until a downstream alert fires.

This scenario illustrates a core challenge of non-human identity. Service principals, CI jobs, and other automated identities are often granted wide‑area permissions to keep pipelines simple. Those permissions are static, rarely reviewed, and the identities themselves have no built‑in visibility into what they actually do once they reach a target system.

Entra can issue OIDC or SAML tokens that prove an automated process is who it claims to be. The token verification step decides who may start a connection, and it can enforce expiration or audience constraints. However, after the token is accepted, the request travels directly to the backend – a database, a Kubernetes API, or an SSH daemon – without any intervening control point. The connection arrives with the full set of privileges encoded in the token, and the target system sees only a regular client. No audit trail is created at the gateway, no data is masked, and no just‑in‑time approval step can intervene. In short, the Entra identity alone does not provide the runtime guardrails needed for high‑risk automation.

Why the data path must host enforcement for non-human identity

To turn a permissive token into a controlled session, the enforcement layer must sit between the identity provider and the target resource. That layer is the only place where request attributes – the user, the group membership, the requested command – can be examined before they reach the backend. By placing a gateway in the data path, you gain a single point where policies such as just‑in‑time access, command approval, inline masking, and session recording can be applied uniformly across all supported protocols.

Introducing hoop.dev as the enforcement gateway

hoop.dev fulfills this role. It receives the Entra‑issued token, validates it, and extracts the identity and group claims. It then consults policy definitions to decide whether the request may proceed, whether an approval workflow is required, and which data fields should be masked in responses. Because hoop.dev is the only component that sees the traffic before it reaches the target, every enforcement outcome originates from it.

• hoop.dev records each session, creating a replayable audit log that ties every query or command back to the originating service principal.
• hoop.dev masks sensitive columns or payload fields in real time, ensuring that downstream logs or error messages never expose secrets.
• hoop.dev blocks disallowed commands before they are executed, preventing destructive actions from ever reaching the database or host.
• hoop.dev requires just‑in‑time approval for high‑risk operations, turning a static token into a context‑aware credential.

These capabilities together turn a broad, static Entra identity into a fine‑grained, observable, and revocable access channel. The enforcement happens at the gateway, not in the identity provider or the target system, which satisfies the architectural requirement that the data path be the sole enforcement point.

Implementing the pattern with Entra

Start by registering a service principal in Entra that represents the AI coding agent. Assign it the minimal set of roles required for the workloads it must run. Next, configure hoop.dev to trust Entra as its OIDC source. The gateway will then verify incoming tokens, map group memberships to policy rules, and enforce the controls described above.

The actual steps – creating the principal, adding it to Entra groups, and pointing hoop.dev at the OIDC discovery endpoint – are covered in the getting‑started guide. The policy language and examples for masking, approval, and command blocking are explained in the learn section. Because hoop.dev is open source, you can review the implementation or contribute improvements via the repository.

FAQ

• Does hoop.dev store the Entra token? No. The token is validated on receipt and then discarded. Only the derived identity and policy decisions are retained in the audit log.
• Can I use the same gateway for multiple automated agents? Yes. Each agent presents its own Entra token, and hoop.dev applies the appropriate policy based on the token’s claims.
• What happens if an agent tries to run a command that is not allowed? hoop.dev intercepts the request, returns an error to the client, and records the attempt in the session log.

By moving enforcement to the data path, you gain visibility and control over every automated action without having to redesign your existing Entra identities.

Explore the source code, contribute improvements, and get the latest release on GitHub.