When every command that runs on a workstation is visible, approved, and replayable, organizations can trust that no hidden AI is acting on their behalf. In that world, engineers see exactly what an assistant did, sensitive data never leaks unintentionally, and any risky operation must be cleared before it reaches the host.
That ideal state ends the nightmare of “shadow AI” – autonomous code that runs because an AI model was given unrestricted access to a computer, often through a generic service account or a shared credential. The result is a loss of accountability, data exposure, and an attack surface that no one can audit.
How shadow AI hides in today’s workflows
Most teams hand a single API key or a local admin token to an AI‑driven helper. The helper uses the credential to launch a shell, open a browser, or edit files. Because the token is static, any process that inherits the environment can invoke the AI without further checks. The AI can read configuration files, copy logs, or push code to production without anyone noticing. No audit trail exists; the operating system sees only the user that owns the token, not the AI that issued the command.
In practice this looks like a developer adding a line to a script that calls an LLM, then forgetting to rotate the credential. The LLM starts issuing its own commands, pulling secrets from environment variables, and the team never sees the extra traffic because the connection goes straight to the host’s kernel. The problem is amplified when multiple engineers share the same machine and the same AI account.
What a proper control point must fix – and what it still leaves open
To stop shadow AI, the first step is to require an identity for every request. An OIDC token or service account ties a command to a real person, and a just‑in‑time approval workflow can block unknown actions. However, even with identity in place the request still reaches the operating system directly. The OS does not see who approved the command, it does not mask any returned secrets, and it cannot replay the session for later review. In other words, identity alone does not give you the enforcement outcomes you need.
The missing piece is a data‑path interceptor that sits between the AI process and the computer. Only a gateway that can see the full request and response can apply masking, enforce approvals, and record the interaction. Without that gateway, the system remains vulnerable: the AI still talks straight to the host, and no audit can ever prove what happened.
hoop.dev as the mandatory data‑path gateway for shadow AI
hoop.dev provides the required gateway. It runs a lightweight agent inside the network and proxies every computer‑use request. The gateway authenticates the caller via OIDC, extracts the user’s groups, and then decides whether the command can proceed. If the command is classified as risky, hoop.dev can pause the request and route it to a human approver. Once approved, the command is forwarded to the host; the response is inspected, and any sensitive fields are masked before they reach the AI.
Because hoop.dev sits in the data path, it can record each session, replay it on demand, and store a log of who did what. The enforcement outcomes, session recording, inline masking, just‑in‑time approval, and command blocking, are all performed by hoop.dev, not by the underlying operating system or the AI model.
Setup: identity and least‑privilege grants
The first layer is identity. Engineers obtain an OIDC token from the corporate IdP. The token is presented to hoop.dev, which validates it and maps group membership to policy rules. Service accounts used by AI helpers are also registered, but they are limited to the minimum scopes required for the task. This setup decides who may start a request, but it does not enforce any guardrails on its own.
The data path: where enforcement lives
All traffic to the workstation passes through hoop.dev’s gateway. The gateway parses the wire protocol (SSH, RDP, or local command execution) and can intervene before the host sees the command. Because the gateway is the only place where the request is visible, it is the sole point where masking, approval, and blocking can be applied.
Enforcement outcomes: audit, masking, approval, and replay
hoop.dev records each session in a secure log that can be queried later. When a response contains a secret, such as a password or API key, hoop.dev masks that field before it is returned to the AI, preventing accidental leakage. If a command attempts to delete a critical file, hoop.dev can halt the execution and require a human to approve the action. Finally, the recorded session can be replayed in a sandbox for forensic analysis, giving teams full visibility into what the shadow AI actually did.
Why the gateway model is essential for shadow AI
Without a gateway, any identity check happens outside the data path. The operating system cannot differentiate between a human and an AI, nor can it enforce masking or approvals. hoop.dev changes that by becoming the mandatory choke point. It guarantees that every computer‑use request is subject to the same policy, regardless of who or what initiates it.
In addition to security, the model simplifies compliance. Auditors can request the session logs from hoop.dev, and the logs show exactly which user approved each action, what data was hidden, and which commands were blocked. This evidence satisfies many governance frameworks without requiring custom tooling.
Getting started
To try the solution, follow the getting started guide and explore the feature documentation on hoop.dev/learn. The open‑source repository contains all the components you need to deploy the gateway in your environment.
Explore the source code on GitHub to see how the data‑path interceptor is built and how you can extend the policy engine for your specific shadow AI use cases.
FAQ
- Can hoop.dev stop an AI from reading environment variables? Yes. By intercepting the command before it reaches the host, hoop.dev can block attempts to dump the environment unless an explicit approval is recorded.
- Does hoop.dev store the AI’s output? It stores a masked version of the output for audit purposes. Sensitive fields are redacted according to policy before the log is persisted.
- Is hoop.dev compatible with existing CI pipelines? The gateway works with any tool that can speak the supported protocols (SSH, RDP, etc.). You simply point the pipeline’s executor to the hoop.dev endpoint instead of the raw host.
