How can you give an MCP server a non-human identity that is governed by Okta without exposing static secrets?
Most teams today embed a service account password or API key directly in CI pipelines, configuration files, or container images. The same credential is reused across dozens of jobs, and anyone who can read the repo or the build logs can replay it against the MCP server. There is no central log of who invoked which command, no way to stop a rogue request, and no visibility into what data was returned.
This practice inflates the blast radius of a single leak. An attacker who captures the secret can enumerate the server, run destructive commands, and exfiltrate proprietary model weights or training data. Because the connection bypasses any enforcement point, the organization loses the ability to enforce least‑privilege, to require human approval for high‑risk actions, or to mask sensitive fields in the response.
In a cloud‑native environment, a non-human identity is typically represented by a service account, a CI runner, or an AI‑driven agent. The modern approach is to let Okta issue an OIDC or SAML token for that identity, letting the token carry the subject, group membership, and expiration. The token tells the downstream system who is calling, but without a gateway the request still travels straight to the MCP server, carrying no guardrails.
Even with Okta‑issued tokens, the request reaches the target unmediated. No approval workflow can interrupt a dangerous command, no inline masking can redact confidential model parameters, and no session recording can capture the interaction for later review. The organization still lacks the evidence auditors demand and the real‑time protection needed for production AI workloads.
Enter hoop.dev. It sits in the data path between the non-human identity and the MCP server, acting as an identity‑aware proxy that enforces policy on every request.
Why non-human identity needs a gateway
The first step is to configure Okta as the source of OIDC tokens for your service accounts. hoop.dev validates each token, extracts the groups, and maps them to permission policies. This setup decides who the request is and whether it may start, but it does not enforce any action on its own.
Once the token is verified, hoop.dev becomes the data path. It terminates the client connection, opens a new connection to the MCP server, and streams traffic through its inspection engine. Because the gateway is the only place the traffic passes, it can apply enforcement outcomes that would otherwise be impossible.
Enforcement outcomes provided by hoop.dev
- Just‑in‑time approval: before a command that modifies model state is executed, hoop.dev can pause the request and route it to an approved approver. The command proceeds only after explicit consent.
- Inline data masking: responses containing API keys, tokens, or personal data are redacted in real time, ensuring downstream logs never contain raw secrets.
- Command blocking: dangerous operations such as “delete all models” are identified and rejected before they reach the server.
- Session recording and replay: every interaction is recorded in a tamper‑evident store, giving you a complete audit trail for forensic analysis.
All of these outcomes are possible only because hoop.dev is the sole enforcement point. If you removed hoop.dev and left only Okta token verification, none of the above protections would exist.
Getting started with Okta and MCP servers
To put the pattern into practice, start with the getting‑started guide. It walks you through deploying the hoop.dev gateway, registering an MCP server as a connection, and configuring Okta as the OIDC provider. The documentation explains how to map Okta groups to hoop.dev policies, how to enable just‑in‑time approvals, and how to turn on inline masking for the fields you care about.
Additional guidance on policy configuration is available in the Learn documentation.
Because hoop.dev is open source, you can inspect the source code, contribute improvements, or host the gateway in your own environment. The repository is available on GitHub.
FAQ
Can I reuse existing Okta groups for policy decisions?
Yes. hoop.dev reads the group claims from the OIDC token and lets you create policies that reference those groups directly. This lets you keep a single source of truth for identity and access.
What happens if a request fails the just‑in‑time approval step?
The request is terminated at the gateway and a clear audit record is created. No command reaches the MCP server, and the operator receives a notification that the request was denied.
Does hoop.dev store the service account credentials used by the MCP server?
No. The gateway holds the credential only in memory for the duration of the proxied session. The client never sees the secret, and the credential is never written to disk.
Ready to explore the implementation? View the source code on GitHub and start building a secure, auditable pipeline for your MCP servers.
