+How it works
Six checks between your agent and someone else's code.
- 01Package
Known-bad packages
The packages a server launches are checked against public malicious-package and advisory feeds, every day.
- 02Description
Hidden instructions
Tool descriptions and schemas are scanned for embedded instructions and hidden characters before an agent relies on them.
- 03Connection
Asked once
The first time an agent calls a server it isn't connected to, a person decides once. That answer becomes the connection.
- 04Call
Decided before it runs
Every tools/call is authorized with the agent's role, the tool's impact and the actual arguments. A denied call never reaches the server.
- 05Approval
Bound to the call
When a person approves, the approval covers that server, that tool and those exact arguments, and nothing else.
- 06Evidence
On the record
Allowed, asked and denied calls land in the MCP hub, the activity ledger and the conversation's trace.
+Why it matters
An MCP server runs with your agent's authority.
It's code you didn't write. It describes its own tools in text your agent reads as instructions. It can change after you approved it. Each of those is a way in, and each needs a check that doesn't depend on a developer reading every server's source.
Poisoned descriptions
Compromised packages
Silent changes
+Decided once
One decision per call. No double approvals.
- Each tools/call is decided once, at the edge, and carries a permit for exactly that call to the server. A person who approves a call is never asked about it twice.
- A call that needs approval returns a clear answer with a link: approve it, and the agent calls again with the same arguments.
- Calls through a combined (virtual) MCP server are governed as the real server and tool they reach.
- Tool impact comes from the tool and its arguments. A server's own annotations can only make a tool riskier, never safer.
stripe.refund needs approval from a person under the
rule "Refunds over $500" and has not been decided yet
(approval apr_7Kd2). The request expires at 10:56 UTC.
Tell the user it is waiting for approval in Intertrace
at https://platform.intertrace.ai/…. Once approved, call
stripe.refund again with exactly the same arguments; it
will run without a new request.Example message. The tool, rule, approval id and expiry come from the real call.
+Getting started
Two ways to connect.
+Through the Intertrace edge
Point your MCP client at Intertrace with a runtime key. Intertrace authorizes every call and forwards only what passes. For coding agents, itr connect registers remote servers and rewires them for you.
+In your own process
Wrap tool calls with the runtime SDK. Each call waits in your process until Intertrace allows it, so local servers that can't be proxied are governed too.
+Start safely
Begin in monitor mode: calls go through, and the ones Intertrace would stop are flagged for review. Switch to enforce when you're ready. In enforce mode a denied call fails closed, and if Intertrace can't decide, it denies.
+What we claim
Inspected, pinned and fail-closed. Not magic.
MCP Guard doesn't make MCP safe in the absolute. It makes every server you use checked before you trust it, every change visible, and every call decided before it runs, with a record of each refusal. A compromised server becomes a logged, denied event instead of a silent breach.
+ MCP Guard
Know every MCP server your agents touch.
Run the free risk check on a server you use today, or book a walkthrough on your own agents.