A recently offboarded contractor left a service‑account token in a CI pipeline that an internal AI assistant still uses to run database queries. The token never expires, and the assistant can reach production clusters without any human review. The organization assumes the AI tool is harmless because the credential was granted once and never changes, but without just-in-time access the risk remains.
In practice, that assumption is dangerous. Most teams hand out standing access to AI agents by embedding static passwords, API keys, or service‑account secrets in configuration files. The gateway that the agents talk to is bypassed entirely, so there is no record of which query was issued, no way to hide personally identifiable information that might appear in results, and no chance to stop a destructive command before it runs. The risk is amplified on‑prem because the infrastructure is under direct control of internal processes and cannot rely on cloud‑native logging services.
Why just-in-time access matters for AI agents
Just-in-time access replaces a permanent secret with a short‑lived, identity‑driven grant that is issued only when a specific request is made. The request carries the caller’s identity, group membership, and any contextual attributes such as time of day or purpose. The policy engine can evaluate those attributes and either approve the request automatically, route it to a human approver, or reject it outright.
This model eliminates the static secret that fuels the scenario above. An AI agent that needs to read a table must first obtain a time‑boxed token that reflects the current user’s intent. If the request is malformed or originates from an unexpected service account, the policy can refuse it before any traffic reaches the database.
Standing access: the hidden attack surface
Standing access leaves the gate open at all times. The credential is stored once, often in a repository or environment variable, and any process that can read that location can use it. Because the connection is made directly to the target, the organization loses three critical controls:
- Visibility: there is no central point that can log every command or query.
- Data protection: response payloads travel unfiltered, exposing credit‑card numbers, SSNs, or internal identifiers.
- Intervention: a malicious or buggy AI routine can issue a destructive command without any checkpoint.
Even if the environment enforces least‑privilege IAM roles, the standing secret still grants that privilege continuously. The privilege cannot be revoked on a per‑request basis, and there is no audit trail to prove who exercised it.
How hoop.dev provides the data‑path enforcement you need
hoop.dev sits in the Layer 7 data path between the AI agent and the on‑prem resource. It receives the short‑lived token issued by the just‑in‑time workflow, validates the identity, and then proxies the connection to the target. Because the gateway is the only point where traffic passes, hoop.dev can enforce every control that standing access lacks.
When a request arrives, hoop.dev records the entire session, including the exact query text and the response payload. It can mask fields that match configured patterns, ensuring that sensitive data never leaves the gateway in clear text. If a command matches a risky pattern, such as a DROP DATABASE or a mass‑delete statement, hoop.dev blocks it before it reaches the database. For operations that require human oversight, hoop.dev routes the request to an approver and only forwards it once approval is granted.
All of these outcomes exist because hoop.dev occupies the data path. The identity check (the setup) determines who may ask for a grant, but the enforcement, audit, masking, blocking, and just‑in‑time approval, happens inside hoop.dev. Without the gateway, the same identity token would travel straight to the database, and none of the protections would be applied.
Comparing the two approaches
| Aspect | Standing access | Just‑in‑time access with hoop.dev |
|---|
| Credential lifespan | Static, long‑lived | Ephemeral, request‑bound |
| Visibility | None at the gateway level | Full session recording |
| Data masking | Not possible without custom code | Inline masking at protocol layer |
| Risk of accidental destruction | High – commands flow unchecked | Command‑level blocking and approval |
| Compliance evidence | Fragmented, scattered logs | Centralized audit trail for auditors |
Getting started
To move from standing access to a just‑in‑time model, begin by deploying hoop.dev in your on‑prem network. The quick‑start guide walks you through setting up the gateway, configuring OIDC authentication, and defining masking rules. Once the gateway is running, register your database or other target as a connection and enable just‑in‑time policies for the AI service account.
For step‑by‑step instructions, see the getting‑started documentation and the broader feature overview at hoop.dev/learn. The repository contains all the artifacts you need to self‑host and customize the gateway for your environment.
FAQ
Does just‑in‑time access eliminate the need for IAM roles?No. IAM roles still define the maximum privileges an agent can receive. Just‑in‑time access narrows the time window and adds runtime enforcement.Can hoop.dev mask data in real time?Yes. hoop.dev inspects responses at the protocol layer and replaces configured fields before they are returned to the caller.What happens if an approval is delayed?The request remains pending in hoop.dev until a designated approver acts. No traffic reaches the target while the request is waiting.
Explore the source code, contribute improvements, and see how the community is building safer AI‑driven workflows: GitHub repository.
