Many assume that only human users can be granted access to an MCP gateway, and that service accounts are simply shared secrets. In reality, a non-human identity can be provisioned, scoped, and audited just like a person.
A non-human identity is any credential that represents a process, CI/CD pipeline, AI agent, or other automation rather than a human. Treating these actors as first‑class identities lets you apply least‑privilege policies, rotate secrets automatically, and trace every request back to the originating system. Without that discipline, a single leaked token can give unrestricted access to critical services for weeks.
An MCP gateway sits at layer 7 between callers and internal services, intercepting protocol traffic so it can enforce masking, require approvals, and record sessions. Because the gateway mediates every request, it is the natural place to enforce identity‑based controls for both people and machines.
Identity verification at the gateway relies on OIDC or SAML tokens issued by an external IdP. The gateway validates the token, extracts group or role claims, and maps those claims to the permissions required for the requested operation. This setup determines *who* is making the request, but it does not by itself enforce what the request may do.
hoop.dev implements the data‑path enforcement that turns a verified non-human identity into a controlled, auditable session. The gateway holds the service credentials, so the automation never sees raw passwords or keys. When a request arrives, hoop.dev checks the token’s claims against policy, optionally routes the operation to a human approver, masks sensitive fields in responses, and records the entire interaction for later replay.
Why non-human identity matters for MCP gateways
Automation is the backbone of modern development pipelines, but unchecked automation can become a blast radius multiplier. By assigning a distinct non-human identity to each pipeline, you can:
- Scope access to exactly the resources needed for that job.
- Rotate credentials on a schedule that matches the pipeline’s cadence.
- Generate reliable audit trails that tie each command to the automation that issued it.
- Apply inline data masking so that downstream services never expose raw secrets to downstream logs.
These capabilities are only effective when the enforcement point sits where the traffic actually flows – the gateway itself.
How hoop.dev enforces policies for non-human identities
Once the setup layer has authenticated the token, hoop.dev becomes the sole authority that decides whether the request proceeds. It performs three core actions:
- Policy evaluation. The gateway reads the identity’s claims and matches them against a policy that defines allowed commands, target hosts, and required approvals.
- Just‑in‑time gating. If a request exceeds its baseline permissions, hoop.dev can pause the flow and present an approval request to a designated human reviewer, ensuring that elevated actions are intentional.
- Enforcement outcomes. Successful requests are recorded, responses are masked according to policy, and the entire session is stored for replay. Because hoop.dev sits in the data path, the agent never sees the underlying credential, and every action is captured.
Without hoop.dev in the data path, the token verification step would be the only control, and the automation could still execute any command it knows how to speak. The enforcement outcomes – approval workflow, masking, session recording – would disappear.
Implementing non‑human identity with an MCP gateway
Begin by defining a service account in your identity provider that represents the automation you want to protect. Assign it a minimal set of groups or roles that reflect the exact resources it needs. Next, register the MCP gateway as a connection in hoop.dev, supplying the credential that the gateway will use to reach the target service. The gateway will store this credential securely, keeping it out of the automation’s runtime environment.
When the automation initiates a request, it presents its OIDC token to the gateway. hoop.dev validates the token, extracts the non-human identity’s claims, and runs the request through the policy engine described above. If the request is within the allowed envelope, it proceeds; otherwise it is blocked or escalated for approval. All interactions are logged and can be replayed for forensic analysis.
Because the enforcement happens at the gateway, you gain a single, consistent control surface for every MCP‑based integration, whether the caller is a CI job, a scheduled data‑pipeline, or an LLM‑driven code assistant.
Next steps
Review the getting‑started guide to spin up a gateway and register a non‑human identity. The learn section contains deeper explanations of policy syntax, approval workflows, and masking rules. When you are ready to explore the source code or contribute, visit the project on GitHub.
FAQ
Do I need to change my existing CI pipelines? No. The pipelines keep using their standard client tools; they only need to acquire an OIDC token for the service account and point the client at the gateway endpoint.
Can I use multiple non‑human identities for the same pipeline? Yes. Each identity can be associated with a distinct set of policies, allowing you to separate read‑only and write‑enabled stages of a build.
What happens to logs that contain secrets? hoop.dev masks configured fields before they are written to the audit store, ensuring that secret values never appear in plain text in logs or replay sessions.
