A newly hired contractor receives a temporary API token that lets a chat‑assistant retrieve internal documentation, bypassing pam controls that would otherwise limit privileged actions. The same token also appears in a prompt that feeds a large language model, expanding the model's context window with snippets of confidential code. The contractor can now ask the model to generate patches, and the model can inadvertently expose secrets in its response.
Context windows are the portion of recent conversation that an LLM keeps in memory. They are limited in size, so engineers often truncate or truncate‑and‑append logs, embed configuration files, or paste credential fragments to give the model enough information to answer a request. The larger the window, the higher the chance that sensitive data travels through the model and reappears in its output.
Privileged Access Management (pam) is the discipline of tightly controlling who can perform high‑impact actions on critical systems. Typical pam solutions issue short‑lived credentials, require just‑in‑time approval, and record every privileged command for audit. The focus is on the action, not on the data that may be carried along with the request.
In many organizations the two worlds operate in silos. Engineers treat the LLM prompt as a harmless string, while pam tools protect the underlying host, database, or cloud console. The request flows directly from the user to the LLM service, then from the LLM to the target system, bypassing any central enforcement point. No audit log captures the exact prompt that triggered a privileged operation, and no real‑time guard can block a dangerous command that originated inside a generated response.
This separation creates a blind spot. If a prompt unintentionally includes an admin password, the LLM may echo it back or use it to open a shell. Because the pam layer never sees the prompt, it cannot enforce policies such as masking, approval, or session recording. The result is a potential leakage of secrets and an untracked privileged action.
Why context windows and pam often clash
Both technologies aim to reduce risk, but they target different attack surfaces. Context windows expand the data surface that the model can see, while pam protects the command surface that reaches the infrastructure. When a prompt leaks a credential, pam has no visibility to intervene. Conversely, pam may block a legitimate command, but the model never knows why, leading to confusing failures for developers.
The missing enforcement layer
Identity verification, issuing an OIDC token, assigning a role, and granting a short‑lived credential, is the setup stage that decides who may start a session. This step is necessary but not sufficient for protecting the flow of data through a context window. The enforcement point must sit on the data path, where the request and response actually travel, so that every piece of traffic can be inspected, masked, approved, or recorded.
hoop.dev as the data‑path gateway
hoop.dev provides exactly that enforcement layer. It is a Layer 7 gateway that sits between identities and the target infrastructure. When a user or an automated agent connects, hoop.dev verifies the OIDC token, reads group membership, and then proxies the traffic to the underlying system. Because the proxy sits in the data path, it can apply pam‑style controls to LLM context windows.
- hoop.dev records each session, preserving the exact prompt that was sent to the model and the response that was returned.
- It can mask sensitive fields, such as API keys or passwords, before they ever leave the model’s output.
- For high‑risk commands generated by the model, hoop.dev can trigger a just‑in‑time approval workflow, requiring a human to sign off before the command reaches the target.
- All privileged actions are replayable, giving auditors a complete view of who asked what, when, and with which context.
Because hoop.dev is the only point where traffic passes, the enforcement outcomes exist only because the gateway is present. Removing hoop.dev would return the system to the original blind spot where context windows and pam operate independently.
Getting started with hoop.dev
Begin with the getting‑started guide to deploy the gateway in a Docker Compose environment. Configure an OIDC provider, Okta, Azure AD, or Google Workspace, to supply the identity tokens that pam uses for authentication. Define policies that describe which LLM prompts may contain privileged data, which responses must be masked, and which commands require approval. The learn page contains detailed examples of policy syntax and workflow integration.
Once the gateway is running, point your LLM client at the hoop.dev endpoint instead of the raw model API. The client continues to use the same libraries (for example, the OpenAI or Claude SDK), but all traffic now flows through the gateway, where pam controls are enforced.
FAQ
How does hoop.dev handle LLM context windows? The gateway treats the prompt as part of the protocol payload. It can inspect the payload for secret patterns, apply inline masking, and log the full text for audit. This gives pam‑style visibility into what data the model received.
Can hoop.dev replace existing pam tools? hoop.dev complements existing pam solutions by adding a data‑path enforcement point for LLM interactions. It does not replace identity providers or credential vaults; instead, it extends pam policies to cover the content that travels through large language models.
Is the gateway open source? Yes, hoop.dev is MIT licensed and the source is available on GitHub. You can self‑host, audit the code, and contribute improvements.
