Britive MCP Gateway

The Britive MCP Gateway sits between the AI that calls your tools and the MCP servers that run them. Every tool call flows through the Gateway, which decides whether that identity may make it, gives the backend a credential that expires, and records what happened.

It serves both kinds of caller:

• People working through an assistant - Claude Desktop, Claude Code, Codex - who sign in with Britive through their browser.
• Autonomous agents and workloads - scheduled jobs, CI pipelines, AI identities - which present a Britive token directly, with no browser and nobody watching.

The Problem It Solves

An MCP server needs credentials to be useful. Left to itself, that means a long-lived API key sitting in a config file, shared by whoever is using the agent, with no record of which identity’s request triggered which call.

The Gateway removes the standing credential from that picture:

• The caller never holds a credential. The Gateway obtains one per call - a Britive checkout for backends you run, or the caller’s own authorized OAuth token for SaaS MCP servers - and injects it into the backend request. Neither is ever handed to the model.
• Each identity sees only its own tools. The tool list a client receives is built from that caller’s Britive policy - two identities connected to the same Gateway see different catalogues.
• Permission is checked twice. Once when the catalogue is built, and again when a tool is actually invoked, so a client holding a stale list cannot reach past its policy.
• Every call is audited. Which identity called what, with which arguments, why the model chose it, and whether it was permitted - in the Gateway’s own database, in your SIEM, and in your Britive tenant’s audit history.
• Payloads are inspected. Tool arguments on the way out and tool responses on the way back are scanned for prompt injection, leaked secrets, and obfuscation attempts - recorded first, blocked once you’re ready.

Where to Start