When an AI coding agent can invoke internal services without a clear audit trail, the organization loses visibility into who ran what code and when. Relying on oidc/sso alone without runtime enforcement leaves a gap that can be exploited. A mis‑configured permission set can let the agent read production secrets, push unwanted changes, or even exfiltrate data, all without any human sign‑off. The cost of a silent breach grows quickly: lost customer trust, compliance penalties, and the effort required to rebuild a clean environment.
OpenID Connect (OIDC) and SAML‑based single sign‑on (SSO) provide a strong identity foundation for both humans and non‑human actors. By issuing short‑lived tokens that carry group membership, Entra can tell a service whether the caller belongs to a privileged team. However, token verification alone does not stop an agent from making a destructive request once it has a valid credential. The missing piece is a control surface that sits between the token‑bearing identity and the infrastructure it wants to reach.
Why OIDC/SSO alone is not enough for AI agents
OIDC/SSO tells the gateway "who" is making a request, but it does not enforce "what" they may do on a per‑command basis. An AI coding agent typically runs many short‑lived operations: fetching schema, applying migrations, reading logs, or writing configuration files. Each of those actions carries a different risk level. Without a runtime guard, the agent can chain together benign calls into a harmful workflow, and the organization has no record of the intermediate steps.
Furthermore, AI agents often operate under service accounts that have broader scopes than a human would ever need. The principle of least privilege is hard to enforce at the token level because the token reflects the service account’s static permissions, not the context of a specific task.
The missing enforcement layer
What is required is a layer‑7 gateway that can inspect traffic at the protocol level, apply just‑in‑time (JIT) approvals, mask sensitive response fields, and record every interaction for replay. This gateway must sit on the data path between the Entra‑issued identity and the target resource, whether that resource is a database, a Kubernetes cluster, or an SSH host. By placing policy enforcement here, the organization gains:
- Command‑level audit that shows exactly which queries or commands the agent executed.
- Inline masking of secrets returned by a database, preventing the agent from seeing raw credentials.
- JIT approval workflows that pause risky operations until a human reviewer grants temporary permission.
- Full session recording for forensic analysis or compliance evidence.
Introducing a layer‑7 gateway
hoop.dev provides the required data‑path gateway. It authenticates incoming OIDC/SSO tokens against Entra, extracts the caller’s groups, and then enforces policy before the request reaches the backend resource. Because hoop.dev sits in the middle, it can block, mask, or route a request without the agent ever seeing the underlying credentials.
When an AI coding agent presents a valid Entra token, hoop.dev:
- Verifies the token signature and checks group membership.
- Looks up the requested target (for example, a PostgreSQL instance) and applies the appropriate guardrails.
- Records the full session, including timestamps, commands issued, and responses (with masked fields where configured).
- Triggers an approval workflow if the requested operation matches a high‑risk policy rule.
All of these enforcement outcomes happen because hoop.dev resides in the data path. Without hoop.dev, the token would travel directly to the database, and none of the above controls would be applied.
Architectural flow for Entra‑backed AI agents
The end‑to‑end flow looks like this:
- The AI coding agent authenticates to Entra and receives an OIDC token that represents a service account.
- The agent initiates a connection to the target resource using its normal client (psql, kubectl, ssh, etc.).
- The request is routed to hoop.dev, which acts as a reverse proxy for the chosen protocol.
- hoop.dev validates the token, extracts group claims, and consults the policy store to decide if the operation is allowed, needs masking, or requires human approval.
- If approval is needed, hoop.dev pauses the request and notifies the designated reviewer. Once approved, the request proceeds.
- The target resource processes the command, returns a response, and hoop.dev applies any configured inline masking before forwarding the data back to the agent.
- The entire session is persisted for replay, audit, and compliance reporting.
This architecture ensures that every AI‑driven action is bound by the same governance that human operators receive, while still allowing the speed and flexibility that AI coding agents need.
Benefits and next steps
By combining Entra’s OIDC/SSO identity backbone with hoop.dev’s data‑path enforcement, organizations achieve:
- Zero‑trust runtime access: No credential ever leaves the gateway, and every request is verified at execution time.
- Fine‑grained audit trails: Each command, response, and approval decision is recorded, simplifying forensic investigations.
- Reduced blast radius: High‑risk operations are gated behind JIT approvals, limiting accidental or malicious damage.
- Compliance‑ready evidence: Session logs and approval records can be exported for audit purposes.
To get started, follow the getting‑started guide and review the learn section for detailed explanations of guardrails, masking policies, and approval workflows. The open‑source repository on GitHub contains the Docker Compose quick‑start, Helm charts, and example configurations.
FAQ
Do I need to change my existing Entra applications?
No. hoop.dev acts as a relying party for Entra, so existing OIDC clients continue to work. You only add the gateway as a proxy for the target resources you want to protect.
Can I apply different policies per AI agent?
Yes. Policies are evaluated against the group claims in the OIDC token, allowing you to assign distinct guardrails to different service accounts or teams.
What happens if the gateway is unavailable?
Because hoop.dev is the only path to the protected resource, a failure would block access. Deploy the gateway in a highly available configuration (e.g., replicated containers or Kubernetes pods) to avoid a single point of failure.
Explore the open‑source repository on GitHub to see the full implementation and contribute improvements: https://github.com/hoophq/hoop.
