Creating a complete, tamper‑evident audit trail for every CI/CD run that touches an MCP gateway gives teams confidence that no hidden command ever slipped through.
In many organizations, the CI/CD system invokes an MCP gateway to run code, fetch data, or trigger downstream services. The pipeline typically authenticates with a static service account, calls the gateway directly, and proceeds without any record of what was sent or received. If a malicious commit injects a dangerous query, the only evidence may be a vague log entry on the build server, and that log often lacks the request payload, the exact response, or the identity of the actor who triggered the job. Because the gateway sits behind the pipeline, the pipeline’s own logs become the sole source of truth, and they are easily overwritten or omitted.
This state leaves three gaps. First, there is no reliable proof that a particular command reached the MCP gateway. Second, the response data, often containing sensitive identifiers, passes back to the pipeline unfiltered, making it hard to prove that no confidential information was exposed. Third, any approval or manual review step happens outside the request flow, so a rogue change can bypass human oversight entirely.
Why an audit trail matters for MCP gateways
The security requirement is simple: every request that traverses an MCP gateway must be recorded, and the record must be tied to the identity that initiated it. An audit trail should capture the full request, the response (with optional masking of sensitive fields), and the exact time of execution. With that evidence, incident responders can reconstruct the chain of events, compliance auditors can verify that only authorized actions occurred, and developers can debug failures without guessing what the gateway saw.
However, achieving this without a dedicated data‑path component is impossible. The pipeline’s own logs cannot guarantee completeness, and the gateway itself cannot be trusted to emit reliable logs when it runs inside the same trust boundary as the pipeline.
Introducing a data‑path gateway
hoop.dev places a transparent gateway in the data path of every MCP request. By sitting between the CI/CD runner and the MCP service, hoop.dev can inspect each wire‑level transaction, apply inline masking, enforce just‑in‑time approvals, and record the entire session. Because the gateway is a separate process that the pipeline cannot reconfigure, the audit trail it produces remains trustworthy even if the pipeline is compromised.
When a CI/CD job starts, the runner presents an OIDC token. hoop.dev validates the token, extracts the user or service‑account identity, and checks whether that identity is allowed to invoke the specific MCP endpoint. If the request passes, hoop.dev forwards it to the MCP gateway, captures the request payload, and streams the response back through the same path. During this exchange, hoop.dev can mask fields such as passwords or API keys, and it can pause execution for a human approval if the operation is deemed high‑risk.
Every interaction is recorded as an audit entry that captures the initiator’s identity, the full request, the masked response, and timestamps. Because hoop.dev controls the connection end‑to‑end, no other component can alter or delete those records without detection.
How to get started
Deploy the gateway alongside your CI/CD infrastructure using the standard Docker Compose quick‑start. The deployment guide walks you through configuring OIDC authentication, registering your MCP endpoints, and enabling session recording. Once the gateway is running, point your pipeline’s MCP client at the hoop.dev address instead of the raw service endpoint.
For detailed steps, see the getting‑started guide and the learn section for deeper coverage of masking policies and approval workflows.
FAQ
- Does hoop.dev store raw credentials? No. The gateway holds the service credentials internally; the CI/CD runner never sees them.
- Can I mask only specific fields in the response? Yes. Masking policies are defined per‑endpoint and can target any JSON field or header.
- What happens if a pipeline tries to bypass the gateway? Because hoop.dev is the only network‑reachable address for the MCP service, any direct connection is blocked by network policy.
Ready to add a reliable audit trail to your CI/CD pipelines? Explore the source code, contribute improvements, and see the full feature set on GitHub: hoop.dev repository.
