A compromised machine identity can let an attacker roam your internal APIs unchecked.
Most teams that run MCP (Machine Code Proxy) services embed static service accounts or long‑lived API keys directly in the application code or configuration files. Those credentials are shared across dozens of containers, never rotated, and the connection to the backend proceeds without any visibility. When a breach occurs, there is no record of which request performed which operation, no way to block a dangerous command, and no audit trail to satisfy compliance or forensic investigations.
Why machine identity matters for MCP
Machine identities give each service a cryptographic proof of who it is, typically an OIDC token or a short‑lived credential issued by an identity provider. In the MCP context, a machine identity should limit the service to exactly the API endpoints it needs, and it should expire quickly enough that a stolen token becomes useless after a few minutes. Without a proper enforcement point, the token is simply passed through to the target, and the MCP server cannot verify that the request complies with policy, mask sensitive fields, or require a human approval for privileged actions.
The missing enforcement layer
Introducing OIDC‑based machine identities is a necessary step: it tells the system who is calling. However, the request still travels directly from the MCP client to the backend service. At that point the identity is no longer under control, so there is no guarantee that the request will be recorded, that sensitive data will be redacted, or that a risky command will be intercepted. The setup alone does not provide just‑in‑time approval, command‑level audit, or session replay. Those controls require a gateway that sits on the data path.
Embedding hoop.dev as the data‑path gateway
hoop.dev is a Layer 7 gateway that sits between the machine identity token and the MCP target. The gateway runs an agent inside the same network as the MCP service, holds the backend credentials, and terminates the client connection. Because every request passes through hoop.dev, it can enforce policy in real time. hoop.dev validates the OIDC token, checks group membership, and then applies a set of guardrails before forwarding the request.
All enforcement outcomes happen because hoop.dev occupies the data path. It records each session for replay, masks fields that match configured patterns, routes privileged commands to a human approver, and can block disallowed operations entirely. The gateway also ensures that the MCP client never sees the backend credential, eliminating credential sprawl.
Key enforcement outcomes you gain
- Session recording: hoop.dev captures the full request and response stream, enabling later replay for audit or incident investigation.
- Inline data masking: Sensitive values such as passwords, tokens, or personal identifiers are redacted in the response before they reach the client.
- Just‑in‑time approval: When a request matches a high‑risk pattern, hoop.dev pauses the flow and routes the operation to an approver defined in your identity provider.
- Command blocking: Forbidden commands are rejected at the gateway, preventing execution on the MCP backend.
- Credential isolation: The backend credential is stored only in the gateway; the MCP client never receives it.
Getting started with hoop.dev for MCP
To protect your MCP services with machine identities, deploy the hoop.dev gateway in the same network segment as the MCP backend. Register the MCP endpoint as a connection in the gateway, configure the OIDC provider that issues your machine tokens, and define the guardrails you need, masking rules, approval policies, and command blocklists. Once the gateway is running, MCP clients connect through it using their standard client libraries; the gateway transparently enforces the policies you have defined.
For the exact deployment steps, see the getting‑started guide. The guide walks you through deploying the gateway with Docker Compose or Kubernetes, wiring up your OIDC provider, and creating the first MCP connection. Detailed feature documentation is available on the learn page, where you can explore masking patterns, approval workflows, and session replay capabilities.
All of the configuration lives in the open‑source repository, so you can audit the code yourself or contribute improvements. Explore the source code on GitHub to see how the gateway implements the data‑path enforcement logic.
FAQ
Do I need to change my existing MCP client code?
No. hoop.dev acts as a transparent proxy. The client continues to use its standard library (for example, the MCP SDK or HTTP client) and simply points to the gateway address instead of the original backend.
What happens if the OIDC token expires mid‑session?
hoop.dev validates the token on each request. When the token is no longer valid, the gateway rejects the request and returns an authentication error, forcing the client to obtain a fresh token.
Can I audit who approved a privileged operation?
Yes. Every approval event is recorded in the session log that hoop.dev stores. The log includes the approver’s identity, the request details, and the decision outcome, providing a complete audit trail.
