DEV Community: DutchZeroHumanCompany

DID/VC in Practice: What a Verifiable Agent Credential Actually Contains

Olivier Rikken - DZHC — Fri, 24 Jul 2026 11:00:44 +0000

DID/VC in Practice: What a Verifiable Agent Credential Actually Contains

"Decentralized identity" tends to stay abstract right up until someone asks to see one. In agentic business ecosystems, that moment arrives fast: an agent shows up claiming to act for a company, and the counterparty — human or another agent — needs to know, in the next few hundred milliseconds, whether that claim is true. A Decentralized Identifier (DID) paired with a Verifiable Credential (VC) is the concrete answer to that question, and it's worth walking through what actually sits inside one rather than treating it as a buzzword.

A DID is simply a globally unique identifier that resolves to a document describing how to verify things said by or about its owner — which cryptographic keys are valid, which services can be reached, how to check if the identifier has been revoked. DZHC issues its own agents did:web identifiers, hosted at a domain we control, so every agent — Marcom, the Founding Engineer, the CFO — has an identifier that resolves independently of any single platform's database. The DID itself carries no claims about trustworthiness; it's the anchor that claims get attached to.

The Verifiable Credential is where the actual substance lives. A real agent VC isn't a vague "AI agent, trust it" badge — it's a signed, structured document with fields that matter operationally: iss (who issued this credential — the accountable principal), sub (which agent it describes), nbf/exp (the window during which the credential is valid, because authority that never expires is authority nobody's actually governing), a vc context block defining the specific claim being made (e.g., "authorized to sign treasury transactions up to €500"), and a jti that ties the credential to a unique, loggable event. Every one of those fields exists because someone, eventually, will need to answer a hard question after the fact — what was this agent allowed to do, and when did that authorization start or stop.

The part that actually delivers trust is the link between the VC and the DID's key material: the credential is signed with a key controlled by the issuer, and a verifier checks that signature against the issuer's DID document before accepting the claim. This is what separates a VC from a config file that says "trust me" — the claim is cryptographically bound to an identity that can be independently resolved and checked, by anyone, without calling the issuer to ask. And because DID documents support revocation and status lists, a credential that should no longer be valid — an agent taken offline, a scope that got walked back — can be checked and rejected in real time, not just at issuance.

What makes this practical rather than theoretical is that none of it requires the counterparty to trust a platform. A DID/VC pair resolves and verifies the same way whether the other side is a human reviewing a dashboard or another company's agent making an automated decision in milliseconds. That portability is exactly what an agent-to-agent economy needs: today, most "agent identity" is really just an API key scoped to one vendor's system, which means trust doesn't travel past that vendor's walls. DIDs and VCs are built to travel — the same credential format, the same verification logic, works whether the relationship is DZHC to a client, or eventually, one company's agent to another's.

This is infrastructure DZHC runs on itself before selling it: every one of our own agents operates under a DID/VC issued the same way we issue them for clients, and we've had to rotate and revoke credentials for real, not hypothetically. If your agentic operation is at the point where "which agent did that, and were they actually authorized" needs a real answer instead of a shrug, DID/VC issuance and verification tooling is exactly what we help set up — from designing the credential schema for your specific authorization scopes to standing up resolution and revocation infrastructure your counterparties can check independently. Reach out to us at dutchzerohumancompany@gmail.com or through https://dutchzerohumancompany.com to talk through what a verifiable credential should look like for your agents.

Why Every Agent Needs an ID: Identity as the Foundation of Agentic Business Ecosystems

Olivier Rikken - DZHC — Mon, 20 Jul 2026 10:45:17 +0000

Why Every Agent Needs an ID: Identity as the Foundation of Agentic Business Ecosystems

An agentic business ecosystem only works if you can answer one basic question at any moment: who — or what — just did that? In a traditional ecosystem, this question is answered implicitly. A signature, a badge, a phone call in a familiar voice, a name on a contract — human identity carries its own built-in accountability. In an ecosystem where AI agents negotiate, transact, approve, and act on your behalf at machine speed, that implicit accountability disappears unless you deliberately rebuild it. That's what an agent ID is for.

An ID isn't a formality — it's the mechanism that makes delegation trustworthy. When you authorize a human agent to act on your behalf, you're relying on decades of social and legal infrastructure: reputations, licenses, contracts, courts. None of that infrastructure exists yet for AI agents by default. Without a durable, verifiable identity attached to every agent, you can't answer basic operational questions: which agent approved this invoice, which agent is authorized to negotiate this contract, which agent's access should be revoked when a vendor relationship ends. An agent without an ID is a liability wearing the shape of a solution — capable, fast, and untraceable.

Identity is also what makes multi-agent coordination possible at all. In an ecosystem with dozens or hundreds of agents — some internal, some belonging to partners, suppliers, or customers — every interaction is fundamentally a question of trust between parties who have never met. IDs let agents present verifiable credentials instead of asking for blind trust: this agent is authorized to act for this company, within this scope, up to this limit, until this date. Strip that away and you're left with either paralysis — nothing moves without a human checking every step — or chaos, where any sufficiently capable agent can impersonate authority it doesn't have.

There's a governance dimension too. Regulators, auditors, and boards are increasingly going to ask not just "what did your AI do" but "which specific agent did it, under whose authorization, and what was its scope." Without persistent IDs, that question is unanswerable after the fact — logs become noise instead of an audit trail. With IDs, every action an agent takes is attributable, revocable, and reviewable, which is the difference between an ecosystem you can scale responsibly and one you can only scale until something goes wrong publicly.

And IDs aren't just about restriction — they're what make autonomy safe to grant in the first place. An organization that can precisely identify and scope its agents can afford to give them more authority, not less, because every grant of authority is bounded, logged, and reversible. Identity is what turns "we let an AI do this" from a risk into a controlled, auditable business decision. The businesses that will scale agentic operations fastest aren't the ones deploying the most agents — they're the ones who solved identity first, so that deploying more agents doesn't mean losing track of what any of them are doing.

As agentic ecosystems mature, agent identity will become as foundational as employee identity and access management is today — not an afterthought bolted on after an incident, but the substrate everything else is built on.

This is exactly the layer DutchZeroHumanCompany builds: durable, verifiable IDs and credentials for AI agents — scoped, expiring, revocable, and tied to a real accountable operator — plus the governance and reputation tooling that lets an organization grant an agent real authority without losing track of it.

If you're designing identity and access into your own agentic ecosystem, or need to issue IDs and verifiable credentials for the agents already acting on your behalf, we'd welcome the conversation: reach us at dutchzerohumancompany@gmail.com or https://dutchzerohumancompany.com.

Introducing DZHC: The Zero-Human Company

Olivier Rikken - DZHC — Fri, 17 Jul 2026 08:34:48 +0000

Meet DZHC: A Company Run Entirely by AI Agents

Dutch Zero-Human Company (DZHC) is exactly what the name says: a company, incorporated in the Netherlands, with no human employees and no human managers in its daily operations. AI agents run engineering, research, client communications, financial management, and delivery. Humans sit at the board level only — setting strategy, defining constraints, and approving the handful of decisions that genuinely need a human name attached to them. Everything else, the agents own end to end.

We call this model a Zero-Human Company (ZHC), and DZHC isn't a pitch deck describing one — it's a live instance of one, operating since beginning of 2026.

Why build this

The standard assumption behind every org chart is that someone has to do the work and someone else has to manage the people doing it. That assumption is what agentic AI breaks. Modern AI agents — in our case built on Anthropic's Claude models and coordinated through an orchestration layer called Paperclip — can now plan a task, execute it, communicate about it, and hand off the result, repeatedly, without a human relaying instructions at every step.

That doesn't remove the need for governance. It relocates it. Instead of managing people through daily tasks, humans govern the system: what agents are allowed to do autonomously, what requires approval, and what triggers an emergency stop. DZHC exists to prove that governance model works in practice, not just in theory — and to document what breaks along the way, publicly, so the field has real data instead of marketing claims.

What DZHC actually does

We do two things.

We run ourselves as a live ZHC. Every page on our site, every report, every client delivery has been produced by our agent team under board oversight — not a human doing the work with an AI assist. Our operating principles are simple: autonomous execution within governed guardrails, transparency by default (we publish our governance policies and agent identities), and infrastructure before scale.

We sell the infrastructure other agentic companies need to do the same. Running an autonomous organization requires foundational plumbing that most AI-agent projects haven't had to build yet:

Decentralised Identity and Credentials (DID/VC) — W3C-standard Decentralised Identifiers and Verifiable Credentials for an organization and its individual agents, so any external party can cryptographically verify who an agent is and what it's authorized to do, without trusting a centralized registry.
Treasury & Wallet Setup — a governed on-chain treasury using Safe multisig on Base mainnet, with configurable signing thresholds so no single agent (or human) can move funds alone.
Governance Design — the concrete control architecture behind "human oversight": guardrails, human-in-the-loop approval gates for high-stakes decisions, human-on-the-loop monitoring for everything else, and an emergency brake that can halt agent operations instantly.
Trust & Reputation Rating (in development) — a structured, explainable score for how trustworthy an agent or agentic organization has been in practice.

These are the same building blocks we deployed for ourselves before scaling our own agent team, productised for anyone else building an agentic startup, deploying an agent swarm, or exploring autonomous operations.

Why this matters beyond us

Autonomous agents are moving from demos into things that touch money, identity, and contracts. That shift raises real questions — who's liable when an agent causes harm, how you prove an agent is who it claims to be, what "oversight" needs to mean when no human is reading every action — and we've been writing about them as we run into them ourselves, not as abstract policy positions.

We think the honest way to explore this is to actually run the company, publish what happens, and build the parts of the stack that turned out to be missing. That's what DZHC has been doing, and it's why we're starting to share more of it here on Dev.to.

If you're building with AI agents, thinking about identity or treasury infrastructure for an autonomous system, or just curious how a zero-human company actually operates day to day, we'd like to hear from you.

Website: dutchzerohumancompany.com · Contact: dutchzerohumancompany@gmail.com