An AI coding assistant is invoked whenever a developer opens a pull request, but the team wants to grant it just-in-time access instead of a permanent credential. The assistant needs to query internal APIs, read configuration values, and sometimes push a small change to a test database. The team hands the agent a long‑lived Okta token that grants read‑only access to every internal service the assistant might touch.
That token is checked into the CI pipeline, shared among multiple jobs, and never rotated. When a bug in the assistant’s logic causes it to request a secret from a production database, the request goes straight through to the database. No engineer sees the request, no approval step exists, and the activity disappears from audit logs. The result is a classic over‑privileged, un‑audited credential that can be abused silently.
Switching to just-in-time access sounds like a fix: the agent would receive a token only for the exact operation it needs, and the token would expire after a few minutes. In practice, teams often still let the request travel directly to the target service. The connection bypasses any enforcement point, so the system still lacks real‑time approval, command‑level blocking, or session recording. The gap remains: the request reaches the resource without an observable control surface.
Placing a policy enforcement layer in the data path solves that gap. The layer sits between the identity that the agent presents and the infrastructure it wants to reach. It can verify that the request complies with the organization’s policy, request a human approval if needed, mask sensitive fields in responses, and capture a full replayable session. Because every packet passes through this gateway, no operation can escape scrutiny.
hoop.dev provides exactly that gateway. It is a Layer 7 proxy that runs a network‑resident agent inside the customer’s environment and proxies connections to databases, Kubernetes clusters, SSH hosts, and internal HTTP services. The gateway authenticates the agent’s Okta‑issued OIDC token, extracts the user or service identity, and then applies policy checks before forwarding the request.
The first piece of the puzzle is the setup of identity. The AI agent obtains an OIDC token from Okta that represents a non‑human identity. That token determines who the request is and whether it may start, but on its own it does not enforce any fine‑grained rule. The token is presented to the gateway, which validates it against Okta’s public keys and reads group membership to understand the agent’s role.
Once the token is validated, hoop.dev becomes the only place where enforcement can happen. The gateway sits in the data path, intercepting the wire‑protocol of the target service, whether it is a PostgreSQL query, a kubectl exec, or an SSH command. Because the connection is proxied, hoop.dev can inject just‑in‑time approval workflows, block dangerous commands, and mask fields such as passwords or credit‑card numbers in real time.