// HONEST COMPARISON
What Fidacy is not.
Most of what you could use instead of Fidacy is good, and necessary. The point of this page isn't to say the alternatives are wrong. It's to show, honestly, where each one is the right call, and the one thing none of them give you: a neutral, signed verdict the other sidecan verify without trusting you. We'll tell you when not to use Fidacy too.
vs. Content guardrails
Hallucination, prompt injection, PII, toxicity. They govern content, and they prove things to you. Galileo, Lakera, Guardrails AI: good at exactly this.
A neutral, signed record of identity and authorization of the action, the other side can verify without trusting you. They stack; they don't compete.
If your problem is the agent sayingsomething wrong, a hallucinated policy, a prompt injection, a PII leak, toxic output, you need a content guardrail, and Fidacy won't do that job. Galileo, Lakera, Guardrails AI and others are built for exactly this, and they're good at it. Use them.
Guardrails prove things to you. They don't issue a neutral, signed record the other side (a merchant, an auditor, a regulator) can verify without trusting you. And they govern content, not identity and authorization of the action. When the question is “who was this agent, whose was it, and was the action inside its mandate,” that's a different layer.
Run both. Guardrails for content. Fidacy for signed provenance and mandate. They stack; they don't compete.
vs. Building it in-house
You wrote it, control it, could edit it. Legitimate for your own visibility. It can't convince anyone else.
A neutral, signed verdict anyone verifies against public keys. The part one company can't build for itself.
If you only ever need to prove things to yourself, internal debugging, your own ops dashboards, one team's visibility, an internal log or proxy is cheaper and fully under your control. Brex built exactly this (CrabTrap) for their own use, and open-sourced the audit piece. For a single company's internal needs, in-house is legitimate.
The moment the proof has to convince someone else, a counterparty who has no reason to trust your log because you wrote it, control it, and could edit it, an internal tool structurally can't help. On YC's podcast, Brex's own CEO said they'd rather use a better externalversion than be in the plumbing business. A verdict only counts to the other side if it's neutral and externally verifiable. That's the part one company can't build for itself.
Build in-house for your own visibility. Use Fidacy for the proof the other side accepts. (And our @fidacy/crabtrap adapter (published, Apache-2.0) lets an existing CrabTrap setup emit a signed Fidacy verdict, start where you are.)
vs. OAuth 2 token-exchange
Identity propagated within a trust boundary the parties already share. Solid intra-flow federated trust.
A neutral, signed verdict a third party that doesn't federate with you can verify on its own. Trust between, not inside.
For propagating a user's identity inside your own agentic flow, or between two organizations that already federate, OAuth 2 + OIDC token-exchange is the right, standard tool. Narrow the scope and audience at each hop, as IBM describes, and you get solid intra-flow federated trust. If both sides already share an identity provider, use it.
Token-exchange proves the user authenticated and limits scope withina trust boundary the parties already share. It doesn't produce a neutral, signed verdict a third party who doesn't federate with you(a merchant, a rail, a regulator) can verify on its own. Agentic commerce is exactly that case: an agent buying from a merchant that has never seen your IDP. Fidacy is inter-organizational trust between parties that don't federate; OAuth is intra-flow trust between parties that do.
OAuth for federated, intra-flow identity. Fidacy for neutral, externally verifiable proof across parties that don't share an IDP. Different layers; they coexist.
vs. Proof-of-human
If your question is “is there a unique human behind this,” proof-of-human (World ID and similar) is the answer, and it's a genuinely hard, capital-intensive problem they're years ahead on. We will not do biometrics, and you shouldn't expect us to.
Proof-of-human proves a unique humanexists. It doesn't prove which agent that human authorized, for which action, with a signed verdict a merchant can verify. In the chain human → agent → action, proof-of-human secures the first link; Fidacy secures the agent and the mandate. They're complementary layers, not substitutes.
Proof-of-human for “is it a real, unique person.” Fidacy for “whose agent is this and is the action authorized.” Best together.
The one thing none of them give you.
Content guardrails, in-house logs, OAuth, proof-of-human, each is the right tool for its job, and several of them belong in your stack alongside Fidacy. But none of them produces the one artifact that decides an agentic transaction with a party that doesn't trust you: a neutral, signed verdict on who the agent is, whose it is, and whether the action was authorized, verifiable by anyone, on any rail, in any jurisdiction, with no trust in us required. That artifact is the whole product. Run it yourself and check the signature.
And the verdict isn't only readable, it's binding. When the action is a payment, an ALLOW issues a short-lived grant the executor verifies before money moves, so a DENY means no grant and no money, the way a duplicate invoice or a redirected wire is stopped at the gate rather than after the fact. Every decision lands in a hash-chained audit whose head is anchored to Bitcoin, so no party, including Fidacy, can rewrite it. One install, npx -y @fidacy/mcp, ships both the signed verdict and that payment gate.
If your agents never act across a trust boundary, they only touch systems you fully control, and no external party ever has to accept your word, you may not need Fidacy yet. The day an outside party has to trust what your agent did, you will.