Tensflare is now a Contributor Member of C2PA, the Coalition for Content Provenance and Authenticity. C2PA is the open standard for content provenance hosted by the Joint Development Foundation. Its Steering Committee includes Adobe, Amazon, the BBC, Google, Meta, Microsoft, OpenAI, and Sony. That's the announcement. The rest of this post is about why it matters to us, and why we think it should matter more broadly than it currently does.
Trust used to be local
For most of human history, trust was a local problem with local solutions. You trusted a document because you recognized the seal, or the hand that wrote it, or the person who witnessed it being signed. You trusted a claim because it came from someone whose reputation was on the line if it turned out to be false, and whose face you could find if it did. Trust didn't need to be verified from first principles, because it was embedded in relationships that were themselves verifiable. You could visit a notary, appeal to a guild, or take a dispute to a court in the same town.
The last few centuries have been a slow, uneven project of decoupling trust from proximity. Currency, double-entry bookkeeping, the joint-stock company, the notarial system, the modern signature, public-key cryptography. Each is, in its own way, a technology for trusting a stranger at a distance, without requiring the relationship that trust used to depend on. Common law agency doctrine, the body of law that governs when a principal is bound by what an agent does on their behalf, is one of the oldest and most thoroughly tested pieces of this machinery. It exists because delegation is powerful and dangerous in exactly the same measure. The more you can act through someone else, the more you need a reliable way to know who is accountable when that someone else gets it wrong.
We think AI has quietly reopened this very old problem, at a scale and speed nothing before it has managed.
The two questions AI forces us to ask again
When a model generates an image, or a document, or a paragraph of legal analysis, the old question resurfaces immediately: where did this actually come from, and can I trust that it hasn't been altered or fabricated since? That is C2PA's question, and it's not a new one. It's the same question a wax seal answered for a medieval letter, asked now of a JPEG or a PDF, at a volume and velocity no seal was ever built for.
But AI raises a second question that content provenance alone doesn't answer. The reason is that increasingly, AI doesn't just produce content. It acts. It files documents. It flags risk in a contract. It delegates a sub-task to another agent, which delegates to another, across organizational and jurisdictional lines a human decision-maker might never have crossed so quickly or so invisibly. When something in that chain goes wrong (a citation that doesn't exist, a filing that shouldn't have been made, an authorization that was never actually granted) the old agency-law question resurfaces too: who authorized this, within what limits, and can that be proven to someone who wasn't in the room?
That second question is the one we've spent the last stretch of Tensflare's life building an answer to. We call it TAP, which stands for the Tensflare Accountability Protocol. It's a formal, cryptographically verifiable way of encoding what an AI agent was authorized to do, recording what it actually did, and tracing how that authority moved from a human principal, through however many agents, to the action that finally touched the world. It borrows its structural logic from three centuries of agency law and its cryptographic logic, in no small part, from C2PA.
Provenance and accountability are the same problem wearing different clothes
We didn't build TAP by inventing a new philosophy of trust. We built it by noticing that C2PA had already worked out the hard part: how do you bind a verifiable claim to an artifact, in a way that survives the artifact moving through systems you don't control? We asked ourselves what it would take to bind that same kind of claim to an action instead of a piece of content.
The technical overlap turns out to be almost exact. C2PA uses hard bindings, or cryptographic hashes, to tie an authenticity claim to the bytes of an image or a document, and soft bindings, or fingerprints, for content that can't be pinned down to an exact byte sequence. TAP does the same thing for an agent's inputs and outputs, for exactly the same reason. A claim that can't survive scrutiny isn't a claim. It's a hope. And TAP inherits something less technical from C2PA, too, which we think matters more than any hash function: the discipline of staying descriptive rather than evaluative. C2PA's own guiding principles hold that a specification should establish whether a piece of provenance data is authentic and untampered with. It should not judge whether the underlying content is good, true, or wise. We built TAP the same way. It can tell you, with cryptographic certainty, that an action was or wasn't within the scope of its authorizing mandate. It has nothing to say about whether the action itself was the right one. That distinction is a form of humility we think matters. A protocol that tried to also be the judge of right and wrong would be making a much larger claim than the one we are actually equipped to defend.
The part we had to prove, not just build
There's a difference between a protocol that seems like it should preserve accountability and one that provably does, and we didn't want to be satisfied with the first kind.
Recent formal work on human-agent collectives had identified something we needed to take seriously before going further: an Accountability Horizon, a computable threshold above which no single point can hold accountability while satisfying a minimal set of axioms at once. That result concerns collectives, meaning multiple agents acting jointly in interaction structures that loop back on themselves. It's a real impossibility result, not a design limitation someone forgot to solve. If it applied to what TAP was trying to do, TAP would be building on ground that couldn't hold the weight.
It doesn't apply, and showing why turned into its own piece of work: Accountability Chains: A Formal Specification for AI Agent Delegation. The sequential delegation chain, where a human principal delegates to an agent which sub-delegates to another in a directed, non-looping sequence before any real-world action occurs, is a structurally different and practically far more common architecture than the collectives the impossibility result addresses. In that narrower setting, we show a formal specification for chain accountability isn't just possible. It's achievable, by importing three centuries of common law agency doctrine directly into the delegation-chain setting: Mandate Boundedness, Authority Narrowing, Scope Monotonicity, Forensic Reconstructibility, and Firebreak Completeness. Two results follow from those five invariants. The Mandate Monotonicity Proposition states that authority can only narrow as it moves down a chain and never widen. The Accountability Firebreak Theorem describes the conditions under which a failure can always be traced back to a specific, accountable point in the chain.
TAP isn't a separate thing from that paper. It's the constructive existence witness for it: the demonstration that a working protocol can actually satisfy all five invariants, not just describe them on paper. That's the order we did things in, and we think it's the right order. Prove the thing is possible before you build the thing that claims to do it.
Why this couldn't stay a solo project
There's a reason we didn't try to build TAP as a private standard that only Tensflare's products understood. A trust protocol that only one company can verify isn't really trust infrastructure. It's a vendor claim wearing infrastructure's clothing. The entire value of something like C2PA is that a claim made in one system can be checked by a completely unrelated party, using open, public rules, without having to take anyone's word for it. That property doesn't come for free. It has to be built in from the start, and it has to be maintained by more than one company with a financial interest in the outcome.
That's why TAP is Apache 2.0, and why we've committed to donating its governance to neutral standards infrastructure, the Linux Foundation or its equivalent, within 24 months of first publishing it. It's also, in a real sense, why we joined C2PA rather than simply citing it from a distance. If you're building something that depends structurally on another community's work, we think the honest thing to do is show up in the room where that work gets decided, not just reference it in a specification and move on.
What we actually think this is worth doing for
We work mostly in law, and increasingly in other domains where being wrong has real consequences: medicine, finance, regulatory compliance. These are domains that have always run on exactly the kind of trust infrastructure we're describing: signatures, chains of custody, notarization, the whole slow apparatus civilization built to let strangers rely on each other's claims. AI is being adopted into these domains faster than that apparatus is being rebuilt to account for it. We think that gap is the actual risk. The risk is not that AI will be used in law or medicine or finance, which seems inevitable and often genuinely useful. The risk is that it will be used there before anyone has rebuilt the machinery that lets a court, a regulator, or a patient trust what happened and who is accountable for it.
Closing that gap isn't a problem one company solves alone, and it was never going to be. It's a standards problem, which means it's a coalition problem, which is the entire reason organizations like C2PA and the Linux Foundation exist in the first place. Joining C2PA is a small, concrete step in that direction. It is not a departure from what we've been building. It is an admission of something that was already true: we've been standing on this standard's shoulders for a while now, and it seemed like time to say so properly, and to start contributing back.
The full TAP specification, reference implementation, and schemas are open for anyone to read, implement, or take apart: truss.tensflare.com/resources/tap-spec.
If you're working on content provenance, AI accountability, or the widening seam between those two problems, we'd like to hear from you.