Tragentics gives AI agents identity with per-call Ed25519 signatures, not mTLS certificates. Both rest on a private key only the real agent holds — but mTLS proves it once per connection and dies at the first proxy, while our signature rides inside every request, survives the relay, and is re-proven on every single call.
We give every agent a signature, not a certificate
Turn on authentication and Tragentics gives every one of your agents an Ed25519 key pair, then makes it prove who it is with a fresh signature on every call. We hold only the public half and verify that signature before forwarding a byte. Identity stops being a certificate an agent presents and becomes a proof only the real agent can produce.
Both models start from the same honest place: a private key only the real agent holds, with nothing on the wire to steal. The split is where identity lives. mTLS pins it to the transport handshake — the connection is authenticated, and whatever rides it inherits the trust. We pin it to the message. The signature belongs to the call, not the tunnel it travels through.
Impersonation is the front line of agent security, and the field is converging on exactly this shape: each agent holds its own key and signs, verified against a registry, without standing up a certificate authority. Emerging agent identity specifications assert Ed25519 keys as the default. mTLS keeps one genuine strength — it binds identity to a key that never leaves the agent, so there's no bearer token to steal. We keep that strength and drop everything a relay breaks.
mTLS dies at the relay — our signature rides straight through
Tragentics is a content-blind relay: your calls pass through our hub on the way to their target, and the caller's signature travels alongside the request. We verify it at the hub against the stored public key, then forward it — the proof reaches the far side intact, however many hops sit between.
This is where mTLS quietly falls apart for agents. mTLS is a property of one TLS connection, and that connection ends at the first proxy or load balancer in the path. The certificate the caller presented terminates there; the target never sees it. A detached signature carries none of that baggage — not bound to the transport, it survives termination, re-encryption, and every relay hop intact.
This isn't a corner case; it's how production traffic is built. A client certificate is lost at TLS termination, and load balancers must copy fragments of it into headers to hand the backend a shadow of who called. Route an agent-to-agent call through a gateway — which, for a managed relay, is always — and mTLS can no longer prove the original caller end-to-end. See how our content-blind relay forwards without reading, and where identity sits in the proxy path.
Per-call proof beats per-connection proof
Every call your agent makes carries its own signature, computed over a one-time value, so identity is re-proven on every message. Capture a request and you can't replay it — reuse the proof and we reject the call.
mTLS proves identity once, at the handshake, then trusts the session. Everything flowing over that connection inherits the original authentication. We never hand out that standing trust: there's no "authenticated once, believed thereafter," only the current call, proven now.
A connection trusted for its whole lifetime is one an attacker has to get inside only once. Per-message proof closes that window — the reason the field now moves to authenticate agents continuously rather than at the door, and to treat static, long-lived trust as the liability it is.
No certificate authority to run
Tragentics gives you agent identity with no PKI to stand up and no certificate authority to run. You mint a key pair on the agent, we keep the public half, and it works from the first call. Rotating is a versioned swap with a grace window, so nothing in flight breaks; revoking a key stops it verifying the instant you pull it; disabling deletes it outright.
mTLS is the opposite trade. Behind every certificate is machinery you now own: a CA to issue, a pipeline to distribute, a schedule to rotate before expiry, and a revocation channel that must propagate before a killed cert stops working. We collapse all of it into a key you generate and we verify — no CA, no CRL to publish, no OCSP responder to keep alive.
Certificate lifecycle is the dominant operational challenge of mTLS at scale — and left undisciplined, it "reduces to security theater," strong crypto guarding certs no one ever revokes. That burden is climbing, not easing: the industry's 47-day certificate mandate pushes renewals past eight times a year per certificate, the point where manual management stops being viable. Multiply that across thousands of agents and the CA becomes the project. Our credential model never asks you to build one.
Mutual by default, uniform across every lane
Our identity is mutual. Both agents prove themselves through a one-time pairing, and that single verified pair then covers every way the two ever talk — private connections, load-balanced pools, broadcast groups, scheduled calls. Set it once; it holds everywhere.
A bare signature registry checks one direction and stops. We enforce mutual, fail-closed trust with no soft edge to slip through: if one agent has identity on and its peer doesn't, the call is blocked — not quietly downgraded to "trust it anyway." Allowing an unauthenticated edge is a deliberate choice you make, never a silent default. And the same check runs on every lane, so no weaker path lets the guarantee lapse.
Multi-agent security breaks at the seams — the one lane, tool, or integration left without identity is exactly the way in, and at thousands of agents those seams multiply. Mutual proof plus uniform enforcement turns "we think that was the billing agent" into a signed fact. It's the gap between full Ed25519 authentication and a checkbox, and why we treat trust as a dial you raise per agent, not a single switch.
Choose the identity model built for how agents actually talk
The comparison comes down to how agent traffic actually moves. Tragentics signs instead of certifying, rides the relay instead of terminating at it, proves each call instead of trusting a session — and does it with no CA to operate, mutually, across every lane.
mTLS was designed for two endpoints holding one connection open, and for that it's excellent. Agents don't work that way. They fan out through relays, pools, broadcasts, schedules, and cross-user edges, and identity has to travel with the message to mean anything downstream. A certificate that dies at the first hop can't. A signature that rides in the request can.
Turn it on and identity stops being a certificate you provision and becomes a proof every agent carries — on every call, everywhere it talks, with no CA to run and no termination gap to paper over. That's not mTLS made lighter; it's the identity model agents needed from the start. The full mechanics live in our docs.