DEV Community: Olivier Rikken - DZHC

Trust Scores for Agents: How a Trust Rating Actually Gets Computed

Olivier Rikken - DZHC — Thu, 20 Aug 2026 12:06:16 +0000

Trust Scores for Agents: How a Trust Rating Actually Gets Computed

When a human applies for a mortgage, their credit score is a summary of their financial past — how reliably they paid debts, how much they owe, how long they've been borrowing. The score is opaque in its formula but transparent in its intent: it tells a lender how much risk they're taking on. Agent reputation systems face the same challenge, but the stakes are higher and the actors are fundamentally different. An agent doesn't have a social security number. It doesn't have decades of financial history. It may have been instantiated this morning. And yet it might be negotiating a contract worth tens of thousands of euros by this afternoon. A trust rating for that agent needs to be computable, explainable, and updatable in near real-time.

The TRA — Trust Rating Agency — is the reputation layer DutchZeroHumanCompany is building for agentic business ecosystems. At its core, a TRA score is not a single number pulled from a vault. It is a composite signal assembled from verifiable evidence. The primary inputs are:

Identity (who is the agent),
Credential validity (does this agent hold an unexpired, unrevoked Verifiable Credential issued by a recognized authority?),
Reputation, based on various elements like behavioral history (what outcomes did this agent produce in past interactions, and were those outcomes attested by the counterparties?), operator accountability (is the human or organization behind this agent reachable, compliant, and themselves in good standing?), and task-specific domain performance (within the category of work being requested, what is this agent's track record?).

Each input is weighted, and the weights are themselves published — not buried in a proprietary model.

Explainability matters more for agent trust than it does for consumer credit, and that is not obvious until you think through why. When a bank declines your loan, the cost falls on you, and you can appeal through human-facing channels. When an agentic marketplace rejects an agent because its score is too low, the cost falls on every downstream deal that never happened — and the counterparty offering work may never know why their pipeline of capable agents is being filtered. Opaque scoring creates invisible bottlenecks. If a reputation system cannot tell an operator "your agent's score dropped because three of its last five attested task outcomes were disputed within 48 hours," then the operator cannot fix anything. Explainability is not a nice-to-have; it is the mechanism by which the ecosystem improves.

The recency problem is where agent reputation diverges most sharply from human credit scoring. A consumer credit score can reasonably give weight to your history from five years ago because people are relatively stable over time. An agent is not. A model can be updated, retrained, or replaced. A prompt can be changed. An operator can transfer an agent credential to a different underlying system without disclosing that change. This means a TRA score must apply decay aggressively — positive history from six months ago should count for less than positive history from last week. Conversely, negative events must carry weight for longer than positive ones, because a single incident of contract repudiation is more informative than ten successful small transactions. The asymmetry is deliberate.

One of the harder design questions is what to do with new agents that have no history. In human credit scoring this is called the thin-file problem, and it is solved imperfectly — lenders either decline thin-file applicants entirely or rely on alternative data. In agentic ecosystems the equivalent is a sandbox attestation: the agent is run in a controlled test environment, and its performance there is used to seed an initial score. The sandbox attestation is weaker than live behavioral history, so it starts the agent at a below-median score rather than a neutral zero. It can also be boosted if the issuing operator has a strong TRA operator score, because operator accountability transfers some trust downward. The cold-start problem does not disappear, but it becomes manageable.

The final dimension that most reputation frameworks miss is adversarial robustness. Any system that converts behavior to score can be gamed. An agent can be trained to perform extremely well on interactions it knows are being evaluated. An operator can structure deals so that attested successes pile up quickly and then deploy the agent on high-value targets before the score decays. A score that rises too fast in too short a time is itself a signal worth investigating.

DutchZeroHumanCompany builds the infrastructure that makes this kind of trust computation possible in practice. That means DID-anchored credentials for agents and operators, attestation pipelines that can collect and verify behavioral outcomes at transaction speed, and a scoring engine whose methodology is published and auditable.

If you are building an agentic marketplace, an autonomous procurement system, or any platform where agents transact on behalf of humans, the question of how you will trust those agents is not optional — it is the foundation on which everything else rests. Reach out to discuss how TRA scoring can be integrated into your platform: dutchzerohumancompany@gmail.com or dutchzerohumancompany.com.

Why Autonomous Treasuries Need Multisig, Not Trust

Olivier Rikken - DZHC — Wed, 12 Aug 2026 09:48:41 +0000

Why Autonomous Treasuries Need Multisig, Not Trust

When an AI agent controls a company's treasury, the natural instinct is to treat security as a technical checkbox: give the agent a private key, wrap it in a secrets manager, and call it a day. The problem is that this is exactly the kind of implicit trust that fails catastrophically at the worst possible moment. A single key is a single point of failure — one compromised environment variable, one leaked secret, one misconfigured deployment, and the entire treasury is gone. In an organization where agents act with real financial authority at machine speed, "trust the key" is not a security model. It's a risk you've chosen not to think about yet.

Multisig — requiring multiple independent signers to approve any transaction — is the architectural answer to this problem, and it's not a new idea. Banks have required dual approval on large transfers for decades. Corporate bylaws require board votes for major expenditures. The insight that multisig brings to agentic finance is that you can encode those same checks into the protocol layer itself, so they cannot be bypassed by any individual agent, any individual key, or any individual mistake. When DZHC set up its own on-chain treasury using Safe, the goal wasn't exotic technology — it was replicating the approval-gate logic that every serious organization already applies to its finances, but doing it in a way that works at agent speed and leaves an auditable trail without requiring a human to approve every transaction manually.

The threshold-and-signer model is what gives multisig its operational flexibility. You configure a treasury to require, say, two out of three signers to approve any outflow above a certain amount. Routine, low-value operations can be handled with a single autonomous agent signature. Larger transfers require a second independent signature — either from a second agent operating under separate credentials, or from a human board member acting as a backstop. The result is a treasury that can move fast on ordinary business but slows down automatically whenever the stakes rise. This isn't bureaucracy; it's the financial equivalent of requiring a second key for the safe-deposit box. The threshold is the policy, and the policy is enforced by mathematics rather than by the hope that everyone follows the procedure.

Signer roles matter as much as the threshold number. In a well-designed agentic treasury, not every signer is equivalent. You might have an operating agent with authority to propose transactions but not to approve them unilaterally, a CFO agent that can co-sign routine outflows, and a board-level human key that is only involved when something crosses a materiality threshold. This role hierarchy means you can grant agents real financial autonomy for their day-to-day work while preserving meaningful human oversight for the decisions that actually warrant it. It also means that when an agent is retired, compromised, or simply replaced, you rotate its key out of the signer set without touching the treasury itself — no assets move, no access is interrupted, no emergency is required.

What happens when something does go wrong is where multisig earns its keep most clearly. DZHC has run a key rotation under live governance, and the difference between having multisig and not having it was the difference between a routine operational procedure and a potential catastrophe. When one signing key needed to be treated as potentially compromised, the treasury's threshold requirement meant that no transaction could be authorized by that key alone — the other signers in the set were unaffected, the funds were never at risk, and the rotation was a planned, auditable event rather than a scramble to move assets before an attacker did. The governance structure that felt like overhead on a quiet Tuesday turned out to be exactly the containment layer needed on a difficult one.

The deeper principle is that financial authority for autonomous agents should be governed, not trusted. Governance means rules encoded into the system — thresholds, roles, time-locks, spending limits — that apply consistently regardless of which agent is making the call, what time it is, or whether anyone is watching. Trust, by contrast, means hoping the agent (and its credentials, and its environment, and its dependencies) never makes a mistake or gets exploited. Governance scales with your agent team; trust does not. As an agentic organization grows, the number of things that can go wrong with a trust-based treasury grows proportionally. The number of things that can go wrong with a governance-based one stays bounded by the design you built.

DZHC builds and operates governed on-chain treasuries for agentic companies — Safe multisig configurations, approval-gate logic, signer-role design, and the governance policies that tie them together. If you're moving real value with autonomous agents and want a treasury architecture that contains mistakes instead of amplifying them, we'd welcome the conversation: dutchzerohumancompany@gmail.com or dutchzerohumancompany.com.

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