MCP security

Secure the MCP servers your agents can reach.

An MCP server hands an agent real power — it can spend money, delete records, message people. Meandr is the security layer that sits in front of those servers: it decides what a call is allowed to do, pauses the risky ones for a human, and records every one. No change to your agent's code.

Get started How Meandr secures it

The risk

An MCP server is a lot of power on a short leash.

The moment an agent can call a tool server, it can act on the world behind it. Without a control plane in the middle, nothing sits between the model's decision and the real effect.

The tool is the blast radius

A single MCP tool can refund a charge, drop a table, or open a pull request. The server exposes the action; whatever calls it inherits that reach the moment it connects.

The arguments are where it goes wrong

A tool being allowed isn't the whole question — which repo, whose account, how large a refund is. The model chooses those arguments at run time, and a raw allowlist never sees them.

And no one has the receipts

When an agent calls a server directly, there's no single place that saw the request. If something goes wrong, you're reconstructing what happened from scattered logs, if they exist at all.

How Meandr secures it

A control plane between the agent and the server.

Every call routes through Meandr on its way to the real server. That one chokepoint is where policy, approval, audit, and encryption all apply — the same for every agent and every server you connect.

Policy on the arguments, not just the tool

Rules read the actual arguments of a call and allow, deny, or require approval. They run in priority order, first match wins, and a default policy is always in force — so a tool you never wrote a rule for is governed, not open.

A human confirms the risky ones

A require-approval rule pauses the call and waits for a person. On supported clients the prompt appears in-chat and is confirmed with a one-time code. Deny or timeout means it never runs — and every decision is logged.

Every call leaves a record

Each call writes a small, immutable row — which tool, which agent, the policy decision, status and timing. Keeping the request or response body is opt-in per rule, and when you keep it, it's stored encrypted.

Encrypted in, out, and to the server

Agents reach Meandr over TLS with SNI required. Meandr re-encrypts every call to the real server and verifies its certificate, and for servers that need it, mTLS is a first-class upstream auth type.

Upstream credentials held, not handed out

The keys and tokens Meandr uses to reach your servers are sealed with AES-256-GCM under a KMS-wrapped data key — one dedicated key per environment — and decrypted in memory only when a call needs them. Your agents never see them. AWS SigV4 signing is built in, with no proxy to run.

Blind to your payloads by default

By default Meandr logs metadata about a call, not its contents. Even when a rule keeps the bodies, capture is storage, not inspection — there's no DLP, no regex, no PII scanning reading what you store.

Stdio MCP servers open no port

A stdio MCP server dials out through the Meandr CLI on the machine that runs it, so nothing on your side listens. Meandr holds no upstream credential for it either.

What a call goes through

Decide, confirm, record — then forward.

The security work happens before the tool ever runs. Nothing reaches the server until the call has cleared policy.

01

Match a policy

On the real arguments.

Meandr reads the tool and its arguments and finds the first matching rule — allow, deny, or require-approval. If nothing matches, the default policy decides.

You set up: the rules, in priority order.

02

Pause if it needs a human

Confirmed by one-time code.

A require-approval call stops and waits. A person approves it with a one-time code; a denial or a timeout means the tool never runs.

You set up: who approves, on which rules.

03

Record, then forward

Signed, encrypted, logged.

An allowed call is signed with the server's own credentials, sent over a verified connection, and written to the audit trail — bodies kept only if a rule asked for them.

You set up: the server's auth and what to capture.

Questions you'd ask anyway.

How is this different from an MCP server's own permissions?
A server decides whether a tool exists and what it can do; it doesn't know which agent is calling or whether this particular call should be allowed. Meandr sits in front of every server and decides that per call, on the actual arguments — one policy layer across all of them, not one per server.
Do I have to change my agent or the server to add this?
No. Meandr speaks standard MCP over HTTP, so you point the agent at Meandr instead of the server and connect the server behind it. No SDK, no code change on either side.
Can it block a specific call, not just a whole tool?
Yes — that's the point of argument-level policy. A rule can allow reads of any repo but require approval to write to production, or deny refunds over a threshold, because it reads the arguments of the call rather than only the tool name.
Does Meandr store the contents of my tool calls?
Not by default — it keeps metadata about each call, never the bodies. Storing the request or response payload is opt-in per rule, and even then it's encrypted at rest and stored, not inspected: no DLP, no regex, no PII scanning.
How are my upstream credentials protected?
Each server's keys and tokens are sealed with AES-256-GCM under a KMS-wrapped data key, with one dedicated key per environment, and decrypted in memory only when a call to that server needs them. Your agents never receive them — Meandr signs the request on their behalf.

Put a security layer in front of your MCP servers.

Point your agent at one endpoint and you're governed in minutes — no code changes, no proxy to run.

Get started

Questions? Email us