LAYER 1 · COVERED
Identity layer
Your identity provider decides who can log in. Solved, standardized, audited.
Enterprise MCP governance · self-hosted or managed
MCP — the protocol agents use to discover and call tools — is spreading through your company one server at a time. Amelfi puts every call on one governed path: agents see only approved tools, credentials never leave the broker, and every decision is on the record, inside your infrastructure.
The gap
Count the MCP servers already running in your org; the number isn't zero. Each one ships its own tool list, credential flow, and audit story — a pattern security can't approve at enterprise scale.
Your identity provider decides who can log in. Solved, standardized, audited.
Your API gateway governs service-to-service calls. Solved, standardized, audited.
Which tools may an agent discover — and call, with whose credentials? This is the boundary Amelfi governs.
The visual model
Thirteen illustrated guides trace the boundary from discovery and credentials through routing, policy, incidents, and operations.
The illustrated guide to MCP Gateway
A visual library for teams already building with MCP: policy-filtered discovery, credential brokering, private connectors, deployment boundaries, incident drills, and the control-plane triage loop.
The adoption tax
Each new MCP server re-implements the same boundary from scratch. Each one is a security review that never actually happens. Set the dial to your org and watch the tax compound — then pay it once instead.
the sprawl
Each hand-rolled server re-implements all thirteen subsystems: authentication, authorization, agent identity, tool-level access, credential handling, private connectivity, discovery and approval, audit logging, SIEM export, session handling, rate limits and quotas, health and metrics, incident response.every column is the same 13 subsystems, rebuilt from scratch — hover any cell.
the bill · per server
+ 4 security reviews owed · 0 completed
Flip the switch: Amelfi ships all thirteen as shared infrastructure — reviewed once by security, reused by every team, revoked from one place.
See the controlsIllustrative counts — the subsystems every hand-rolled boundary re-implements. Your list is probably longer. Read the full breakdown →
Control model
Deny overrides allow. Unauthorized tools are hidden at discovery — not denied after the fact.
Discovery is part of authorization. An agent's tool list contains only what it may call — everything else doesn't exist. Try the rule:
1 tool hidden at discovery. It doesn't exist to this agent.
Deny removed: crm_update_stage is now discoverable and callable in prod.
Service, user-delegated OAuth, agent-scoped, and workload credentials resolved at call time. The agent holds an opaque reference — nothing to leak, nothing to rotate out of a repo.
Private MCP servers and selected API operations registered with owner, risk, environment, and approval before anything is exposed.
Versioned, default-deny authorization with explicit deny and pre-deployment simulation. Every decision has a stable, human-readable reason.
Who, what, when, why, which policy version — searchable and exportable to your SIEM. Payloads and secrets never appear.
Revoke a tool, credential, server, agent, or session. Emergency disable shows blast radius before it fires and requires a reason.
The governed path
A governed call passes six gates between an agent and your backend. A denied call fails closed with a clear reason — before the upstream is ever touched.
> deny path: fail closed at the first gate that says no — clear reason, no upstream attempt, full audit record. See the six gates in the product →
Find your page
Default deny as the estate posture, policy simulated before rollout, and an audit stream your SIEM ingests. One pattern to approve instead of a review queue.
One review covers every team's agents Your page →Helm into your cluster, against your PostgreSQL, Valkey, IdP, and secret manager. Policy gates run in CI; sessions drain, reconnect, and revoke without tickets.
40 API endpoints become 3 governed tools Your page →Teams onboard to one approved path instead of building their own boundary. A 4–6 week pilot ends in evidence your security team verifies themselves.
Revocation is one click, in one place Your page →On the other side of the boundary? Tool owners and agent builders get less friction than the ungoverned path. Five worked scenarios live in Solutions.
There are five ways to solve this without us — including doing nothing. The comparison covers when each one is the right call, and where we lose.
Read the honest comparisonWhy we're building this
We spent years watching enterprises connect software to software — and reviewing what happens when that's done without governance. Agents raise the stakes: they discover capabilities on their own, hold credentials they shouldn't, and act faster than any review cycle.
We believe the answer isn't slowing agents down — it's giving them one path that security already trusts. That's what we're building, in the open where it counts: no invented metrics, no claimed certifications we don't hold, runnable evidence for everything we ship.
— the Amelfi team at DigitalAPI.ai
Next step
Read for five minutes, talk for twenty-five, or bring one real boundary and prove the whole path with your security team watching.
Quickstart, Helm install, policy guide. See exactly what you'd be running before you talk to anyone.
Open the docsA working session on your architecture: where the gateway sits, what your IdP and SIEM see, what a pilot would look like.
Book a walkthroughOne boundary, on your infrastructure: one allowed call, one denied call, one revocation — witnessed end to end.
Talk to the teamWe'll get back to you to schedule a walkthrough and scope your first governed boundary.