How Ultra secures MCP traffic

Ultra is a security proxy for the Model Context Protocol. It sits transparently between your agents and the upstream connectors they call, giving you full visibility into every tool call, resource read, and prompt request, and a place to enforce policy on them. This post walks through how it is built and the design decisions behind each layer.

Design principles

• Local-first. Ultra runs as a single binary on your own machine. Agents launch it as a subprocess and processing happens on-device. There are no cloud components in the data path, so there is no added network hop and no third party routing your traffic.
• Transparent. Ultra looks like an ordinary MCP endpoint to the agent and an ordinary client to upstream connectors. Neither side has to change. It speaks the full protocol across stdio, HTTP/SSE, and Streamable HTTP.
• Visibility before enforcement. Observability is the foundation and policy sits on top of it. You cannot write good rules for traffic you cannot see, so Ultra records first and enforces second.

System architecture

Ultra is a layered proxy with clear separation between transport, processing, routing, and storage. A request enters through the transport layer, passes through the observability pipeline, and is dispatched by the aggregator to the correct upstream connector. Responses travel the same path in reverse.

Transport layer

The transport layer handles MCP protocol communication and supports every transport type. The client-facing side is typically stdio, since agents launch Ultra as a subprocess, while upstream connections use whatever transport each connector requires. This is what lets one device bridge a stdio desktop agent to a mix of local and remote HTTP connectors without either side knowing the difference.

The pipeline

Every request and response passes through the same interceptor chain, in order:

• Trace captures distributed traces for each request and response, with full payloads, timing, status, and OpenTelemetry span IDs using W3C Trace Context, so MCP activity correlates with your existing observability stack.
• Logging records structured request and response logs.
• Audit emits security-relevant events with severity, outcome, and principal identity.
• Metrics tracks request counts, latency histograms, and error rates, broken down per connector.

The pipeline makes one deliberate asymmetry. Trace, Logging, and Metrics absorb errors silently, because observability should never break a workflow. Audit does the opposite and fails closed: if an operation cannot be recorded, it is not allowed to succeed. That guarantee means every completed MCP call has a matching audit record, which is what security teams need to rely on.

The aggregator

The aggregator manages connections to all upstream connectors and presents them to the agent as one unified interface. This is what collapses the N×M connection problem: an agent connects to Ultra once and the aggregator fans out to every connector behind it. It probes and normalizes connectors automatically, handling quirky startup flags and protocol differences, and hot-loads new connectors without a restart.

Storage

Observability data is stored locally on the device by default, with optional export to any OpenTelemetry-compatible backend such as Datadog or Grafana, and optional sync to Ultra Hub for team deployments. Nothing leaves the machine unless you enable one of those paths.

Local-first is a security decision

Running Ultra on your own machine is not only a performance choice, it is a security one, and it is core to how we think about building this infrastructure. When it runs locally, your most sensitive material never has to leave your environment to be protected: tool calls, their payloads, the credentials they carry, and the audit trail they produce all stay on-device by default. There is no cloud component in the data path, so there is no third party sitting inside your trust boundary.

Contrast that with the common alternative of routing every request through a vendor's cloud proxy. That model asks you to send the exact traffic you are trying to secure, including secrets and internal data, to someone else's infrastructure to be inspected. It widens the attack surface, creates a high-value central target, and makes your enforcement dependent on that vendor's uptime and its handling of your data.

Local-first avoids all of that. Guardrails evaluate inline, on the same machine the traffic already flows through, so enforcement keeps working offline or in air-gapped environments and never depends on a remote service being reachable. Your data stays yours, your blast radius stays small, and the security layer does not become the thing you have to trust most.

This is a genuine differentiator for Ultra, and a deliberate part of our technological philosophy: put security where the traffic already is, and do not make teams hand their most sensitive data to another cloud to protect it. For teams that prefer not to run it themselves, Ultra also offers a hosted gateway that runs in the cloud, available today. It covers two needs: teams that simply want Ultra to run and maintain the gateway for them, and remote MCP connectors that require a hosted, always-on endpoint rather than a local process to reach. It is a deliberate option, not the default, so you can run Ultra in the cloud where that helps without giving up local-first anywhere it does not.

Governance vs. guardrails

Ultra separates two enforcement questions that are often conflated. Governance answers whether a connector, tool, or agent should be reachable at all. It operates on identity and its only action is to block. Guardrails answer a broader question: is this specific action or data component call safe? They inspect tool names, parameters, content patterns, and user or agent identity, and can block, alert, monitor, or redact. Governance is the coarse gate, guardrails are the fine-grained inspection behind it.

Guardrails

The Guardrails engine evaluates every tool call before it reaches an upstream connector. All active guardrails run in parallel, each returns a decision, and the strictest decision wins. The engine is fail-closed: if an evaluator errors or is unavailable, the request is blocked regardless of its configured mode.

Enforcement modes

Every guardrail runs in one of four modes. Block prevents the request from reaching the connector and returns a structured error containing the guardrail name, the rule that fired, a redacted excerpt of the matched content, and a remediation hint the agent can act on. Alert allows the request but emits a warning-level audit event. Monitor allows it and records silently. Redact allows it after masking matched content in both request and response, replacing matched values with [REDACTED].

Scoping

Guardrails are configured at three levels (organization, workspace, and device), with more specific scopes overriding broader ones. You set an org-wide baseline and let a workspace or a single device run stricter policy where needed. Configuration lives in Ultra Hub and syncs automatically to every connected device.

Built-in guardrails

Ultra ships built-in guardrails covering the most common MCP risks:

• Parameter Validation and Input Sanitization validates parameters against type and range constraints and dangerous patterns like path traversal, unsafe CLI flags, shell injection, and command chaining.
• Credential and Secret Protection blocks access to credential files and secrets passed in tool parameters, and redacts matched secrets in the audit log.
• In-Line Authorization and Destructive Action Blocking blocks destructive tool calls, dangerous SQL and shell operations, code and git write actions, and financial actions, each independently toggleable.
• PII and Personal Data Protection detects PII in parameters and resource URIs (emails, SSNs, phone numbers, Luhn-validated cards, IBANs, crypto addresses, PHI), with per-category toggles and a bypass list for tools that legitimately handle PII.
• Tool and Connector Isolation tracks values read from one connector within a session and blocks them from being written to a different connector, stopping cross-connector exfiltration, plus a configurable forbidden tool-sequence blocklist.
• Rate Limiting enforces per-connector request limits to prevent resource exhaustion and control quotas.
• Circuit Breaker watches each upstream's error rate and latency and trips to block traffic to a failing or slow connector, then probes for recovery before restoring it.

Beyond these, custom guardrails use the same engine and modes, matching on fields like tool name, connector, resource URI, any or named parameter, and user or agent identity, with operators from exact match to regex. See the guardrails product page for the full picture.

Anomaly detection

Guardrails act inline on individual calls, locally on the device. Anomaly detection is the complementary layer for teams that sync their devices to Ultra Hub, looking across traffic over time. It runs as a background process in the Hub that scans your organization's traffic on a schedule you configure, identifies suspicious patterns with an AI-driven analysis engine, and records findings in the dashboard and audit log. Running it centrally, off the request path, means it adds no per-call latency.

Each scan covers the traffic since the previous run. Findings are classified into categories (enumeration, privilege escalation, data exfiltration, injection, credential abuse, evasion, resource abuse, and behavioral anomaly), and a single finding can carry several when activity matches a multi-stage pattern. Every finding includes a risk score and level, a confidence, a recommended action, an explanation, the affected identities, and links to the underlying traces. Anomalies that cross severity thresholds escalate into Alerts.

Built for teams: Hub, identity, and RBAC

Ultra Hub is the control plane. It centralizes guardrail configuration, alerts, and traces across every device in an organization. Enterprise identity is ready out of the box: single sign-on, including SAML, plus SCIM provisioning, included on every tier with no SSO tax. Access follows a strict RBAC hierarchy (Owner, Admin, Member, Viewer, and a device-only Beacon role for linked devices), enforced at the organization, team, and workspace levels.

Alerting and integrations

Guardrail hits, security events, and anomaly findings surface as Alerts in a dedicated Alerts module in Ultra Hub, where your team can triage, resolve, and escalate them. From there, Alerts can route out to the tools you already run, including Slack, a SIEM like Panther, and Amazon S3. The same integrations carry your observability data: export traces and audit records to Panther, S3, or any OpenTelemetry-compatible backend such as Datadog or Grafana.

How it fits together

The layers compose into a defense model that follows the traffic. Governance decides what is reachable. The pipeline records everything that flows, with an audit trail that fails closed. Guardrails inspect each call inline and enforce policy in real time, also fail-closed. Anomaly detection watches the whole picture over time to catch multi-step patterns no single call would reveal. Ultra Hub ties it together for teams.

The through-line is the opening principle: see first, then govern. Observability provides the audit trail and the understanding, and guardrails and governance turn that understanding into enforcement that is precise instead of blunt. That is what it takes to let AI agents operate at scale without operating unchecked.

Put it all together and Ultra is a single security layer that an agent points to once, running on your own machine, that then sees, records, and controls everything an agent does. Each piece reinforces the others: local-first keeps sensitive traffic inside your trust boundary, the pipeline makes every action accountable, governance and guardrails enforce what is allowed in real time, and anomaly detection surfaces the patterns that only emerge across many calls. None of it requires changing your agents or your connectors, which is the payoff of vendor-agnostic building for MCP from the ground up instead of retrofitting: security thorough enough for a regulated enterprise and light enough for a solo developer to turn on in minutes. Agents will only keep taking more action on their own and become more powerful and sneaky. Ultra is how you let them, without losing sight or control of what they do.

Get started at ultra.security.