Securing MCP servers and AI agents

AI agents are non-human principals that run unattended, at machine rate, and can be prompt-injected into asking for the wrong thing while remaining correctly authenticated. This guide covers how Tunnex governs what agents can reach on your network — and, just as importantly, what it cannot do.

The problem with MCP deployments today

MCP (Model Context Protocol) servers are typically deployed in one of two positions:

1. Localhost — safe because unreachable. The moment your team is remote or the agent runs in a container, localhost stops working.
2. Public internet behind a bearer token — reachable, but any holder of that token gets in. No device identity, no network boundary, no expiry, no attribution.

There is no network boundary and no device identity between those two positions. Tunnex provides exactly that missing layer: the MCP server stays inside your network, and agents connect over WireGuard as named principals.

The boundary, first

Under prompt injection, authentication is intact and authorization is intact. Only intent is corrupted. Zero Trust bounds the blast radius of a correctly-authenticated principal. It does not detect injection.

Tunnex cannot detect a manipulated request. What it does is ensure that when an agent’s intent is corrupted, the damage is capped at what policy already allowed — nothing more is reachable, and everything it did reach is attributed in the log.

How agent governance works

1. Agents are a managed device kind with a required owner

An AI agent enrolls as its own device kind — not as a reused user account or an ownerless service credential. Every agent principal belongs to a human account, which means:

• It counts against the per-user device cap like any other device.
• Posture and lifecycle tooling treat it as a device: enrollment, credential rotation, and full-sweep revocation all apply.
• An optional organization group can be delegated to manage the agent without transferring ownership.

2. MCP servers are port-scoped destinations

An MCP server is expressed as an ordinary Zero Trust resource — a CIDR plus specific ports and protocols. Policy rules name the agent as the subject (src_kind: agent) and the MCP server as the destination. Everything else is denied by default at the gateway kernel; there is no rule to write that grants “the subnet around” the server.

Because agents are subjects in the same compiled artifact as human devices, there is no parallel rule stack and no second door.

3. Access is approval-gated and expires on its own

Agents can request just-in-time access instead of holding standing rules:

• A request names the destination, a reason, and a duration between 5 minutes and 24 hours.
• An administrator approves or denies it in the console.
• Approved requests materialize ordinary expiring policy rules — the same mechanism, sweep, and audit trail as any other rule. When the expiry passes, access is gone.

Standing access should be the exception. Extend a grant by approving a new window rather than widening a permanent rule.

4. Credentials rotate; inventory is observed without secrets

Agent credentials support rotation without re-enrollment. Separately, a managed agent runtime can report an MCP inventory — a shadow-mode snapshot of which servers it observes, carrying no credentials, session identifiers, prompt content, or tool results. It answers “what MCP servers exist in this environment” without becoming a sensitive store itself.

5. Attribution is per-agent

Flow logs stamp the source device from the compiled artifact’s address map, so a connection is attributed to the specific agent — and through ownership, to the account that launched it. The audit log records policy changes with a stated cause, including system actors.

Hardening checklist

• Enroll agents as the agent device kind; never share human credentials with an agent.
• Express each MCP server as a resource scoped to its exact ports — never a whole subnet.
• Prefer just-in-time grants over standing rules; keep durations at the low end.
• Delegate management to a group only where a team genuinely shares responsibility.
• Review flow logs filtered to agent subjects; unexplained allow traffic is an incident.
• Treat the MCP inventory snapshot as discovery input for policy, not as compliance art.

What this does not do

• It does not detect prompt injection, malicious tools, or data exfiltration inside allowed flows. Pair it with content-layer controls where that risk matters.
• It does not make an agent trustworthy. It makes an agent bounded: correctly authenticated, narrowly authorized, temporarily granted, and fully attributed.