An AI‑driven code‑completion service was granted a static AWS key and began provisioning resources without any oidc/sso oversight. The key was stored in a CI pipeline, duplicated across several job definitions, and never rotated. When the service mis‑interpreted a comment, it launched a large number of EC2 instances that quickly exhausted the account’s quota. The incident highlighted three systemic gaps: the agent operated with a long‑lived credential, there was no real‑time verification of who or what was requesting access, and every operation disappeared into the AWS audit logs without a clear link to the originating AI workflow.
Modern development pipelines increasingly rely on generative agents to write, test, and even deploy code. Those agents need to talk to cloud APIs, but treating them like ordinary users creates a dangerous blend of automation and privilege. The industry answer is to replace static secrets with identity‑based, short‑lived tokens issued through OIDC/SSO flows. By tying each request to a federated identity, a system can enforce least‑privilege policies, require just‑in‑time approval, and produce an audit trail that maps every action back to a concrete identity.
However, simply configuring an OIDC identity provider for the AI service does not close the loop. The service still contacts AWS directly, using the token it received. Without a control point on the data path, the token can be reused, the request can bypass policy checks, and no one can intervene if a command looks suspicious. What is missing is a gateway that sits between the federated identity and the AWS control plane, where every request can be inspected, approved, or blocked before it reaches the target.
Why oidc/sso matters for AI coding agents
OIDC/SSO introduces two essential guarantees. First, the credential is short‑lived and scoped to the exact set of actions the agent is allowed to perform. Second, the token is tied to a federated identity that can be audited by the organization’s identity provider. For AI agents, this means the system can revoke access the moment a model is updated or a policy changes, without having to rotate static keys across dozens of pipelines.
The missing enforcement layer
Even with OIDC, the request travels straight to AWS. At that point the cloud provider sees only a valid token and the AWS service permissions attached to it. There is no place to inject additional guardrails such as command‑level approval, real‑time masking of sensitive response fields, or session recording that captures the exact query the AI issued. Those controls belong to a data‑path component that can observe the full protocol exchange.
hoop.dev as the data‑path gateway
hoop.dev is built to occupy that exact spot. It acts as an identity‑aware proxy that terminates the OIDC flow, validates the token against the organization’s IdP, and then forwards the request to AWS only after applying policy checks. Because hoop.dev sits in the data path, it alone can enforce just‑in‑time approvals, block dangerous commands, mask sensitive values in responses, and record every session for replay. The enforcement outcomes exist only because hoop.dev is the gateway; removing it would return the architecture to the insecure direct‑connect model described earlier.
How the architecture works
1. The AI coding agent authenticates to the corporate IdP using OIDC. The IdP issues a JWT that carries the agent’s group membership and any custom claims required for policy evaluation.
2. The agent presents the token to hoop.dev instead of contacting AWS directly. hoop.dev validates the token, extracts the identity information, and checks it against the organization’s access policies.