The first question every architect asks about a boundary in front of their API is what it costs them in milliseconds. The honest answer depends entirely on which parts of the system participate in a request — and for us, the answer is one.
· Article
Put anything in front of a production API and the first question is fair: what does this cost me per request? Security that taxes every call gets removed the first time a latency budget is missed, and everyone in the room knows it.
The answer has less to do with cryptography than with architecture. Verifying a proof is fast. What makes an authorization layer slow is not the maths, it is how many systems have to answer before a request can proceed. So the useful question is not how quick is your check, but who participates in my request.
Trustplane has two components, and conflating them is the source of most of the confusion.
The auth plane is the boundary. It sits in front of your API, in your environment, and it is in the path of every request. It holds the trust material it needs, verifies the proof presented, and returns a decision.
The control plane is management. It is where you declare trust anchors, enroll workloads, revoke access, and read the audit trail. It pushes policy to the boundary. It is not consulted when a request arrives, and it does not sit between your caller and your API.
That distinction is the entire latency story. Policy is pushed, not fetched. When a request lands, the boundary already has everything it needs to decide, because that material arrived earlier, out of band.
Trustplane
verified locally · no external hop
Client-side brokers
credential fetched per request · extra round trip
Same request. One of these leaves your network before it is answered.
Each request carries a proof. The boundary checks it against material it already holds, locally: that the proof is well-formed and genuine, that it is fresh rather than stale, that the caller matches a trust anchor you declared, that the action and route are within what that anchor allows, and that this proof has not been presented before. Then it allows or denies with a reason code, and writes the decision.
None of those steps require a network call to us. There is no per-request lookup against a hosted service, no token introspection endpoint, no credential fetch. The work is local, in-process, in front of your API.
Being straight about the interesting part: a proof that is valid exactly once has to be recorded as used, or single-use is a promise rather than a property. Something in your deployment has to remember what it has already seen, for as long as a proof could plausibly be replayed.
That is a real design consideration and it is worth asking any vendor about. In our case it stays inside your deployment, alongside the boundary, rather than being resolved by a call to our infrastructure. It is the same class of problem as a nonce cache in front of any replay-resistant protocol, and it is bounded by the freshness window rather than growing forever.
We would rather name this than pretend a boundary is free. It is the one stateful thing in an otherwise stateless check.
Average latency is the wrong thing to design around. What determines whether a security layer survives contact with production is what happens when a dependency is unavailable.
If a hosted service participates in your request path, its availability becomes your availability, and its worst-case tail becomes your worst-case tail. That is not a criticism of anyone's engineering, it is arithmetic about dependencies.
With the control plane out of the path, a control-plane outage degrades management, not enforcement. You would temporarily be unable to enroll a new workload, edit an anchor, or read fresh audit data through the console. Requests keep being verified against the policy the boundary already holds, and they keep being allowed or refused correctly. Enforcement does not depend on us being reachable.
The same logic applies to the boundary itself. It is a component you run, scaled and monitored like the rest of your infrastructure, and it fails closed: if it cannot verify, it does not serve.
Products that solve the outbound problem place a component next to the caller, attest the workload, and supply it a credential for the target it is calling. Several of them run distributed local components specifically so that step does not require a remote call, and it would be wrong for us to claim otherwise.
The architectural difference is not speed, it is who participates and what arrives at your door. In that model the credential is obtained on the caller's side and your API then receives and trusts it. In ours, nothing is issued to the caller, the boundary you own does the verifying, and your API trusts a decision made inside your own perimeter.
So the honest comparison is about dependencies and trust placement, not about a millisecond scoreboard.
We are not publishing latency numbers in this post, and you should be suspicious of any young product that leads with them.
Real figures depend on your hardware, your deployment topology, your proof type, and how you have configured freshness and replay retention. A number produced on our laptop tells you nothing about your p99. Anyone can publish a favourable benchmark; almost nobody publishes the configuration that produced it.
What we will publish, once the pilot programme has produced measurements on real traffic rather than synthetic load, is a methodology alongside the numbers: the hardware, the topology, the configuration, and the distribution rather than the mean. Until then, treat the architectural argument above as the claim, and measure the rest yourself.
If you are evaluating this, these are the questions worth putting to us, and to anyone else in this category.
The last one is the test we would want to run if we were buying. Disconnect the vendor and send a request. If the boundary still decides correctly, the vendor was never in the path. If it does not, you have found your dependency.
Every request proves itself — no keys, anywhere.
Put the boundary in front of one API and measure it yourself.