How can you let an AI agent or automation script talk to your internal services without exposing long-lived secrets? The answer hinges on using a non-human identity that is verified at the gateway but never leaks credentials.
Today many teams embed static API keys, service-account passwords, or hard-coded tokens directly in code that drives the MCP (Machine Control Plane) runtime. The credential lives in the repository, in container images, or in CI pipelines, and every request the automation makes reaches the target database or service with no visibility. If a token is compromised, every downstream system is instantly exposed, and there is no reliable way to prove which command caused a problem.
This approach creates three concrete risks. First, credential sprawl makes revocation a nightmare because the secret is duplicated across dozens of jobs. Second, there is no per-request audit; you cannot answer who asked a particular LLM to read a row from a database. Third, the automation can issue destructive commands without any human checkpoint, increasing the blast radius of a mistake.
The missing piece is a non-human identity that can be granted just-in-time, yet the request still travels straight to the target. In that state the identity is verified, but the gateway that could enforce masking, command-level approval, or session recording is absent. The result is a valid authentication token with no guardrails, no audit trail, and no way to block risky operations.
Why non-human identity matters for MCP
When MCP acts on behalf of a service, a bot, or an LLM, the principal is not a human user. The principal must be represented by an OIDC or SAML token that conveys group membership and attributes. Those attributes drive policy decisions such as which databases the bot may query or which Kubernetes namespaces it may exec into. Without a dedicated data-path enforcement point, the token alone cannot enforce fine-grained rules. The request reaches the backend directly, and any sensitive fields returned by the service are exposed in clear text.
Non-human identity also enables just-in-time (JIT) provisioning. An automation workflow can request a short-lived token, perform its work, and have the token automatically expire. The token’s lifetime is enforced by the gateway, not by the downstream service, which typically does not understand short-lived credentials.
hoop.dev as the enforcement layer
hoop.dev provides the data-path that every MCP request must cross. It verifies the OIDC/SAML token, maps the identity to a policy, and then proxies the connection to the target infrastructure. Because the gateway sits in the protocol layer, it can:
- Record each session for replay and audit, ensuring that every query issued by a non-human principal is traceable.
- Mask sensitive response fields in real time, preventing secrets from leaking back to the automation.
- Require human approval for high-risk commands before they are sent to the backend.
- Enforce JIT access by granting credentials only for the duration of an approved session.
All of these enforcement outcomes exist only because hoop.dev occupies the data path. The setup, OIDC provider, service accounts, and IAM roles, decides who may start a request, but without hoop.dev there is no place to apply the guardrails.