Security and trust posture
Running agents against MCP servers in production raises three questions Catalyst is built to answer:
- Who is this caller? Can the platform prove a tool call came from a specific agent, and not from impersonated or hijacked credentials?
- What may this caller do? Are there enforceable limits on which tools an agent can use — limits the LLM cannot reason its way around?
- What has this caller done? When something goes wrong, is there a record of what happened, by which identity, in what order?
Catalyst answers each of these at its MCP proxy endpoint, so the answers stay consistent regardless of which agent framework, language, or LLM you use, and without any change to MCP client or server code.
How Catalyst answers the three questions
| Question | Catalyst control |
|---|---|
| Who is this caller? | Every agent reaches an MCP server through Catalyst's MCP proxy endpoint, authenticating with its App ID API token. Catalyst validates that token before any policy runs. Internally the call is carried over mTLS using SPIFFE-issued workload identities that Catalyst attests and rotates automatically. |
| What may this caller do? | A deny-by-default MCPServerAccessPolicy allow-lists which caller App IDs may use which tools. Tool discovery is filtered to authorized tools and unauthorized calls are rejected with 403 — the LLM cannot reason its way around either, because enforcement happens after its decision. |
| What has this caller done? | Every MCP call flows through Catalyst's data plane and is captured in logs, metrics, and distributed traces. The observability console shows which App ID called which server and tool, when, and whether the policy allowed or denied it. |
Default postures
Catalyst's defaults favor refusal over permissiveness. None of these require you to "turn on a security mode" — they are how the platform behaves out of the box.
- Deny by default. A newly created MCP server denies every caller and every tool until you explicitly grant access.
- No upstream credentials in agent code. The upstream server's credential is stored in your project's secret store and injected by Catalyst at request time. The agent holds only its own Catalyst token and receives tool results, never the credential.
- The upstream URL is hidden. Callers address servers by connection name through Catalyst; they never see or connect to the upstream URL directly.
- mTLS is on everywhere. Internal traffic between Catalyst workloads is mutually authenticated using SPIFFE identities. You don't configure it; it isn't a per-resource flag.
Threat model
The failure modes below account for most of the security risk when agents use MCP tools in production. Catalyst's controls map directly to each.
| Failure mode | What it looks like | Catalyst control |
|---|---|---|
| Unauthorized tool use | An agent tries to use a tool it isn't entitled to. | The MCP access policy filters discovery and rejects the call with 403 at Catalyst's data plane, before it reaches the upstream server. |
| Over-broad access | An agent is granted a whole server when it needs only one tool. | Policy grants are per-tool, so you allow exactly the tools an agent needs and nothing more. |
| Jailbreaking | A prompt persuades the LLM to attempt an unauthorized action. | The LLM's decision happens before the platform; authorization runs after. A jailbroken LLM that tries a forbidden tool still hits a deny before any code on the upstream server runs. |
| Credential leakage | Upstream API keys appear in logs, prompts, or agent code. | Upstream credentials are resolved from the secret store at request time and never sent to or visible to the agent. The caller's own token is stripped before the call is forwarded upstream. |
| Caller spoofing | A request claims to be from an agent that didn't send it. | The caller is identified by its App ID token at the endpoint and by its SPIFFE identity on the internal hop; both are verified before the policy is evaluated. |
| No provenance | No verifiable record of who did what. | Every MCP call is recorded by Catalyst's observability pipeline — logs, metrics, traces — alongside the policy decision. |
What stays your responsibility
Catalyst draws the trust boundary at the platform's surface. Some risks live outside it.
- Prompt injection and LLM-layer attacks. Catalyst enforces authorization regardless of what the LLM does, but it does not inspect prompt content. Defense against prompt injection — content filters, output validation — belongs in your agent's pre-LLM and post-LLM layers.
- The security of the upstream server itself. When you connect to a third-party MCP server (GitHub, Stripe, Linear), Catalyst secures the connection, not the server. Vet third-party MCP servers as you would any other dependency.
- Audit sink durability and integrity. Catalyst emits observability data to your sinks; their long-term durability and tamper resistance are governed by the sink you write to. Choose one whose retention and integrity guarantees match your compliance obligations.
Next steps
- Control tool access — deny-by-default, per-tool authorization.
- Authentication — caller-to-Catalyst and Catalyst-to-upstream credentials.
- Model Context Protocol — where these controls fit in the protocol story.