The Covenant of Humanistic Technologies is live. It defines a design philosophy for Human Tech: d/acc technologies that embed digital rights by design, built and governed on the human.tech protocol layer. Commit your alignment at manifest.human.tech

we think about this question more than any other: what would you build if you knew it couldn't be used against you?

verification and delegation look equivalent from the outside they're not • one answers: who is accountable for what this agent does? • the other: what is this agent authorized to do, right now? -> an agent with only the first: you know who owns it, but nothing constrains what it signs -> an agent with only the second: it's scoped, but there's no chain of human accountability building both is what makes an agent trustworthy, not just capable human.tech/blog/proof-of-per…

human.tech’s AI strategy is now publicly available link in the QT

every compliance framework ultimately asks for proof: show that the check happened, and show when Proof of Clean Hands generates exactly that: this address cleared the check, at this moment, without storing anything. the record is what regulators require; the underlying data they'd normally expect to see collected doesn't need to exist auditable without accumulation

Article 14 puts the operational compliance burden on the deployer, not the foundation model provider pointing at your AI vendor's certification isn't enough. in production, what matters is whether you can show: authorization records tied to specific human approvals, scope constraints that exist outside the model's reasoning, and an audit trail that holds up under regulatory review

query a wallet and you know whether it connects to a verified unique human; no user action, no re-verification step @HumnPassport Models API runs Sybil defense at the protocol, not the application

when agents share signing infrastructure, a single compromise has a multiplier effect how far it reaches depends on the key design, not the agent that got hit. in a full-key pool, a breach at the infrastructure level reaches every agent in it 2PC changes the math: the human signing party is a fixed boundary

the agent acts onchain the human keeps root control delegation ≠ full handover @elizaOS soon

when an agent executes onchain, two checks need to happen @HumnPassport answers: who backed this agent? is there a verified human behind it? @WaaPxyz answers: what is this agent authorized to sign? what's the scope? common goal -> keep humans in the loop human.tech/blog/proof-of-per…

organizations running identity verification for compliance face a structural choice: run the check and become a data custodian, or run the check without retaining anything most default to the first because the second path required infrastructure that wasn't available Human ID is that infrastructure: credentials generated by the user, organization queries the proof, not the data; no PII at rest, no retention obligation docs.holonym.id

verifying humanity through government-issued IDs used to mean uploading documents to a KYC provider (aka a honaypot) @HumnPassport proves it's possible to run privacy-preserving verification instead NFC Passport now suported, free for a one-time, 1-week proof. $3 for a reusable onchain version

you’re not updating your priors fast enough

right in line with Proof of Clean Hands >> zk-proofs >> AML & sanctions check >> that's what we built into the bridge to @aztecnetwork privacy and compliance can go hand in hand 🤝

everyone's trying to make their agents smarter, so do we our agents read structured truth instead of guessing at it. as a result, a non-engineer did 3 months of work in 3 days, and hallucinations became rare part of our thesis: make the company readable to agents through indexed docs, structured frontmatter, roadmaps, and a CRM that an agent can parse without drowning in context the full story of how we restructured human.​tech, by co-founder @NanakNihal: nanaknihal.com/2026/06/09/hu…

Article 14 specifies the standard, not the implementation. in practice, effective oversight means: • scoped permissions: the agent operates within pre-approved authority limits • human authorization on record: the approval predates the action • verifiable enforcement record: the boundary and its enforcement are auditable after the fact compliance is an architecture decision, not a policy document human.tech/blog/authorizatio…

wallets confirm the key. Passport confirms the human at agent scale, it's two different questions: who holds the key, and who authorized the action

for those who still don't know @WaaPxyz, or need a refresher stop renting your private keys

Article 14 of the EU AI Act doesn't ask enterprises to file a policy. it asks, in effect: can you demonstrate, after the fact, that a human could have intervened before the agent acted? for high-risk AI systems deploying LLM agents in production, that's an infrastructure question, not a compliance checkbox every agent transaction needs a verifiable record: what it was authorized to do, by whom, and within what scope. Article 14 creates the accountability requirement. the architecture that satisfies it is a records and authorization infrastructure problem "we have logs" doesn't satisfy this. traditional logs are mutable and can be selectively retained. a signed authorization chain isn't 56 days to August 2

207K verified humans in one campaign is proof human verification can scale the harder gap: agents running wallets with no verified human behind them at all verification at that scale was step one. agent authorization is the next one