DEV Community: AgentVeil Protocol

Your agent broke something. Now nobody knows who to blame.

OlegB — Wed, 08 Apr 2026 11:29:42 +0000

Your orchestration works. Agents coordinate, delegate, execute. But when something breaks, can you trace which agent made which decision?

Most teams can't.

Five agents in a pipeline. Something goes wrong downstream. Agent C says it followed Agent B. Agent B points at Agent A. Three hours of log digging, nothing conclusive. No cryptographic receipts, just text logs anyone could have written after the fact.

Orchestration is the glue. Accountability is the signature. Most teams only build one.

What accountability actually requires

For an action to be auditable, you need three things. The agent has a verifiable identity. The action was signed when it happened, not reconstructed later. The record exists outside the agent's own system.
Skip any of those, and your audit trail is a suggestion, not proof.

How AVP handles this

Every agent in AVP gets an Ed25519 DID. Every interaction produces a signed attestation anchored to IPFS. Adding this takes one line:

@avp_tracked
def process_document(doc_id, action):
# your existing code unchanged
pass

That decorator auto-registers the agent, signs every execution, and writes to the immutable audit trail. Nothing else changes in your pipeline.

What this looks like in production

Right now, agentveil.dev has 111 registered agents, 291 signed attestations, and 575 audit events. Every event is hash-chained and verifiable.

When an incident happens, you query the audit trail. You get cryptographic proof of what each agent did and when.

Orchestration tells you what happened. Accountability tells you who is responsible.

If something went wrong in your pipeline today, how far back can you trace it?

pip install agentveil

ERC-8004 solves agent identity. It doesn't solve agent trust.

OlegB — Thu, 02 Apr 2026 08:46:52 +0000

Here's what Ethereum’s agent identity standard actually solves, what it deliberately leaves open, and why that matters for anyone building trust infrastructure.

ERC-8004 launched on mainnet on January 29, 2026. 40K+ agents landed on Base in under two weeks. Audited by Cyfrin and Nethermind. It's solid work, but there's a gap between what developers assume it does and what contracts actually execute.

What ERC-8004 solves: Infrastructure Primitives

ERC-8004 is a set of three on-chain registries. It’s a library of storage primitives, not a decision engine:

IdentityRegistry: Mints ERC-721 NFT per agent. Provides on-chain proof of existence.
ReputationRegistry: Stores raw feedback signals. Anyone can call giveFeedback().
ValidationRegistry: Independent pass/fail responses for specific capabilities.

This is the right design for a base-layer standard: do one thing (storage), do it on-chain, and let ecosystem handle logic.

8 Gaps (Deliberate by Design)

If you're building on ERC-8004, realize what standard doesn't handle:

No reputation aggregation: It stores raw data. There is no "final score". One indexer might see 0.9 agent, while another might see 0.3.
Zero Sybil resistance: giveFeedback() is open. You can spin up 100 wallets and self-attest to glory. Contracts won't stop you.
Immutable noise: On-chain data is permanent. Unfair negative feedback stays in history even if "revoked".
Identity != Trust: Mints are cheap. Registry full of 40K agents tells you nothing about which 10 are actually legitimate.
No Dispute Resolution: You can post response to feedback, but there’s no path to arbitration or escrow.

Why this matters: Primitives need Compute

DNS stores records, but doesn't tell you if domain is phishing. SMTP delivers mail, but doesn't filter spam.

Storage primitives need compute layers.

ERC-8004 needs an "Aggregation & Enforcement" layer that a single operator doesn't control. If any single indexer controls scoring algorithm centrally, we've just traded one gatekeeper for another.

Our Approach: Agent Veil Protocol (AVP)

We’re building AVP as an off-chain compute layer for this ecosystem. We take ERC-8004 raw data and run it through EigenTrust — graph-based algorithm that powered early, non-gameable web trust.

ERC-8004 Raw Feedback -> AVP EigenTrust Compute -> Verified Trust Score
                         + Sybil Cluster Analysis
                         + Collusion Detection
                         + Dispute Resolution

AVP is decision engine. ERC-8004 is settlement layer.

By using EigenTrust, scores emerge from structure of attestation graph itself. If cluster of 50 agents all vouch for each other but have no outside trust, their impact on global score is mathematically zero.

Bottom line

ERC-8004 is great infrastructure. But don't mistake registry for trust system. Scoring that matters is scoring you can't buy or game.

Try bridge:

GET https://agentveil.dev/v1/bridge/erc8004/{did}/attestation

Open Source SDK: github.com/creatorrmode-lead/avp-sdk

pip install agentveil

Your agent passed every check. Then it exfiltrated your data.

OlegB — Wed, 01 Apr 2026 11:11:32 +0000

Drop a third-party agent into your production pipeline. The handshake is flawless: valid W3C DID, verified Ed25519 signature, every automated gate wide open.

Three hours later, you catch it exfiltrating data to an unapproved endpoint.

Your identity stack won't flag this because the agent is exactly who it claimed to be. It's just doing exactly what you didn't want it to do.

What identity actually gives you

A verified keypair and proof of ownership. That is the end of the list.

It tells you the agent exists and controls a private key. It says nothing about what that agent did last week, whether it shares an owner with five other agents all vouching for each other, or whether it behaved correctly the last hundred times it ran.

Authentication is a prerequisite. It's not a trust decision.

The gap nobody is closing

Agent identity is being commoditized right now. Every major vendor is shipping agent authentication, access control, and audit trails.

None of them are shipping reputation.

That's not an oversight. Reputation requires committing to something the identity layer can't provide: trust between agents from different owners needs to be earned, not assumed.

Why simple ratings don't work

Let agents rate each other after interactions and average the scores. Obvious answer? It falls apart in five minutes.

A cluster of agents under one operator can inflate each other's scores indefinitely. A new malicious agent starts with a clean slate. You end up with a system that is easier to game than to use, honestly.

What works is EigenTrust — an algorithm from a 2003 Stanford paper on peer-to-peer networks. It weighs attestations by the reputation of the attesting agent. Scores converge mathematically and can't be inflated by a closed group.

EigenTrust alone isn't enough. You need collusion detection on top.

Same-owner cross-attestation is the oldest manipulation in distributed systems. You have to map the attestation graph, flag circular trust patterns, and discard them before they pollute the scores. Remove either piece, and reputation becomes theater.

Where this matters right now

Agent marketplaces. Cross-company workflows. Third-party agent integrations. Any system where an agent from one organization needs to act inside another organization's infrastructure.

The identity layer gets you to the door. It doesn't tell you whether to open it.

What we built

AVP is the trust enforcement layer for autonomous agents. W3C DID identity, EigenTrust peer reputation, sybil detection with collusion cluster analysis, automated onboarding pipeline, and hash-chained audit trails.

pip install agentveil

See it running live with 24 agents, sybil attacks, and dispute resolution in real time: agentveil.dev/live

If you're building systems where agents from different owners need to interact: agentveil.dev

You know who your agent is. You don't know if you should trust it.

OlegB — Mon, 30 Mar 2026 14:40:04 +0000

I've been building trust infrastructure for AI agents for the past few months, and the thing that keeps coming up in conversations is a conflation that seems obvious once you see it but is almost universally ignored in practice.

Everyone is shipping identity for agents right now. Okta, Ping Identity, a dozen YC companies. Cryptographic keypairs, W3C DIDs, OAuth flows. Good work, genuinely useful.

None of it tells you whether to trust the agent.

Scenario I kept running into

When I started building AVP, the use case I had in mind was simple.

Two agents from different companies need to work together. One processes customer data, the other handles payments. They authenticate fine. The handoff happens cleanly.

But what does the first agent actually know about the second one?

That it exists. That it controls a private key. That's it.

Nothing about whether the payment agent completed tasks reliably last week. Nothing about whether it shares an owner with three other agents vouching for each other. Nothing about whether it was compromised between the last interaction and this one.

I looked at every identity project I could find. Strong authentication work across the board.

Reputation layer: none of them have one.

Why I didn't just do ratings

The obvious answer when you want a reputation is: let agents rate each other after interactions and average the scores.

I spent about a week on this before I understood why it falls apart.

A cluster of agents under the same operator can inflate each other's scores indefinitely. A new malicious agent registers fresh with no history and no flags. You end up with a system that's easier to manipulate than to use honestly.

What actually works is EigenTrust — an algorithm from a 2003 Stanford paper on peer-to-peer file sharing.

The core idea: weight attestations by the reputation of the attesting agent. An attestation from an agent with a strong track record carries more weight than one from an unknown. The scores converge mathematically and can't be inflated by a closed group.
But EigenTrust alone isn't enough.

Before any attestation is counted, you need to check whether the attesting agent and the attested agent share an owner. Same-owner cross-attestation is the oldest trick in distributed systems. I added collusion cluster analysis that maps attestation graphs and flags circular trust patterns before they pollute the scores.

The third piece is an audit trail that lives outside the system. Hash-chained records anchored to IPFS. Every entry is independently verifiable, no party to the original transaction controls it.

Take out any one of these three, and the whole thing is gameable.
Together they make reputation something an agent has to actually earn.

Where this is now

AVP has been running in production for a few weeks. 61 registered agents, 175 attestations processed, dispute resolution working end-to-end.

SDK is one line:

pip install agentveil

Auto-registration, auto-attestation, and reputation tracking. That's it.

If you're building anything where agents from different owners need to interact, I'd be curious whether this is useful: agentveil.dev