What Is OpenAIIS? The Beginner's Guide to the Decentralized Trust Protocol for AI Agents
CodexFuse Team · 2026-11-05T03:31:05.167Z · 11 min read min read
What Is OpenAIIS? The Beginner's Guide to the Decentralized Trust Protocol for AI Agents
What Is OpenAIIS?
OpenAIIS is the Open Artificial Intelligence Integrity Sentinel, a decentralized trust, governance, and safety protocol proposed for the digital activity of people, organizations, and autonomous AI agents. In short, this is what the OpenAIIS decentralized trust protocol is for: answering who made a claim, who authorized it, and whether it can still be trusted. Published as the IETF Internet-Draft draft-sethi-openaiis-protocol-00 on 30 October 2026 by author Tarun Sethi, it proposes that actors issue typed signed claims about exact subjects — delegations, consent, evidence, and lifecycle events — and that those claims enter an ordered, Merkle-linked history whose checkpoints are anchored to the Bitcoin blockchain. In the draft's own words, OpenAIIS "specifies a decentralized trust, governance, and safety protocol for digital activity performed by people, organizations, and autonomous AI agents."
One caution before anything else: OpenAIIS is an individual Internet-Draft with an intended status of Standards Track, set to expire on 3 May 2027. It is a work in progress, not an adopted standard — the IETF's own boilerplate says it is inappropriate to cite Internet-Drafts as anything other than work in progress. That single fact frames everything below: this is a proposal to study, not a standard to rely on yet.
Why Does OpenAIIS Exist? The Problem It Solves
OpenAIIS exists because autonomous software can now create artifacts, publish code, invoke services, and start actions across organizational boundaries — and today's tooling cannot answer the questions that matter afterward. The draft puts the gap plainly: "After an action, a signature may identify the software key that produced it without identifying the organization that authorized it, the human or institution that accepted responsibility, the evidence supporting its execution, or the conditions under which its authority was withdrawn." A signature tells you which key signed; it tells you nothing about who stood behind the action.
The project's site, openaiis.com, compresses the same problem into a motto: "A valid signature is not permission." Today's tools can tell you a key signed something — they cannot tell you whether that key was allowed to, or whether it was stolen an hour earlier. If you run agents on hardware you control — for example on VPS hosting you administer yourself — every agent you deploy inherits exactly this trust question: who authorized this action, and can I still trust it?
The scope is wider than agents alone. The same site notes that AI is the reason OpenAIIS exists, but the same questions apply to every digital claim, whether a person, a company, a program, or an agent made it. Software releases, media integrity, and identity credentials are all named as use cases on the project's homepage.
Is OpenAIIS an OpenAI Product? And What About the Open Agent Protocol?
No. OpenAIIS is not affiliated with OpenAI the company — it is an independent project authored by Tarun Sethi (OpenAIIS, Germany) and published as an individual IETF Internet-Draft, whose record names no OpenAI involvement. The name is a trap worth disarming once, because the confusion is the first thing every beginner hits when they search the term.
The Open Agent Protocol (OAP, openagentprotocol.eu) is also a different protocol, not a rival product with a similar name. It describes itself as a vendor-neutral specification for verifiable identity, discovery, invocation, governance, and accountability between autonomous AI agents and the tools they use, organized around seven planes. OpenAIIS, by contrast, is a signed-claim registry with Bitcoin-anchored trust evidence. Two different projects, two different designs — and to put the OpenAIIS vs Open Agent Protocol distinction in one sentence: OAP standardizes how agents talk to tools; OpenAIIS standardizes the signed evidence those actions leave behind. Distinguished here once so they are never conflated.
OpenAIIS Protocol Explained: The Five Properties
OpenAIIS combines five protocol properties into one design: provenance, authenticated history, governance, safety, and independent verification. The draft defines each precisely; the table below gives the draft's wording and what each property means in plain terms.
| Property | What it means | The draft's wording |
|---|---|---|
| Provenance | Every claim is signed by an issuer and bound to the exact subject and content it describes. | "an issuer signs a canonical statement about an exact subject and cryptographic content commitment" |
| Authenticated history | Admitted records form an ordered log; its signed checkpoints are committed to Bitcoin. | "an ordered Merkle log binds admitted records to signed checkpoints whose bytes are committed to Bitcoin mainnet" |
| Governance | Consent, scoped delegation, responsibility, and lifecycle changes are all signed relationships. | "explicit signed relationships establish consent, scoped delegation, responsibility, and controlled lifecycle changes" |
| Safety | Revocation, compromise, and dispute records feed into later trust decisions. | "authenticated compromise, revocation, dispute, and related evidence can affect subsequent trust decisions" |
| Independent verification | Anyone with the proofs and the declared trust inputs can reproduce the evidence and the policy outcome. | "portable cryptographic proofs and declared trust inputs permit distinct implementations to reproduce supported evidence and policy outcomes" |
What Is a Typed Signed Claim in OpenAIIS?
A typed signed claim is the atomic unit of OpenAIIS: OpenAIIS typed signed claims are canonical JSON records with exactly fourteen fields — profile, record type, subject id, issuer id, issuer key id, content hash, payload schema, payload hash, authority refs, evidence refs, consent refs, related-record refs, claimed-at time, and signature — sealed with a canonical, domain-separated Ed25519 signature. Each claim is "typed" so a verifier knows exactly what kind of statement it is evaluating, and "canonical" so every implementation signs the same bytes. The draft leans on established cryptography throughout, citing Ed25519 (RFC 8032), Certificate Transparency-style Merkle trees (RFC 9162), and OpenTimestamps for the Bitcoin link.
The content commitment is a SHA-256 hash of the exact payload, so a verifier can confirm the bytes it received match what the issuer signed. To see what that fingerprinting looks like in practice, try a SHA-256 hash generator: it produces the same kind of 256-bit digest an OpenAIIS claim carries as its content commitment.
Claims are not limited to "who did what." They can cover delegations, consent, evidence, and lifecycle events — including compromise and revocation records — so trust inputs can change as the facts change, and verifiers can act on the change.
How Is OpenAIIS Bitcoin Anchored?
OpenAIIS anchors its history to Bitcoin by committing signed registry checkpoints — not individual claims — to Bitcoin mainnet through OpenTimestamps. Each checkpoint note is exactly three ASCII lines: the registry origin, the decimal tree size, and the canonical base64 of the 32-byte Merkle root, signed with Ed25519 by the registry operator using a key distinct from the claim issuer's key. An OpenTimestamps commitment then carries that digest into a Bitcoin block attestation, and aggregation can bind many checkpoints to a single Bitcoin transaction, so the chain never needs to hold every claim or artifact.
The resulting evidence ladder is explicit in the draft. A record moves through CHECKPOINT_SIGNED, STAMPED_PENDING_BITCOIN, BITCOIN_ATTESTED, and finally BITCOIN_CONFIRMED, with the core policy requiring a minimum of six Bitcoin mainnet confirmations. The draft's assurance classes climb from PUBLIC_SOURCE through PINNED_ANCHOR and PINNED_CONFIRMING_CHAIN up to VALIDATING_NODE, giving verifiers a shared vocabulary for how strongly anchored a record is.
The project's own site reports a first anchor: it says that on 25 October 2026 a signed OpenAIIS registry checkpoint was confirmed on the Bitcoin blockchain, citing Bitcoin block 973,103 with six confirming blocks checked. That is vendor-claimed — no independent confirmation of that block claim was found in this run, so treat it as the project's own report, not an established fact.
Two cautions the draft states itself. First, Bitcoin anchoring protects historical evidence against retroactive substitution or rewriting, but "Neither layer by itself determines the truth of a claim or the authority of its signer" — anchoring proves the history, not the truth. Second, "Registration success is not a Bitcoin-confirmation verdict": being admitted to the registry is not the same as being confirmed on Bitcoin, and verifiers must not confuse the two.
Declare, Record, Decide: How OpenAIIS Is Used
The project's site distills the workflow into three steps — Declare, Record, Decide — built around the principle that "OpenAIIS keeps what was claimed separate from whether it is allowed, so trust can change when the facts do."
- Declare. The agent, the company that runs it, and the people responsible each sign what they stand behind: who operates it, who accepts responsibility, and what it may do.
- Record. Every signed claim joins an append-only history that anyone can audit and no one can quietly rewrite; checkpoints can be anchored to Bitcoin.
- Decide. When the agent acts, any service checks the full chain against its own policy and gets a clear answer: allow, deny, or send for review.
When something goes wrong, the site says "the company publishes one signed revocation. Every service that checks the shared history can refuse what the stolen key signs next" — revocation that travels with the record. And one line sets the protocol's scope precisely: "OpenAIIS never tells anyone whom to trust. Each service applies its own trusted keys and its own rules." The protocol supplies evidence; each verifier supplies the verdict.
How Does OpenAIIS Compare to AER-1, Mitra, and TRAIL?
OpenAIIS sits beside — never against — the other agent-trust proposals being drafted in parallel. Each answers a different question. AER-1 proposes verifiable execution receipts for AI agent tool calls; the Mitra protocol proposes a signed envelope that carries claims with token budgets; the TRAIL protocol proposes cross-organizational audit trails with live revocation. OpenAIIS's question is trust evidence: who issued the claim, under what authority, and can its history still be trusted?
| Lane | What it records | What it is for |
|---|---|---|
| OpenAIIS | Typed signed claims plus a Bitcoin-anchored Merkle history | Trust, governance, and safety evidence for agent actions |
| AER-1 | Execution receipts for agent tool calls | Post-hoc proof that a call happened and what it returned |
| Mitra | Signed envelopes carrying claims with token budgets | Transporting agent messages with spend limits |
| TRAIL | Cross-organizational audit trails with live revocation | Auditability and revocability across organizations |
A final privacy note from the vendor's site: only fingerprints of content are recorded — "The files themselves stay with you" — so private payloads stay private while their signed commitments remain verifiable.
Is OpenAIIS a Cryptocurrency? No Protocol-Native Currency
OpenAIIS is not a coin or token project, and it is important to say that once: the draft explicitly says it "supports versioned decentralized consensus profiles without a protocol-native currency." Bitcoin appears only as external proof-of-work for historical commitments, never as payment and never as the project's own asset — no copy about OpenAIIS should imply a token.
Status check as of 5 November 2026: the project's site labels itself an "Open protocol, now in preview," and its homepage lists no pricing, no SDK, and no user numbers, so this guide claims none. Only one consensus profile is fully specified in the draft — openaiis-universal-registry-v1; the architecture admits more, but none are published yet. No CodexFuse OpenAIIS tool exists or is promised here.
Sources
IETF Internet-Draft draft-sethi-openaiis-protocol-00, "OpenAIIS — A Decentralized Trust, Governance and Safety Protocol for the Digital World," Tarun Sethi (OpenAIIS, Germany), 30 October 2026, expires 3 May 2027 — https://datatracker.ietf.org/doc/html/draft-sethi-openaiis-protocol-00. The datatracker's BibTeX record confirms 33 pages and intended Standards Track status.
openaiis.com — the project's homepage ("Open protocol, now in preview"; "Every AI action, traced to someone accountable."), fetched 2026-11-05.
Open Agent Protocol (openagentprotocol.eu) — "An open standard for AI agent communication," fetched 2026-11-05.
Frequently Asked Questions
Is OpenAIIS an OpenAI product?
No. OpenAIIS is an independent project by Tarun Sethi, published as an individual IETF Internet-Draft; the IETF record names no OpenAI involvement. The name is the trap — the two are unrelated.
Is OpenAIIS a finished standard?
No. It is an individual Internet-Draft with an intended status of Standards Track, dated 30 October 2026 and expiring 3 May 2027. IETF drafts are work in progress and may be updated, replaced, or abandoned at any time.
Is OpenAIIS a cryptocurrency or a token project?
No. The draft explicitly says it supports versioned decentralized consensus profiles without a protocol-native currency. Bitcoin is used only as external proof-of-work for anchoring history, not as payment or as the project's own asset.
How is OpenAIIS different from the Open Agent Protocol?
The Open Agent Protocol (OAP) is a vendor-neutral communication and coordination standard for agents and tools, organized around seven planes. OpenAIIS is a signed-claim registry with Bitcoin-anchored trust evidence. They are different projects answering different questions.
What does Bitcoin anchoring actually prove?
That a checkpoint existed at a point in Bitcoin's history and that the recorded state cannot be quietly rewritten without redoing Bitcoin's proof-of-work. It does not prove a claim is true or that its signer had authority — the draft states that explicitly.
