Every authorization system has to answer a question that sounds like plumbing and turns out to decide the architecture. Where does the permission data live?
For us that data is three things. Grants, meaning what an agent has been authorized to do. Audits, meaning what it did and what was decided. Precedents, meaning approvals that have happened often enough to become a rule.
There are two obvious answers. Either the vendor runs the database and customers keep their grants, audits and precedents there. Or each customer hosts an endpoint and the vendor connects out to it, so permission data never touches vendor infrastructure.
The second has an appealing shape. Permission data is the most sensitive thing a customer will ever hand an authorization vendor, because it is a map of who can reach what. Letting customers keep it looks more respectful and easier to sell to a security team. It also looks like more work. We wanted to know whether that work bought anything real.
So we read how everyone else does it.
What eight vendors do
These come from vendors' own product and documentation pages, read the same day. We did not independently verify the claims. We are reporting what each company says about itself, because on this question what they choose to advertise is the finding.
| Vendor | Control plane | Decision point | Cloud on the hot path? |
|---|---|---|---|
| Permit.io | Theirs — policy editor, GitOps, audit, role and relationship graph | Local PDP (OPA or Cedar) in the customer VPC, synced via OPAL | No. Sub-millisecond, no lookup |
| Cerbos | Cerbos Hub, managed | Open-source stateless PDP in customer infrastructure, including air-gapped | No. "Without requiring any cloud lookups" |
| AuthZed | Three product tiers | Cloud, Dedicated, or self-hosted Enterprise | Depends on tier |
| Arcade | Theirs | Runtime deployable customer-side | Optional. "Credentials never leave the runtime" |
| Aembit | Theirs — policies, access logs, audit | Their broker and MCP gateway | Yes. Traded for zero secrets in the customer environment |
| Descope | Theirs — credential vault, agent directory, policies | Theirs | Yes, but Cross-App Access lets the customer's own IdP be the authority |
| Braintrust | Theirs | Data plane deployable on customer infrastructure | Hybrid option |
| Baseten | Theirs | Cloud, customer VPC, or hybrid | Three tiers, stated on the homepage |
Two things fell out of this table that we did not expect.
Nobody dials in
Not one vendor connects into a customer-hosted endpoint. The model is simply absent from the market.
Even the most conservative vendors invert it. Cerbos ships its decision point as open source, stateless, running inside the customer's own network, including air-gapped environments. That is about as customer-controlled as authorization gets. The connection still runs the other way: the customer's PDP pulls policy from the Hub, and the Hub never initiates anything into the customer.
The reason is not really about data. A vendor that connects into N customer networks has signed up for N sets of NAT traversal, N firewall exceptions, bidirectional authentication, and N independent availability problems. That last one is what kills it. Every one of those becomes a support ticket addressed to you about an outage inside somebody else's network.
The real axis is not where the data sits. It is which direction the connection runs. Customer to vendor, always. Push or pull, but outbound from the customer. Once that is settled, most of what made the customer-hosted option look expensive goes away, because you can put the data wherever you like without ever dialing in.
The control plane and the decision point are different machines
The second pattern is sharper. Among the vendors whose whole business is authorization — Permit, Cerbos, AuthZed — the same architecture shows up three times independently.
The control plane is hosted. The decision point is not. Nothing that has to answer in milliseconds is allowed to depend on a network call to the vendor.
Permit puts it most bluntly, describing itself as the control, data and enforcement plane, "not a dashboard in front of someone else's PDP." Cerbos markets the property directly: decisions happen locally at the edge, with no cloud lookup. Both let you author, version and audit centrally, then materialize the decision locally.
This is not squeamishness about data residency. It is a correctness argument, and it is the one that settled our design.
What a network hop does to an audit log
If a host has to ask a remote service before it can allow a tool call, that service's uptime silently becomes the customer's uptime. That is bad on its own. What makes it worse is how the failure looks afterwards.
An authorization service that cannot be reached does not return "I could not reach the authorization service." It returns something shaped like a decision. The most common shape is no matching grant, which is also exactly what a correct denial looks like when an agent genuinely has no authority. An outage and a legitimate denial produce the same row.
That is an expensive class of bug, and not because anything leaks. It fails closed, which is the right direction. The problem is what it teaches the operator. Someone reviewing denials sees a policy doing its job. They are looking at an outage wearing a policy's clothes. Any design that puts a network hop between a host and its decision inherits this by construction, and no amount of logging discipline downstream fixes it, because the information was lost at the moment the decision was made.
The IETF is arriving at the same requirement from a completely different direction. The WIMSE working group's cross-organizational delegation draft states it as a MUST: a relying party has to reach an authorization decision "without a synchronous call to the originating organization on the critical path." They got there from cross-domain delegation. We got there from what a denial means when you read it back a week later. Same rule. When two unrelated lines of reasoning land on one constraint, it is usually load-bearing.
Where we landed
We run the database. Customers do not host an endpoint, and we never connect into their network.
But "we run the database" is not the whole answer, and treating it as one is where this gets subtle. The three artifacts have three different answers.
Audits are the easy case. Append-only, write-heavy, never on the decision path. The host ships events out and nothing waits on the round trip. The real design constraint here is the opposite of availability: an audit event carrying raw tool arguments turns an audit table into a lake of customer business data, with every obligation that implies. Redact or hash at the host, before the event leaves.
Grants are the case that matters. We are the system of record and the issuing authority. The host is where the decision happens. Grants are materialized down to the host as signed, expiring artifacts, and the check is local. This is the same shape Permit reaches with OPAL and Cerbos reaches with a stateless PDP. We reached it from the audit-log argument above rather than from latency, which is a good sign that the shape is right.
Precedents are derived from audits, read at decision time, and tolerant of being slightly stale. Computed centrally, pushed down as a snapshot. A precedent that is an hour old is fine. A precedent that requires a network call to consult is not.
The hard part left over is the one WIMSE also names and does not solve. Deciding locally and revoking instantly pull against each other, and no architecture makes that go away. The honest version is that staleness has to be bounded and explicit. A host should know how old its grant material is and behave differently as that number grows, rather than assuming a freshness it does not have.
One more thing worth watching. Both the MCP Enterprise-Managed Authorization extension and Cross-App Access are pushing authority toward the customer's own identity provider. An enterprise that says the authority has to be their Okta rather than your database is not being unreasonable, and that request is going to become common. Holding the grants is fine. Assuming you are the only possible authority over them is not.
If you are making this call yourself, do not start from where the data should live. Start from what is allowed to sit on the decision path, and let that decide the rest.