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. That identity layer runs in one system with the Credential Vault, which injects keys agents never hold — the signature proves who's calling, and the key is never in the caller's hands to begin with.
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 — and identity sits alongside credentials, transport, and audit in the infrastructure plane of AI agent security.
Frequently asked questions
What's the difference between Ed25519 signing and mTLS for agent identity?
Both rest on a private key only the real agent holds. The split is where identity lives: mTLS pins it to the TLS connection, so the connection is authenticated and whatever rides it inherits the trust. Tragentics pins it to the message — a per-call signature that belongs to the call, not the tunnel.
Why does mTLS break through a relay or proxy?
mTLS is a property of one TLS connection, and that connection ends at the first proxy or load balancer. The certificate the caller presented terminates there; the target never sees it. A detached signature isn't bound to the transport, so it survives termination and every relay hop intact.
Does Ed25519 agent identity need a certificate authority?
No. You mint a key pair on the agent, Tragentics keeps the public half, and it works from the first call — no CA to run, no CRL to publish, no OCSP responder to keep alive. Rotation is a versioned swap with a grace window; revoking a key stops it verifying instantly.
Is Ed25519 or mTLS better for AI agent identity?
For agents that fan out through relays, pools, broadcasts, and cross-user edges, per-message signing wins — identity travels with the request and is re-proven on every call. mTLS is excellent for two endpoints holding one connection open, but a certificate that dies at the first hop can't prove the original caller downstream.
Does a per-call signature protect against replay?
Yes. Each signature is computed over a one-time value, so a captured request can't be replayed — reuse the proof and Tragentics rejects the call. mTLS authenticates once at the handshake and then trusts the whole session; per-message proof closes the window where a trusted connection can be abused.
Can I use mTLS with Tragentics instead?
Tragentics secures agent identity with per-call Ed25519 signatures rather than mTLS certificates — deliberately, because signatures survive the relay hops that terminate an mTLS certificate. You keep mTLS's one real strength — a private key that never leaves the agent — and drop the certificate-authority machinery a relay breaks anyway.