A common misconception is that simply assigning an AI model a single service account guarantees proper segregation of duties; in reality, that approach leaves the model free to read and write any data it encounters.
When an organization deploys an MCP (Model‑Controlled Process) server, the model often acts on behalf of users, scripts, or other services. If the model’s credentials sit in a static secret and the MCP process receives them directly, every downstream request bypasses any oversight. Auditors will see a single credential used for many unrelated actions, and a compromised model can cause a cascade of damage.
Understanding segregation of duties for MCP
Segregation of duties (SoD) separates critical functions among distinct actors. For MCP, the principle translates into three practical goals:
- Separate intent and execution. One identity proposes an operation, another approves it.
- Make every action visible. Each request and response records for later review.
- Protect sensitive data. Responses that contain personal or financial fields mask before they reach the model.
Achieving these goals starts with a strong identity foundation. Organizations typically configure OIDC or SAML providers (Okta, Azure AD, Google Workspace) so that each user or service account receives a short‑lived token. The token conveys who is calling, what groups they belong to, and any contextual attributes such as time of day or IP range.
Why identity alone isn’t enough
Identity verification answers the question “who am I?” but it does not answer “what am I allowed to do right now?” In many deployments the MCP server receives a validated token and then opens a direct TCP connection to the target database, Kubernetes API, or internal HTTP service. The connection travels straight from the MCP process to the resource, meaning:
- The gateway cannot intervene with real‑time policy evaluation.
- The resource logs only see the MCP’s service account, so command‑level audit disappears.
- No inline masking occurs, so any sensitive fields flow back to the model unfiltered.
- No human approval step can be inserted for high‑risk commands.
In short, the request still reaches the target directly, with no audit, no masking, no approval, and no way to block a dangerous operation. The setup provides authentication, but it stops short of enforcement.
Enforcing duties with hoop.dev
hoop.dev acts as a Layer 7 gateway that sits between the MCP server and every downstream target. By placing the gateway in the data path, hoop.dev becomes the sole component that evaluates policy and produces enforcement outcomes.
- Just‑in‑time approvals. When the model issues a command that matches a high‑risk pattern (for example, a DROP DATABASE or a kubectl delete on a production namespace), hoop.dev pauses the request and routes it to an approver defined in the organization’s workflow. The approver’s decision records, and the request either proceeds or is rejected.
- Inline data masking. hoop.dev strips or tokenises fields marked as sensitive (PII, credit‑card numbers, internal identifiers) before handing the response back to the MCP process. The model never sees raw confidential data, satisfying SoD requirements for data protection.
- Command‑level audit and replay. hoop.dev logs every request, approval decision, and masked response. It stores the logs outside the MCP runtime, enabling auditors to reconstruct exactly what the model did, who approved it, and what data was exposed.
- Session recording. For interactive protocols such as SSH or database consoles, hoop.dev records the full session stream. This provides forensic evidence if a breach later emerges.
Because hoop.dev consumes the OIDC token, it maps the token’s groups to fine‑grained policies. The MCP server never embeds policy logic; it simply talks to the gateway using its native client (psql, kubectl, curl, etc.). The gateway enforces segregation of duties without requiring code changes in the model or the downstream services.
Getting started
Deploy the gateway using the official getting‑started guide. Register your MCP target as a connection, configure the masking rules for the fields you consider sensitive, and define approval workflows for the critical commands you want to guard. The documentation in the learn section walks through each step in detail.
FAQ
Q: Does hoop.dev replace the need for service‑account rotation?
A: No. Rotating credentials remains a best practice. hoop.dev adds a control layer that evaluates each request, regardless of how fresh the credential is.
Q: Can I use hoop.dev with multiple OIDC providers?
A: Yes. The gateway can trust any OIDC or SAML identity source that your organization uses.
Q: How does masking affect model performance?
A: Masking occurs at the protocol layer and adds only minimal latency. The model receives the same response shape, with sensitive values replaced, preserving downstream logic.
By inserting hoop.dev into the MCP data path, organizations gain the three core pillars of segregation of duties: enforced approval, protected data, and complete auditability. The result is a practical, auditable workflow that lets AI‑driven processes operate safely in production environments.
Explore the open‑source repository on GitHub to dive deeper into configuration options and contribute improvements.
