{brand} — Compare

The verdict, first

Seven capabilities, five alternatives.

Read the row you care about, then jump to that column's section below — each one covers when the alternative is genuinely the right call. The last row is where several of them beat us.

Boundary capability	Build it yourself	API gateway	Vendor-hosted plane	Your IdP	Wait and see	Amelfi
Per-agent tool list, computed per caller	~ you build it	✗	✓	✗	✗	✓
Unauthorized tools hidden at discovery	~ subtle to build	✗	~ vendor-dependent	✗	✗	✓
Credential brokering — agents hold opaque refs	~ you build it	✗	~ vendor-dependent	✗	✗	✓
Agent identity + environment in policy	~ you build it	✗	~ vendor-dependent	~ login only	✗	✓
Control plane stays in your infrastructure	✓	✓	✗ theirs	✓	✓	✓ self-hosted
One security review covers N servers	✗ N reviews	✗	✓	✗	✗	✓
Nothing new to deploy or operate	✗	✓	✓	✓	✓	✗ you run one more service

~ = possible, but you build and maintain it. Column headers jump to the honest long-form argument for each — including the rows where an alternative wins.

Build it yourself

Roll your own governance layer.

"It's a proxy with auth. We can build this in a couple of sprints."

The same gate, rebuilt per teamN servers = N security reviews

When it's the right call

You run one or two MCP servers and no sprawl is coming — a shared control plane is overhead you don't need yet
You have bespoke transport or runtime requirements no off-the-shelf gateway will meet
You have a team funded to maintain it long-term — not as a side project next to their real job

The boundary it misses

One reviewable control plane vs N re-implementations — security approves a pattern once, or reviews every build forever
Policy-filtered discovery is subtle to build: tools must be hidden per caller, not refused after the fact
Credential brokering where agents hold opaque references and never see secret material
Constrained OpenAPI-to-MCP import — selected operations become tools, nothing else exists
Release evidence security can verify — signed builds, SBOM, runnable test scenarios — reproduced on every one of your releases

> our counter: you can build the first server. What doesn't scale is rebuilding authn, authz, credentials, routing, revocation, and audit for every server — then re-proving it to security on every release.

Your existing API gateway

Put it behind the gateway you already run.

"We already govern APIs. Add a route, add a rate limit, done."

Routes pass through — tools aren't a concept hereKeep it. We sit alongside.

When it's the right call

The traffic is pure north-south HTTP with no agent or tool semantics involved
All you need is rate limiting and routing — no per-caller tool exposure, no credential brokering
It keeps that job with us in place — we govern the agent-to-tool layer alongside your existing API gateway, not instead of it

The boundary it misses

No per-agent tool list — it can't compute what a specific agent is allowed to see and call
No discovery filtering — unauthorized tools stay visible and get refused, instead of never existing
No credential modes — service, user-delegated OAuth, agent-scoped, and workload credentials aren't route concepts
No agent identity or environment in policy — "which agent, on which surface, in which environment" isn't expressible

> our counter: an API gateway governs HTTP routes. Agent-to-tool is a policy and identity problem at the MCP semantic layer, not a route problem.

A vendor-hosted MCP control plane

Point your agents at someone else's cloud.

"Connect your servers to our platform and stop worrying about infrastructure."

Every governed call round-trips their estateSelf-hosted mode: zero mandatory egress

When it's the right call

Your security team accepts vendor-hosted control planes for this class of traffic
You want zero-ops and are willing to trade custody of the boundary for it
The tools involved are already public or low-sensitivity — nothing private transits the vendor

The boundary it misses

Private tool traffic and control-plane metadata leave your infrastructure — tool names, call patterns, and identities live in someone else's estate
Opaque policy — you trust the vendor's authorization model instead of inspecting a default-deny model you operate
Our fully self-hosted mode has no mandatory vendor egress — verifiable at your firewall
It runs on your own PostgreSQL, Valkey, OpenTelemetry, and SIEM — the evidence trail is yours, on your infrastructure

> our counter: if security can't route private tools through someone else's control plane, the control plane has to live in yours.

Your identity provider

Let the IdP handle it.

"Access control is an identity problem, and identity is already solved here."

Who gets in — solved. Which door, with whose key — not an IdP jobYour IdP stays authoritative with us

When it's the right call

You only need SSO and coarse access control — who may reach an application at all
And to be clear: it stays authoritative for identity with us — we integrate with your IdP, we don't compete with it

The boundary it misses

Per-tool, per-agent, per-surface, per-environment authorization — an IdP decides who logs in, not which tool an agent may call in prod
Discovery as authorization — filtering the tool list itself isn't an identity operation
Credential brokering — resolving the right upstream credential at call time, without handing it to the agent
Private routing — reaching registered internal backends is a data-plane job an IdP was never built for

> our counter: your IdP stays the source of identity. We add what it doesn't do at the tool-call boundary.

Wait and see

Do nothing, for now.

"MCP is early. Client apps already show approval prompts. Let's revisit next year."

Sprawl compounds quarterly — keys copied, approvals unownedCount yours today; it isn't zero

When it's the right call

You genuinely have no agent-to-private-tool activity planned — nothing internal will be exposed to agents this year
If that's true, waiting costs you nothing. Check with your teams first — it's often already false

The boundary it misses

Sprawl compounds — every quarter, another team ships its own server, its own credential path, its own audit story
Retrofitting governance onto N live servers costs more than making the approved path the easy path now
Client-side approval prompts protect one end user, on one surface — not the enterprise behind them

> our counter: provider approval prompts are not enterprise policy, inventory, credential governance, or owned audit.

Fair questions

The objections we hear most — answered straight.

These come up in almost every evaluation. Where the honest answer is "not yet" or "we're the wrong product," that's the answer you'll get.

Why wouldn't we just build this ourselves?

For one or two servers with a funded owner, you can — and we say so above. The problem is the N-th server: each one re-implements authentication, authorization, credential handling, routing, revocation, and audit, and each one is a separate security review. A gateway turns N reviews into one — and the subtle parts (policy-filtered discovery, opaque credential references, release evidence) are exactly the parts hand-rolled builds skip first.

Can't our existing API gateway cover this?

Keep it — it's the right tool for service-to-service HTTP, and we sit alongside it. What it can't do is compute a per-agent tool list, hide unauthorized tools at discovery, broker per-call credentials, or evaluate agent identity and environment in policy. Those are MCP-layer semantics, not route configuration.

We can't send private tool traffic through a vendor's cloud.

Neither can many of the security teams we talk to — that constraint is why the product exists. Fully self-hosted mode runs entirely in your infrastructure with no mandatory vendor egress, on your own PostgreSQL, Valkey, OpenTelemetry, and SIEM. You can verify the egress claim at your firewall. A hybrid mode exists if you want a managed admin experience while the data plane stays home.

Doesn't a gateway add latency and a single point of failure?

The hot path is a Rust data plane with hot state in your Valkey, deployed and scaled on your infrastructure like any service you run. And yes — it is deliberately the one path all governed traffic takes. That concentration is the point: one place to enforce policy, one place to revoke, one place to audit. You operate its availability the same way you operate your other tier-one services.

Does it work with our IdP, secret manager, and SIEM?

That's the design center. OIDC and SAML against your identity provider, workload identity for non-human callers, a Vault-compatible credential broker against your secret manager, audit export to your SIEM, and OpenTelemetry to your observability stack. Your systems stay authoritative; the gateway plugs in.

What about prompt injection?

We reduce the structural attack surface: default deny, approved-only tools, discovery hidden per caller, host allowlists, schema validation, and rate limits mean a manipulated agent can only call what it was already allowed to call, within bounds. What we don't do is inspect content — ML-based prompt-injection detection is roadmap, not shipped, and we won't imply otherwise.

Will secrets end up in your logs?

Structurally, no. The credential broker resolves secrets server-side and hands agents opaque references — secret material never transits the agent, the audit stream, or the logs. Releases ship with automated no-secret gates that fail the build if secret material appears where it shouldn't.

Can you host our MCP servers for us?

No. We govern the boundary between agents and tools — we don't host your servers and we don't orchestrate your agents. If managed hosting is your primary need, we're the wrong product, and we'll tell you that in the first call rather than the last one.

The fine print, in large print

What we don't do — and don't claim.

A comparison page is only useful if it's honest about our side too. These are the things you might expect from this category that we do not ship today.

NOT IN THE PRODUCT: content inspection / DLP · ML-based prompt-injection detection · tamper-evident audit chains. Our audit is metadata-only and exportable — we don't claim inspection or cryptographic chaining we don't have.

WE DON'T OFFER: managed hosting of your MCP servers · certified air-gap deployments · SCIM provisioning / device posture. If one of these is your deciding requirement, we're not your vendor yet.

ROADMAP, NOT A CLAIM: formal certification is on the roadmap. Until an auditor signs, we don't say "certified" — and we'd encourage you to ask every vendor for the certificate, not the sentence.

Next step

Bring your hardest question.

A 25-minute walkthrough on your architecture — including the questions above, asked about us. If an alternative genuinely fits you better, we'll say so.

Book a walkthrough Talk to the team