Segregation of Duties in MCP Gateways, Explained

A recently offboarded contractor still holds a token that can invoke the internal AI model, while a newly created CI job is granted a blanket permission to the same MCP gateway. The contractor’s token can issue prompts, and the CI job can retrieve responses, but no one has checked whether the same identity should be allowed to both generate and consume the model’s output. The result is a classic segregation of duties violation that can hide malicious activity, inflate blast radius, and make audit trails meaningless.

In many organizations the MCP gateway is treated as a simple proxy: a network address that forwards traffic to a language model or code‑completion service. Engineers configure a service account, hand out its credentials, and assume that the surrounding IAM policies are enough. What actually slips through is the lack of a clear boundary between the actors who are allowed to initiate a request, the actors who can approve a high‑risk request, and the actors who can view the resulting data. When those responsibilities overlap, a single compromised credential can both trigger and conceal abuse.

Why segregation of duties matters for MCP gateways

Segregation of duties is a control principle that requires critical functions to be divided among separate people or systems. For an MCP gateway the critical functions are:

• Request initiation – the identity that sends a prompt to the model.
• Risk approval – the identity that reviews and authorizes a request that matches a high‑risk policy (for example, prompts that contain production secrets).
• Result consumption – the identity that reads the model’s response.
• Audit and replay – the identity that can inspect a session for compliance or forensic purposes.

If a single token can perform all four steps, an attacker who steals that token can issue malicious prompts, bypass any human review, read the output, and erase evidence of the activity. The separation of duties reduces the attack surface by ensuring that no single credential can complete the entire workflow.

Required controls before you can claim a safe MCP deployment

To achieve proper segregation you need three layers of protection:

1. Identity‑driven role mapping – define distinct roles such as "prompt‑sender", "approver", and "viewer" in your identity provider. Each role receives a token that conveys only the permissions required for its function.
2. Policy enforcement at the gateway – the gateway must examine each request, match it against risk policies, and enforce approval workflows before forwarding it to the model.
3. Comprehensive audit – hoop.dev records every session, including the request, the approval decision, and the response, in an immutable store that only privileged auditors can query.

These controls cannot be satisfied by IAM alone because the IAM system never sees the actual prompt payload, never knows whether a request matches a high‑risk pattern, and never records the model’s answer. The enforcement point must sit where the traffic flows.

How hoop.dev provides the data‑path enforcement needed for segregation of duties

hoop.dev is a Layer 7 gateway that sits between identities and the MCP target. It authenticates users via OIDC or SAML, reads group membership, and maps each identity to a role. Because the gateway resides on the data path, it can inspect the request payload in real time. It then applies the following enforcement outcomes:

• hoop.dev blocks a request that originates from a "prompt‑sender" role when the request matches a high‑risk pattern.
• hoop.dev routes the request to an approval workflow and only forwards it after a designated "approver" grants consent.
• hoop.dev masks sensitive fields in the model’s response before delivering it to a "viewer" role that does not need to see raw secrets.
• hoop.dev records each session, including the original token, the approval decision, and the masked response, in an immutable store that only privileged auditors can query.

Because hoop.dev is the only component that can see both the request and the response, the segregation of duties guarantees cannot be bypassed by a compromised service account. The gateway’s policy engine is the single point where the four critical functions are separated and enforced.

The getting‑started guide walks you through deploying the gateway, configuring OIDC authentication, and defining role‑based policies. Detailed feature documentation is available in the learning portal, which explains how to write risk policies, set up approval workflows, and configure masking rules.

What to watch for when implementing segregation of duties

Even with a capable gateway, certain pitfalls can erode the segregation guarantees:

• Over‑broad role assignments – granting the "prompt‑sender" role also the "approver" role defeats the purpose. Keep role definitions narrow and review group membership regularly.
• Missing approval steps for high‑risk patterns – if the policy engine does not include the relevant regexes or keyword lists, risky requests will flow unchecked.
• Improper audit storage – storing session logs in a location that the same service account can delete removes the forensic value. Use a separate, write‑once storage backend for audit records.
• Bypassing the gateway – ensure that all client traffic is forced through the gateway, e.g., by network ACLs or DNS entries that resolve only to the gateway address.

Addressing these concerns starts with a clear mapping of duties to identities, followed by strict network enforcement that guarantees every request passes through hoop.dev.

FAQ

How does segregation of duties differ from simple RBAC?

RBAC assigns permissions to roles, but it does not enforce the sequence of actions. Segregation of duties adds the requirement that certain actions (like approval) must be performed by a different role than the one that initiates the request, and that the system records the hand‑off.

Can I use hoop.dev with existing CI pipelines?

Yes. CI jobs can be given a "prompt‑sender" token that allows them to submit low‑risk prompts. When a job needs to run a high‑risk prompt, hoop.dev will automatically pause execution and wait for an approver, preserving the segregation guarantee.

Do I need to modify my application code to use hoop.dev?

No. The gateway works at the protocol level, so standard client tools (curl, grpcurl, or the model’s SDK) can point at the gateway endpoint without code changes. The enforcement happens transparently in the data path.

By placing identity verification, policy enforcement, and audit collection in a single, immutable gateway, you achieve true segregation of duties for MCP gateways.

Explore the source code on GitHub