← Back to Proof of Origin

How It Works

Five steps from birth to proof. Every AI output gets a verifiable origin — who authorized the agent, what model answered, when it happened.

1
The Agent Is Born

Every agent starts with a birth certificate — a permanent record naming two parents: the AI that gives it capability, and the key holder who gives it authority.

Birth Certificate
  Agent: 0xB29A...ffaA6
  AI Parent: Morpheus / Kimi K2.5 / api.mor.org
  Authorizer: Steven Sprague / 0xCf31...3fDa
  Policy: 100 MOR/day, scope: enterprise-demo
  Key Protection: TPM-sealed (hardware-bound)

The birth certificate is cryptographically signed and written to the blockchain. It can't be altered, forged, or denied. Anyone can verify it.

Why This Matters

Enterprises

Every AI agent in your organization gets a corporate badge. Unsanctioned agents have no birth certificate — shadow AI becomes detectable by absence.

Decentralized AI

Morpheus agents get verifiable identity. Not just an API key — a birth certificate naming the specific model, provider, and authorization.

Self-Hosted AI

Running Llama or Mistral locally? The birth certificate proves YOUR model produced the output. Your hardware, your keys, your proof.

2
Every Action Is Recorded

When the agent answers a question, every inference call is recorded as a signed, hash-linked entry. The prompt is hashed. The response is hashed. Both are chained to the previous action.

Action Note
  Prompt Hash: 0x8d11...13da (SHA-256 of question)
  Response Hash: 0x1828...845e (SHA-256 of answer)
  Previous Hash: links to birth certificate
  Model: kimi-k2.5 | Tokens: 2,137 | Latency: 21s
  Channel: Layer 1 (agent-side signing)

The content is never stored in the chain — only the hashes. The full conversation is encrypted and archived separately. The hashes prove integrity without exposing sensitive content.

Why Hashing Matters

SHA-256 has a search space of 2256. Finding two different prompts with the same hash would take longer than the life of the universe. If the hash matches, the content matches. No trust required — just math.

Healthcare example: A patient asks an AI about chest pain. The AI recommends going to the ER. Six months later, the insurance company disputes the visit. The patient has the hash of exactly what the AI said, when, and which model answered. The proof is patient-owned, not platform-owned.
3
The Chain Grows

Each action links to the previous one. The second response can't be moved before the first. Alter any entry and the chain breaks. Same math as Bitcoin — applied to AI conversations.

Note 0: Birth Certificate
  ↓ hash-linked
Note 1: STEMI Diagnosis — 2,137 tokens
  Prompt: "Patient presents with chest pain..."
  Response: "Acute Inferior STEMI..."
  ↓ hash-linked
Note 2: Risk Stratification — 2,899 tokens
  Prompt: "What are the key risk factors..."
  Response: "GRACE score, Killip class..."
  ↓ hash-linked
Tamper-evident: change any Note and every link after it breaks

Why Ordering Matters

AI agents don't make decisions in one shot. They reason across turns. A doctor asks a follow-up. A financial analyst refines a model. A lawyer challenges a conclusion.

Without proof of origin, each turn is independent — you can't prove the AI's second answer was informed by its first. With the hash chain, the sequence is proven. An auditor walks the chain and verifies every step.

4
One Hash Proves Everything

At the end of a session, a Merkle root is computed — a single hash that covers every action in the chain. One verification proves the entire session.

Settlement
  Merkle Root: 0x7e1e854fcf3bacdfb1b860c656fe2f0b631b2c17...
  Actions: 2 inference calls
  Total Tokens: 5,036
  Models Used: kimi-k2.5
  Errors: 0

Change any bit in any Note → the Merkle root changes.
One hash. One verification. Complete session integrity.

The Lightning Chain Model

We don't write every action to blockchain individually. That would be expensive and slow. Instead, actions accumulate in memory during the session (free, fast). At settlement, one blockchain write covers everything.

During the Session

Actions recorded in memory. Hash-linked. Signed. No blockchain cost. No latency.

At Settlement

One Merkle root. One blockchain write. Full session proven. Cost: less than a penny.

For Auditors

Verify one hash. If it matches, every Note underneath is proven intact. No need to read 10,000 transactions.

5
The Proof Goes On-Chain

The settlement is written to the agent's Sovereign Secret on the Polygon blockchain. The full conversation is encrypted and archived to IPFS. The agent's entire history — every session, every action — accumulates at one address.

Sovereign Secret: 0x70b893e3...056a2d5c (Polygon Mainnet)

  Note 0: Birth Certificate (March 28)
  Note 1: Session 1 — Decentralized AI research (March 28)
  Note 2: Session 3 — GTM strategy (March 30)
  Note 3: Session 4 — Skills architecture (March 31)
  Note 4: Session 5 — TEE demo (April 1)
  Note 5: Session 6 — Healthcare demo (April 1) ← just written

One address. Six sessions. All encrypted. All verifiable.

The agent IS the wallet. Its identity is the address. Its memory is the Notes. Its history is the chain. Anyone with the share link can read it. Anyone without it sees only encrypted data.

What this enables: The agent can be recovered from one address. New hardware reads the Sovereign Secret from the blockchain, loads the latest checkpoint, and resumes. Same identity. Same history. Different machine.
&shield;
The Policy Layer

Every action the agent takes passes through a policy engine inside a Trusted Execution Environment (TEE). The policy is set by the owner. The TEE enforces it. The agent can't bypass it — not through prompt injection, not through jailbreaking, not through any software trick. The enforcement is in the container, not in the prompt.

graph LR
    subgraph Request["AI Agent Request"]
        Action["Sign transaction
Call inference
Write data"] end subgraph TEE["Trusted Execution Environment"] Policy["Policy Engine
ALLOW / DENY / AUTO"] Chain["Internal Chain
Every decision recorded"] end subgraph Signing["Hardware Signing"] TPM["Desktop TPM
Hardware-sealed key"] end subgraph Result["Outcome"] Allow["Action executed
Recorded in chain"] Deny["Action blocked
Denial recorded"] end Action --> Policy Policy -->|ALLOW| Chain Policy -->|DENY| Deny Chain --> TPM TPM --> Allow style Request fill:#e0e7ff,stroke:#4f46e5,color:#1e1b4b style TEE fill:#f5f3ff,stroke:#6366f1,color:#1e1b4b style Signing fill:#d1fae5,stroke:#059669,color:#064e3b style Result fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f

What the Policy Controls

Spending Limits

Daily and weekly caps on value transferred. Per-transaction maximum. Auto-approve threshold for small operations.

Allowed Operations

Which contracts the agent can interact with. Which models it can call. Which skills it can load.

Skill Permissions

Each loaded skill declares what it can do. The TEE verifies the manifest and enforces the boundaries at runtime.

Denial Logging

Denied actions are recorded in the chain too. The audit trail includes what the agent tried to do and was prevented from doing.

The TEE: Container, Not Cage

graph TB
    Owner["Owner
Writes policy, can revoke"] PE["Policy Engine"] MC["Merkle Chain"] SL["Skill Loader"] Set["Settlement"] S1["Skill: morpheus-inference"] S2["Skill: payments"] S3["Skill: data-collection"] TPM["Desktop TPM / HSM"] Owner --> PE SL --> S1 SL --> S2 SL --> S3 S1 --> PE S1 --> MC PE --> TPM MC --> Set style Owner fill:#d1fae5,stroke:#059669,color:#064e3b style PE fill:#e0e7ff,stroke:#4f46e5,color:#1e1b4b style MC fill:#e0e7ff,stroke:#4f46e5,color:#1e1b4b style SL fill:#e0e7ff,stroke:#4f46e5,color:#1e1b4b style Set fill:#e0e7ff,stroke:#4f46e5,color:#1e1b4b style S1 fill:#ede9fe,stroke:#7c3aed,color:#1e1b4b style S2 fill:#ede9fe,stroke:#7c3aed,color:#1e1b4b style S3 fill:#ede9fe,stroke:#7c3aed,color:#1e1b4b style TPM fill:#d1fae5,stroke:#059669,color:#064e3b

The owner writes the policy. The TEE enforces it. Skills execute within it. The signing key never leaves the hardware. The agent operates with authority but under control — like an employee with a corporate card and a spending limit.

Key distinction: Most AI safety approaches use prompts to tell the AI "be careful." That's quality control by asking the assembly line to behave. Our approach uses cryptographic enforcement — the policy is in the container, not in the conversation. The agent physically cannot exceed its limits.

Ready to Add Proof of Origin?

See it working. Read the code. Build on it. For partnerships and enterprise integration, reach out.