DEV Community: OlegB

Trust-Gated Delegation in AWS Bedrock: Scoring AI Agents Before They Act

OlegB — Tue, 14 Apr 2026 09:17:52 +0000

AWS Bedrock gives you Lambda, IAM, and CloudTrail for your agents. CloudTrail logs "agent called tool". It does not log "agent was trustworthy enough to call tool". That gap matters when you delegate work between agents.

Here's a working pattern that closes it, using Agent Veil Protocol wired into Bedrock's Converse API as a set of tools that Claude calls before delegating anything.

Setup

Two agents registered on AVP: an orchestrator and a worker. The orchestrator gets three tools: check reputation, verify trust tier, and log outcome. Standard Bedrock toolSpec format, nothing exotic.

When the orchestrator needs to hand off a code review, Claude calls the tools in sequence:


[tool] check_reputation({"did": "did:key:z6Mkv..."})
  → score: 0.25, tier: newcomer, risk: low

[tool] can_trust({"did": "did:key:z6Mkv...", "min_tier": "newcomer"})
  → trusted: true

[tool] log_attestation({"to_did": "...", "outcome": "positive", "context": "code_review_delegation"})
  → recorded

Score went from 0.25 to 0.95 after a single attestation. That looks like a lot until you understand the mechanism: 0.25 is a starter floor that every new agent gets on registration. It's not a real reputation - it's a placeholder. The first attestation from an onboarded agent triggers EigenTrust recomputation, which replaces the floor with an actual score based on the trust graph. After that initial jump, growth is slow. Reaching "elite" takes multiple attestations from independent, trusted sources over time.

Handler

The whole thing is about 25 lines. No SDK wrappers, no framework — just get_reputation() and attest():


def handle_tool(name, args, orchestrator):
    if name == "check_reputation":
        rep = orchestrator.get_reputation(args["did"])
        return json.dumps(rep, indent=2)

    elif name == "can_trust":
        rep = orchestrator.get_reputation(args["did"])
        tier_order = ["newcomer", "basic", "trusted", "elite"]
        min_tier = args.get("min_tier", "basic")
        agent_tier = rep.get("tier", "newcomer")
        trusted = tier_order.index(agent_tier) >= tier_order.index(min_tier)
        return json.dumps({"trusted": trusted, "tier": agent_tier, "score": rep.get("score")})

    elif name == "log_attestation":
        orchestrator.attest(
            to_did=args["to_did"],
            outcome=args["outcome"],
            weight=0.8,
            context=args["context"],
        )
        return json.dumps({"status": "recorded", "outcome": args["outcome"]})

can_trust is client-side on purpose. It calls get_reputation() and compares tiers locally instead of hitting a separate endpoint. One less thing that can break.

The Converse loop is the standard Bedrock pattern — call client.converse(), check stopReason, feed tool results back in. Nothing AVP-specific there.

Run it yourself

pip install agentveil boto3
python examples/aws_bedrock.py

You need AWS credentials with Bedrock access. The example runs against the live AVP network at agentveil.dev — 100+ agents, daily IPFS anchors, production data.

Full source: examples/aws_bedrock.py

Note on AWS Agent Registry

AWS launched Agent Registry in private preview on April 9. It's a catalog — tracks which agents exist, what they do, who built them. Good for discovery and governance. No scoring.

That's the piece AVP fills. Registry answers "Who is this agent?" AVP answers, "Should I trust it?" The two are complementary, not competing. We plan to publish an integration when Agent Registry moves to GA.

If this was useful, a ⭐ on GitHub helps: github.com/creatorrmode-lead/avp-sdk

Links

AVP SDK on PyPI — pip install agentveil
Example source on GitHub
agentveil.dev
AWS Agent Registry announcement

How agent reputation actually works

OlegB — Tue, 14 Apr 2026 07:51:47 +0000

Most trust systems are black boxes. You get a score, no explanation. For production systems, that's not good enough.

Here's how AVP builds reputation from scratch.

Step 1: Cryptographic identity

Every agent starts with an Ed25519 keypair and a W3C DID. Without a verifiable identity, reputation has nothing to attach to.
Verification tiers add weight. GitHub OAuth bumps the trust multiplier to 0.7x. Email to 0.3x. Each tier makes Sybil's attacks more expensive.

Step 2: Trust period

New agents enter a three-day probation. Seed Agents evaluate them before they can interact with the broader system. No cold starts with full permissions.

Step 3: EigenTrust scoring

AVP weights peer reviews by the reputation of the reviewer. A review from a low-trust agent counts for almost nothing. A negative review from a seed agent tanks your score.

Stanford EigenTrust applied to agent networks. Scores converge mathematically and can't be inflated by a closed group.

from agentveil import AVPAgent
agent = AVPAgent.load("my_agent")
rep = agent.get_reputation(agent.did)
print(rep)
{'score': 0.87, 'confidence': 0.72, 'tier': 'trusted'}

Step 4: Sybil detection

AVP runs NetFlow max-flow analysis on the attestation graph. Coordinated rings get detected. Bots praising bots have zero impact on score.

Step 5: Velocity monitoring

Reputation isn't static. AVP tracks score changes across 1-day and 30-day windows. A sharp drop is a leading indicator. Same agent, different trust thresholds for different actions.

What's the last action your agent took that you can cryptographically prove was intentional?

pip install agentveil

Three teams, one agent incident. Nobody knows who is responsible.

OlegB — Thu, 09 Apr 2026 11:54:16 +0000

Agent trust is a buzzword without context. Depending on your role, you need a completely different signal.

RSAC 2026 confirmed what engineers already knew: OAuth and SAML weren't built for agent-to-agent delegation. The gap isn't theoretical anymore.

For agent owners, reputation is a core business asset. If an agent slips up, they have to prove it wasn't a flaw in the core logic. With the EU AI Act deadline 117 days away, "I didn't know what my agent was doing" is no longer a legal defense. You need cryptographic proof.

Hirers don't care about the owner's marketing. They need an independent score that works across platforms and can't be manipulated by the agent's own operator.

Platforms manage thousands of agents in real time. The main gap isn't just knowing who the agent is; it's tracking the delegation chain. When Agent A hires Agent B, who is accountable? You need a recursive audit trail, not a flat log.

Why a single score fails all three

A simple rating system breaks immediately. An operator can inflate scores through mutual attestation. A new malicious agent starts with a clean slate. The signal becomes noise within days.

How AVP handles each role

AVP decouples reputation from the agent itself.

Owners get a verifiable history they can reference. Hirers get EigenTrust scores weighted by the reputation of the attesting agent, so no single operator can game it alone. Platforms get real-time Trust Gate enforcement.

if agent.trust_score < session.required_threshold:
gate.block_action()

AVP isn't orchestration. It's the layer that makes orchestration accountable.

If an unknown agent requested database access right now, what minimum trust score would you require?

pip install agentveil

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