Comparison · agent governance · Ultra Security

Ultra Security, measured.

Ultra runs on the host as a proxy between agents and the MCP tools they call, enforcing policy inline before a call reaches its server. This page scores that architecture across 16 capabilities against the same capabilities in Agen.co — with the sources, the scoring ladder, the six rows that come out level, and the row Ultra wins.

The short answer

  • Ultra blocks, redacts or allows every MCP tool call before it reaches its server, and the pipeline is fail-closed. This is not a comparison about whether they enforce — they do, inline.
  • The enforcement surface is the MCP protocol. An agent action that does not travel as an MCP call — a direct API request, a browser session, a customer-facing agent — has no decision point.
  • Ultra resolves a real person on its top attribution tier, through SSO and SCIM. Below it, credit falls to the gateway's owner, and then to no one — an unattributed client principal.
  • Agen binds every action to a named accountable owner, wherever the agent runs and whatever protocol it speaks, and judges it in context in under 30ms.
  • Six of the sixteen scored rows come out level, including MCP tool governance, masking, the audit record and the gateway itself. Ultra wins on ecosystem breadth.
  • The two products are not mutually exclusive. Ultra governs the MCP path; Agen governs the action and the accountability behind it.
The long read

A proxy on the host, and the protocol it can see.

Ultra is one of the most architecturally honest products in this category, and the scored table reflects that: six ties out of sixteen, and a row they win outright. The distinction worth a buyer's time is not enforcement. It is what the enforcement is anchored to.


One binary, on the machine

Ultra runs locally on each user's machine as a single binary. MCP clients launch it as a subprocess, and all processing happens on-device — the documentation is explicit that there are no cloud components in the data path. The client sees Ultra as one MCP server; Ultra connects to the real servers behind it and presents their combined tools as a single interface.

Every request crosses an interceptor chain on the way out and the same chain in reverse on the way back: trace, logging, audit, metrics, governance, guardrails. Policy is configured centrally and synced down to every gateway, so a fleet shares one policy surface without a cloud hop on the request path. For a security team that cannot send agent traffic to a vendor, this is a genuinely strong property, and it is why the deployment and data-residency row comes out level.

Enforcement is real, and it is pre-execution

There are four enforcement modes: block, alert, monitor and redact. Block returns a structured error and the call never reaches its server. Redact masks matched content in both the request and the response and lets the call proceed. Guardrails are fail-closed — if an evaluation errors or an evaluator is unavailable, the request is blocked regardless of the configured mode. That is a deliberate and defensible design, and it is why the masking row is a tie.

The built-in set is substantial: parameter validation against path traversal and shell injection, credential-file and cloud-metadata blocking, PII detection with Luhn and IBAN validation, rate limiting, and a circuit breaker. One control deserves particular credit — tool and server isolation tracks the values a session has read from one server and blocks them from being written to a different one, which stops the read-here-send-there exfiltration pattern that most policy engines cannot express at all.

The protocol is the boundary

Everything above applies to MCP. That is a large and fast-growing surface — it is how coding agents and desktop assistants reach GitHub, Postgres, Slack and Salesforce today — and governing it completely is a real accomplishment. It is also a boundary with a definite edge.

  • Same machine, different path.Ultra is on the endpoint, deployable zero-touch across a fleet. It sees what crosses the proxy. A process on that same laptop calling a REST API directly, or running a CLI against production, is not on that path.
  • The browser.The documented clients are desktop applications and IDEs. An agent acting inside a browser session is not making MCP calls through a local proxy, and no browser enforcement point is described.
  • Agents you do not run.Every documented deployment path is an employee machine, an MDM-managed fleet or a cloud development environment. A customer-facing agent lives outside all three.

None of these are shortcomings in what Ultra built. They are the shape of a product that chose one protocol and governs it thoroughly. The question for a buyer is whether the agents they are accountable for stay inside that shape.

Who the record names

This is the row that decides the page, and it is closer than the category usually is. Ultra does resolve a human. Its identity model is documented as covering every person, service account and device making MCP tool calls, and members arrive through SSO and SCIM from the organisation's own directory.

Attribution then resolves through three tiers, in order. Authenticated: the event carries a real session user, and that is genuine per-action human attribution. Gateway-attributed: no session user, so the gateway's owner is credited instead — accountability lands on whoever owns the machine rather than on whoever acted. Unattributed: neither is available, and the traffic is grouped under a client principal such as claude-desktop with a version number.

Ultra surfaces the lower two tiers as work to be done, with an assurance badge on every identity and an unattributed-activity view to work through. That is the honest way to build it. It also means the record's answer to who is answerable for this action is a confidence level rather than a name — and the agent itself is a fingerprinted client, not an identity object with a lifecycle of its own.

Agen inverts the order. The agent is a first-class identity carrying a named accountable owner before it does anything, and every individual action is attributed to that person at the moment it happens, judged in context in under 30ms. There is no fallback tier, because attribution is a precondition of acting rather than a property recovered afterwards.

What is inline and what is scheduled

Ultra's guardrails are inline and deterministic. Its behavioural layer is not, and the documentation is refreshingly direct about it: anomaly detection runs as a scheduled background process in the cloud console on a cadence between fifteen minutes and twenty-four hours, and individual gateways do not evaluate calls inline. An LLM scores traffic across seven threat categories using full session history rather than isolated calls, which is a better analysis than a real-time check could do — arriving after the actions it describes.

Both designs are defensible and they answer different questions. It is worth knowing which layer catches what, because the deterministic rules are the ones standing between an agent and a destructive call.

What it costs to run

Ultra publishes no pricing page. The site commits to free to start, scaling with usage, and no per-seat, per-host or SSO charge — a buyer-friendly answer, and not per-seat, which is the failure mode this row usually catches. Enterprise SSO sits on the Enterprise plan. Time to a first governed call is short: one binary, point the clients at it, or push it zero-touch through Jamf with SCIM resolving each gateway to an employee.

Where Ultra is strongest

  • Ecosystem reach, and the row they win.Their server registry scores every MCP server on a 0–100 composite across eleven signals, scans each version for injection, secrets, CVEs and obfuscation, and signs the results into a public transparency log — across every major public registry. We are a focused platform rather than a marketplace, and this is the row where that shows.
  • On-host deployment, scored level.All processing on the device, storage local by default, offline operation, optional sync. For a team that cannot route agent traffic through a vendor, that is decisive, and we score level on it.
  • The audit guarantee, scored level.Their audit layer blocks a successful operation if it cannot be recorded, while every other layer in the pipeline absorbs errors silently. Choosing completeness over convenience in exactly one place is the right place to choose it.
  • MCP governance and data protection, scored level.Per-call allow and deny, masking in both directions, and cross-server exfiltration tracking. On the protocol they chose, they are as deep as we are.
The scored comparison

Sixteen capabilities, scored side by side.

Runtime enforcement, identity and accountability, coverage, and what it costs to operate — each scored 0–5 on capability depth against vendor documentation, including the six rows that come out level and the row Ultra wins.

Capability depthNoneCompleteUltra SecurityAgen.co
01 · Runtime enforcement
Verdict rendered at the moment of actionUltra SecurityInline on every MCP callCapable3/5Agen.coPer-action verdicts, <30msComplete5/5
Decision latency, published and measuredUltra SecurityLocal process, no number publishedPartial2/5Agen.co<30ms, published, no samplingComplete5/5
Masking or redaction at action timeUltra SecurityRedact mode, request and responseComplete5/5Agen.coMasking at action timeComplete5/5
Human-in-the-loop approval on a risky actionUltra SecurityBlocks rather than escalatesBasic1/5Agen.coHuman-in-the-loop, built inComplete5/5
02 · Identity & accountability
Agent has a first-class identity objectUltra SecurityClient fingerprint, not an objectPartial2/5Agen.coFirst-class agent identityComplete5/5
A named human accountable for each agentUltra SecurityGateway owner, not per agentCapable3/5Agen.coNamed owner, every agentComplete5/5
Each individual action attributed to that humanUltra SecurityThree-tier, degrades to unattributedCapable3/5Agen.coAttributed per actionComplete5/5
Audit record per actionUltra SecurityBlocks the call if unrecordableComplete5/5Agen.coA record per actionComplete5/5
03 · Coverage
Endpoint enforcementUltra SecurityOn device, MCP traffic onlyCapable3/5Agen.coAgenShield on the deviceComplete5/5
Browser enforcementUltra SecurityNo browser enforcement pointBasic1/5Agen.coBrowserShield, early accessCapable3/5
Gateway / API enforcementUltra SecurityThe gateway is the productComplete5/5Agen.coOne governed gatewayComplete5/5
MCP tool governanceUltra SecurityEvery call, allow and denyComplete5/5Agen.coMCP tools governed per callComplete5/5
Network-layer enforcementUltra SecurityNot their layer eitherPartial2/5Agen.coNot our layer — works alongsidePartial2/5
04 · Operate & buy
Pricing unit — what you are billed perUltra SecurityUsage-based, not publishedCapable3/5Agen.coPer governed agentComplete5/5
Deployment model and data residencyUltra SecurityOn host, local by defaultComplete5/5Agen.coSaaS, hybrid, or on-premComplete5/5
Ecosystem and marketplace breadthUltra SecurityIndexes every public MCP registryStrong4/5Agen.coFocused platform, not a marketplacePartial2/5
9 rows Agen.co leads6 tied1 rows Ultra leads
Levels reflect capability depth and supporting evidence. Capability descriptions based on vendor public documentation, August 2026.
What the scores mean

One boundary, and it is not enforcement.

Ultra blocks before execution, fail-closed, on every call that crosses it. Six rows come out level and one goes to them. This comparison does not turn on whether they can stop an action.

It turns on reach and on anchoring. The enforcement surface is one protocol, so an agent acting any other way has no decision point at all — and where a session user is not present, the record names a machine's owner or no one. Agen governs the action itself, wherever the agent runs, with a named person answerable for every one.

The findings

Four groups, four conclusions.

The same argument the table makes, read as findings rather than scores.

01

Enforcement is real, and it is pre-execution

Block, alert, monitor and redact, evaluated before the call reaches its server, with a fail-closed pipeline that blocks on evaluation errors. Masking scores level. The vocabulary stops short of a step-up challenge or an approval path, and no decision latency is published — the modes are the whole set, which follows from a subprocess having no channel to reach a person.

approval pathnone
02

A person on the top tier, a machine owner below it

Members arrive through SSO and SCIM, and an authenticated event carries a real session user. Attribution then falls back to the gateway's owner, and then to an unattributed client principal. The agent itself is a fingerprinted client rather than an identity object, so the record answers who is answerable with a confidence level rather than a name.

accountable human per actiontiered
03

One protocol, governed thoroughly

MCP tool governance and the gateway both score level — on the surface they chose, the depth is there. It is one surface. A direct API call from the same machine, a browser session, or a customer-facing agent never becomes an MCP call, so none of them reach a decision point.

enforcement surfaceMCP calls
04

Fast to run, and strong on the ecosystem

One binary, minutes to a first governed call, zero-touch across a fleet through MDM, and processing that never leaves the device. Their MCP server registry — scored, scanned per version and signed into a transparency log — wins the ecosystem row outright. No pricing page is published.

published pricingnone
Watch it happen

Every action resolved to the human who answers for it.

Not a confidence tier and not the owner of the machine — a named accountable owner carried on every agent, and every individual action attributed back to them, judged in context before it runs.

agent ownership · live product scene
What closes the gap

Keep the proxy. Anchor what crosses it to a person.

Your gateway keeps governing the MCP path, on the host, exactly as it does today. Agen governs on top: every agent carrying a named accountable owner, every action judged against your policy at the moment it happens in under 30ms — on the endpoint and in the browser as well as at the gateway, and for the agents your customers touch as well as the ones your staff run.

Select a capability

Continuous discovery across your IdP, gateway, devices, cloud, and registries. Nothing has to self-register: agents are found, risk-scored, and resolved to a named human before they act.

  • Agentless and API-based across five surfaces
  • First-party, custom, and third-party agents alike
  • Every agent mapped to an owner, approver, and escalation
Agen Discover AI agent discovery flow: any identity provider, productivity suites and assistants, cloud, gateway, endpoints, and MCP server registries all feed one agent registry where every AI agent is inventoried, risk-scored on arrival, given a named human owner, and shadow AI is surfaced.
Discovery pulls from five surfaces into a single agent registry — no SDK self-registration required.
ClosesWhich agents are running that nobody registered?
no SDK required5 surfacesowner-mapped
Discover in depth →

Methodology

How these scores were reached.

Forty-two capabilities were scored against the ladder in our internal rubric; sixteen are published here. Four were dropped and are not published on any page — two because the only finding was an absence in public documentation, which is weaker evidence than a documented limit, and two because publishing them would have been a manufactured loss on surfaces this vendor has never claimed. Three further capabilities are held back because our own column could not be verified against the rubric baseline, including audit-first rollout, where Ultra's monitor mode and historical dry-run are strong enough that the row would likely not go to us. Six published rows are ties and one goes to Ultra; both are printed rather than filtered.

Sources8 primary
Evidence ledger
  1. Ultra Security documentation — ArchitectureTier AUltra runs locally on each user's machine as a single binary. MCP clients launch it as a subprocess and all processing happens on-device. There are no cloud components in the data path.
  2. Ultra Security documentation — GuardrailsTier AFour enforcement modes: block, alert, monitor and redact. Guardrails are fail-closed — if an evaluation error occurs or an evaluator is unavailable, the request is blocked regardless of the configured mode. Built-in guardrails cover parameter validation, credential and secret protection, in-line authorization and destructive-action blocking, PII and PHI detection, tool and server isolation, rate limiting and a circuit breaker. Any rule can be dry-run against historical traffic before enforcement.
  3. Ultra Security documentation — IdentitiesTier AAn identity is every person, service account and device making MCP tool calls. The effective identity for every event resolves through a three-tier fallback: authenticated, where the event carries a Hub session user provisioned by SSO or SCIM; gateway-attributed, where the gateway owner is credited instead; and unattributed, grouped by MCP client principal.
  4. Ultra Security documentation — PipelineTier AThe audit layer is designed to block a successful operation if it cannot be recorded, so every completed MCP call has a corresponding audit record. The other pipeline layers absorb errors silently.
  5. Ultra Security documentation — Anomaly DetectionTier AAnomaly detection runs as a scheduled background process in Ultra Hub on a cadence of 15 minutes to 24 hours. Detection is asynchronous and centralised — individual gateways do not evaluate calls inline.
  6. Ultra Security documentation — MDM DeploymentTier AZero-touch fleet deployment through Jamf Pro with macOS device management. SCIM provisioning is required for per-user identity resolution; without it, gateways are attributed to the admin who created the deploy key.
  7. Ultra Security documentation — LedgerTier AA security registry for MCP servers with a composite 0–100 trust score across eleven signals, per-version scanning for injection, secrets, CVEs and obfuscation, and Sigstore-signed scores recorded in a Rekor transparency log, indexing the MCP Registry, Smithery, Glama, mcp.so, PulseMCP and Cursor.
  8. Ultra Security — product siteTier BFree to start, scaling with usage, with no per-seat, per-host or SSO charge. No pricing page is published. Supported clients are desktop and IDE MCP clients including Claude, ChatGPT, Cursor, Windsurf, Claude Code and Gemini.

Vendor capabilities change. If a row is out of date or wrong, tell us and we will re-score it — corrections are published with the date they were made.

FAQ

Questions, answered.

What is Ultra Security?
It is a security product for the Model Context Protocol. It runs locally on each machine as a single binary that MCP clients launch as a subprocess, sitting between those clients and the MCP servers they call. Every request passes through an interceptor chain that traces, logs, audits and measures it, then applies governance rules and guardrails before it reaches the upstream server. Around that sit an inventory of every server, client and tool, an identity view, a scheduled anomaly-detection service, and a security registry that scores public MCP servers.
Does Ultra Security actually block agent actions, or only observe them?
It blocks. Guardrails and governance rules both evaluate before a call reaches its server, and a matched block rule returns a structured error rather than forwarding the request. The pipeline is fail-closed: if an evaluation errors or an evaluator is unavailable, the call is blocked regardless of the configured mode. The four enforcement modes are block, alert, monitor and redact.
What is the difference between Agen.co and Ultra Security?
The enforcement surface and what the decision is anchored to. Ultra governs the MCP protocol, thoroughly and inline, on the host. Agen governs the action itself — on the endpoint, in the browser and at the gateway, for agents built on any stack and for customer-facing agents as well as internal ones — and binds every one of those actions to a named accountable human at the moment it happens. On the sixteen published rows the two products come out level six times, and Ultra wins on ecosystem breadth.
Can Ultra Security tell you which person is behind an agent's action?
On its top tier, yes. Attribution resolves through three documented tiers: an authenticated event carries a real session user provisioned through SSO or SCIM; if there is no session user, the owner of the gateway the event came through is credited instead; if neither is available the activity is grouped under an unattributed client principal such as a desktop client and version. Ultra surfaces the lower tiers so teams can work through them.
Does Ultra Security support step-up authentication or human approval?
Its documented enforcement modes are block, alert, monitor and redact, and the built-in control closest to approval blocks destructive actions rather than routing them to a person for a decision. No step-up or approval path appears in the public documentation.
Do Agen.co and Ultra Security overlap or work together?
They overlap on the MCP path and cover different ground either side of it. Ultra enforces on MCP calls from the host with no cloud round-trip. Agen governs the action across the endpoint, the browser, the gateway and the cloud, for internal and customer-facing agents alike, with a named owner on every agent and a record per action. Running a protocol proxy and an action-level governance layer together is a coherent architecture.
How were these scores produced?
Forty-two capabilities were scored 0–5 against a published ladder using vendor public documentation, and sixteen are published here. Ties and rows the competitor wins are printed rather than filtered out. It is scored against vendor public documentation and re-scored on a schedule we hold ourselves to.

Bring your own comparison.

Send us the rows you would score differently. We will show you the evidence behind ours, and where we are wrong we will change the page.