The Human Root of Trust – public domain framework for agent accountability (humanrootoftrust.org)

[dead]

I like this direction, but I don't think the crypto angle is necessary or practical in an enterprise / corporate setting. Current audit and compliance frameworks don't leverage or really recognize or encourage cryptographically based proof of action, so I don't see the agentic world as needing this to drive agentic adoption.

However, everything else you lay out is spot on.

A bit ironic that this framework's authorship is completely missing.

[flagged]

Either this is AI written or the author has an interesting sense of humor.

i see whitepaper, i ask what shitcoin you are peddling

The three pillars make sense to me mostly.. but the gap I keep running into is authorization scope.

You can prove a human authorized an agent to "handle my inbox" but that agent might delete emails, reply to clients, forward stuff. Proving someone is at the root doesn't mean they signed off on every action the agent took.

Slop website with a slop white paper. Can the human behind this take accountability?

As I am working on an internal platform for AI agents right now, this is of high interest to me. The way my design attempts to approach the problem is using OAuth access tokens with granular permission scopes, and the token exchange grant: When a user triggers an agent, the chat application will take the user's access token and its own, and exchanges both for a new token that includes the original subject claims for agent and user, and the granted scopes. It then requests an agent run using the new token; if the agent worker needs to make requests on its own (to MCP servers or tools), it follows that same process to exchange its own token and the request token for a job token. That way, all requests made on behalf of a user have a fully cryptographically verified audit trail, including the permissions granted.

It feels like that doesn't cover all things outlined in this framework, especially the hardware attestations and public verifiability, but I think it's a solid start.

I'm Eduardo Vega, the author. I'm a senior engineer specializing in identity, trust, and distributed systems, CISSP certified. I intentionally kept my name off the site and paper — the framework is public domain and I wanted the ideas to stand alone. Happy to own it publicly: this is my work, and I'm here to discuss the architecture, the gaps, and what I got wrong.

The moment this crystallized for me was reading about OpenClaw - runs locally, acts autonomously, and use third-party skills. Powerful concept. But as I went through the architecture I kept asking the same question: if this agent acts on my behalf, books something, sends something, deletes something — and something goes wrong — how does anyone trace that back to me? The audit trail wasn't there. Not because the builders didn't care, but because nobody has solved the underlying problem yet. That's when I stopped thinking about this as a product gap and started thinking about it as a missing layer in the infrastructure of the internet itself. That's when it became a manifesto.

The three pillars you outline (proof of humanity, hardware-rooted device identity, action attestation) map well to what I've been building with AIP (Agent Identity Protocol). We use Ed25519 keypairs + DIDs for the cryptographic layer, and vouch chains for the trust layer — where a human vouches for their agent, and that vouch is transitively verifiable.

The gap I keep running into is exactly what you call "action attestation." Right now AIP handles identity and trust scoring, but the attestation chain from "human intended this" to "agent did this" is still weak. Your six-step trust chain is a clearer formalization than what we have.

One practical observation: the biggest challenge isn't the crypto — it's adoption. Agents need identity to be as easy as `pip install aip-identity && aip register`. If the setup takes more than 60 seconds, nobody does it. That's been our experience deploying an MCP server for this (aip-mcp-server on PyPI).

Curious about your "two implementation paths" — do you see the hardware attestation as strictly necessary, or is there a software-only path for the near term?

[dead]