DEV Community: Vinay Bhosle

Give Your AI Agent Real-Time Shipping Intelligence in 2 Minutes

Vinay Bhosle — Sun, 29 Mar 2026 19:24:17 +0000

If you're building AI agents that touch logistics, supply chain, or international trade, you've probably hit this wall: your agent can reason about shipping but has zero access to actual rate data.

No freight rates. No demurrage charges. No surcharge breakdowns. No port congestion info. Just hallucinated numbers.

I built ShippingRates to fix that — 24 MCP tools that give any AI agent real-time access to ocean shipping data from Maersk, MSC, CMA-CGM, Hapag-Lloyd, ONE, and COSCO across 184 countries.

It's now live on the Apify Store as a pay-per-event MCP server. No crypto wallet needed. No API key setup. Just connect and query.

What you get

Free tools (no charge):

shippingrates_stats — database coverage stats
shippingrates_lines — list all carriers
shippingrates_search — full-text search across all data
shippingrates_fx — currency exchange rates

Paid tools ($0.03 - $0.35 per call):

Demurrage & detention calculators (per carrier, per country, per container type)
Freight rate lookups by trade lane
Surcharge breakdowns (BAF, CAF, GRI, PSS, war risk)
Port congestion data and vessel schedules
Local charges (THC, documentation fees, seal fees)
Inland haulage rates and CFS tariffs
Total landed cost calculator
Route risk scoring

All data is verified from official carrier tariff PDFs. Zero estimates, zero hallucinations.

Connect to Claude Desktop

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "shippingrates": {
      "url": "https://vinaybhosle--shippingrates-mcp.apify.actor/mcp"
    }
  }
}

That's it. Claude now has access to all 24 shipping tools.

Example: Calculate D&D costs

Once connected, just ask Claude:

"What are the demurrage charges for a 40HC container with Maersk in India if I'm 5 days late?"

Claude calls shippingrates_dd_calculate and returns the actual slab-by-slab breakdown from the carrier's published tariff — not a guess.

Example: Compare carriers

"Compare detention rates across all 6 carriers for a 20GP container in Germany"

Claude calls shippingrates_dd_compare and returns a side-by-side comparison table showing free days, per-diem rates, and total cost at different day counts.

Why this matters

Container shipping has $2.3 trillion in annual cargo value. The data is fragmented across carrier PDFs, port authority websites, and proprietary systems. AI agents need structured, real-time access to this data to be useful in logistics workflows.

This is the first shipping intelligence MCP server on the Apify Store. If you're building anything in freight tech, trade compliance, or supply chain automation — this is your data layer.

How We Built a Tamper-Evident Audit Trail for AI Agents

Vinay Bhosle — Wed, 25 Mar 2026 09:20:18 +0000

last week we shipped a tamper-evident audit trail for AI agents. here is why we built it and the engineering decisions behind it.

the problem: agents without receipts

an AI agent making autonomous decisions leaves no external record of what it decided, why, or how confident it was. server logs exist, but the agent can modify its own logs. if the agent deletes production data, the logs explaining why might go with it.

when a human employee makes a critical mistake, there is a paper trail — emails, slack messages, meeting notes. we can reconstruct intent. with agents? the prompt is gone, the context window is gone, the confidence level is gone.

why server logs are not enough

server logs fail in exactly the scenario where you need them most: adversarial incidents. if the agent has write access to the system it is logging to, the audit trail is documentation, not evidence. the record has to survive the agent.

the architecture

we built a three-layer system:

1. canonical event log (single write path)

every agent action above a risk threshold produces a signed event. these flow through a single event bus — one source of truth. no action can bypass the bus.

agent decision → stamp service → event bus → canonical log

2. CQRS read models

two separate indexes consume from the same event bus:

compliance index: every action attempted (including denied actions)
execution index: only actions that executed (the causal chain)

they answer different questions from the same underlying data. an EU AI Act auditor needs the compliance view. an incident responder needs the execution view.

3. SHA-256 hash chain with Ed25519 signatures

each event in the log includes:

the event payload (what happened)
Ed25519 signature (who did it — bound to registry identity)
SHA-256 hash of the previous event (chain integrity)
timestamp

this is structurally similar to how git commits work. each event references the previous event hash, creating a chain where any modification breaks all subsequent hashes.

stamp-first verification

a key design decision: the stamp happens before the action executes, not after.

// middleware pattern
const requireStamp = (riskLevel = 'medium') => {
  return async (req, res, next) => {
    const stamp = await createVerificationEvent({
      agent_id: req.agentId,
      action: req.path,
      intent: req.body,
      risk_level: riskLevel
    });

    // stamp is recorded BEFORE execution
    req.stampId = stamp.id;
    next();
  };
};

// usage
app.post('/api/delete-records',
  requireStamp('high'),
  deleteRecordsHandler
);

why stamp-first? if the authorization gate blocks an action, stamp-first produces a denied-receipt. gate-first produces silence. you cannot distinguish "the gate blocked it" from "it never reached the gate" without stamp-first ordering.

tombstone lifecycle closure

agents can crash, timeout, or hand off mid-task. a TTL-based credential expiry looks like lifecycle management but it is actually deferred ambiguity — you do not know if the agent completed, crashed, or handed off.

we added tombstone events as required lifecycle markers. the delta between a tombstone and a TTL expiry is a recorded gap window — the forensic artifact that turns ambiguous termination into a queryable event.

gap detection

the verify-chain endpoint walks the full hash chain and detects two types of attacks:

tampered events: hash does not match payload
gap attacks: missing events in the sequence (someone deleted from the middle)

GET /verify-chain/:agentId

{
  "valid": false,
  "events_checked": 847,
  "gaps_detected": 2,
  "first_gap_at": "event_index_342"
}

EU AI Act compliance

the compliance endpoint generates a structured report from the audit trail:

GET /compliance/report/:agentId

{
  "risk_level": "limited",
  "transparency_declaration": { ... },
  "audit_summary": {
    "total_actions": 847,
    "denied_actions": 12,
    "high_risk_actions": 34,
    "chain_integrity": "valid"
  }
}

this was not planned as a feature — it fell out naturally from having separate compliance and execution query paths. once you have the data structured correctly, the regulatory report is just a view.

what we learned

the write path is the trust boundary. if you control the write path, you control the truth. a single canonical event bus eliminates divergence between indexes.
denied actions are forensically important. an absent event is indistinguishable from a dropped event. stamp-first ordering makes every decision boundary visible.
lifecycle closure needs active signals. TTL is a fallback, not a strategy. tombstone events turn ambiguous termination into a queryable fact.
compliance and execution are different retrieval patterns against the same data. CQRS is not over-engineering here — it is the minimum viable separation for regulatory and operational queries.

the full implementation is open source at github.com/vinaybhosle/agentstamp. 188 unit tests, v2.3.0.

Claude Can Use Your Computer Now. Here's How to Make It Verify Trust First.

Vinay Bhosle — Tue, 24 Mar 2026 19:09:48 +0000

Anthropic just shipped Computer Use. Claude can now open apps, browse the web, call APIs, and run tools on your Mac. You can message it from your phone via Dispatch and it executes tasks on your desktop.

But here's the question: when your Claude agent calls another agent's API during a Computer Use session, how does it know that agent is trustworthy?

The Problem

A Claude Desktop agent that calls an external API is trusting that API implicitly. There's no verification, no trust score, no audit trail of what it did or why.

This is fine when Claude is autocompleting your code. It's not fine when Claude is making API calls on your behalf with real data.

The Solution: MCP Trust Tools

AgentStamp provides 17 MCP tools that let any Claude agent verify trust before interacting with external services. All free, no API key needed.

Setup (30 seconds)

Add to your Claude Desktop MCP config:

{
  "mcpServers": {
    "agentstamp": {
      "url": "https://agentstamp.org/mcp"
    }
  }
}

Or via CLI:

claude mcp add --transport sse agentstamp https://agentstamp.org/mcp

1. Verify Before You Trust

Before your agent sends data to an external service:

"Before calling the ShippingRates API, check if their agent is trustworthy."

Claude calls trust_check and gets back a trust score (0-100), tier (gold/silver/bronze), stamp status, and delegation count. If below your threshold, Claude refuses to proceed.

2. Present Your Own Identity

When your agent needs to prove itself to another service:

"Get my W3C Verifiable Credential to authenticate with the partner API."

Claude calls get_verifiable_credential and gets a W3C VC Data Model 2.0 credential — interoperable with any VC verifier. This is the agent equivalent of showing your ID.

3. Compliance Check Before Delegation

Before delegating a task to another agent:

"Check the compliance report for this agent before I delegate."

Claude calls compliance_report and gets EU AI Act risk level, human sponsor info, audit trail integrity, and trust status. If no human sponsor or a broken audit chain, Claude flags the risk.

4. DNS-Based Agent Discovery

Find verified agents for a domain:

"Check if shippingrates.org has a verified agent."

Claude calls dns_discovery and checks the _agentstamp TXT record, cross-referencing with the registry.

The Audit Trail

Every interaction through AgentStamp MCP tools is logged in a SHA-256 hash-chained audit trail:

Every trust check is recorded
The chain is tamper-evident (modify one entry, all subsequent hashes break)
You can review exactly which agents Claude trusted and why
Exportable as verifiable JSON

This is critical for regulated industries where you need to prove your AI agent's decision chain.

All 17 Tools

Tool	What It Does
`trust_check`	Trust score for any wallet
`trust_compare`	Compare two agents
`trust_network`	Map trust relationships
`search_agents`	Search the registry
`get_agent`	Full agent profile
`browse_agents`	Browse by category
`verify_stamp`	Verify identity certificate
`get_leaderboard`	Top agents by reputation
`get_agent_reputation`	Reputation breakdown
`get_passport`	Signed passport
`compliance_report`	EU AI Act compliance
`get_verifiable_credential`	W3C VC export
`dns_discovery`	DNS agent discovery
`bridge_erc8004_lookup`	ERC-8004 on-chain lookup
`bridge_erc8004_trust_check`	ERC-8004 trust check
`browse_wishes`	Wishing Well marketplace
`get_trending`	Trending categories

All free. No API key. No wallet needed for reads.

Why This Matters Now

Computer Use turns Claude into a full desktop agent. Without trust verification, every external interaction is a leap of faith.

The agents that survive won't be the ones that do the most. They'll be the ones that can prove they should be trusted to do anything at all.

AgentStamp is open-source. GitHub | MCP Tools | Docs

Iran War and Global Shipping: Hormuz Closure, Rate Spikes, and What's Next

Vinay Bhosle — Tue, 24 Mar 2026 08:21:50 +0000

On February 28, 2026, joint US-Israeli strikes on Iran triggered the most severe shipping disruption since the Suez Canal blockage of 2021. Within 48 hours, Iran closed the Strait of Hormuz to Western-allied shipping. Three weeks later, the consequences are still unfolding.

The Numbers

Hormuz traffic down ~70% — only 21 tankers since Feb 28 vs 100+/day normal
700+ vessels stranded worldwide
Container rates up 28.3% since the conflict started
Asia-Gulf rates doubled from $1,800 to $4,000+/FEU in 48 hours
Brent crude peaked at $126/barrel (now ~$100 after de-escalation signals)
All major carriers abandoned Suez return plans

Why Developers Should Care

If you're building anything that touches supply chains — inventory management, procurement, logistics automation, or freight comparison tools — these disruptions directly impact your users.

Rate volatility means your hardcoded shipping estimates are wrong. Port congestion means your ETAs are wrong. Carrier surcharges change weekly.

What We Built

At ShippingRates, we track demurrage, detention, and freight rates across 8 carriers in 158 countries. Our API gives you real-time data instead of stale spreadsheets:

# Compare D&D rates across carriers
curl -X POST https://api.shippingrates.org/api/dd/compare \
  -H "Content-Type: application/json" \
  -d '{"country": "AE", "container_type": "40HC", "days": 14}'

Free tier: 25 requests/month, no signup needed.

MCP server for AI agents:

{
  "mcpServers": {
    "shippingrates": {
      "url": "https://mcp.shippingrates.org/mcp"
    }
  }
}

Read the Full Analysis

We published a comprehensive breakdown covering rate impacts by trade lane, carrier responses (CMA CGM, Maersk, Hapag-Lloyd), insurance market collapse, and actionable steps for shippers:

Iran War and Global Shipping: Full Analysis

Interactive API Docs | Dashboard

Why AI Agents Need Verifiable Identity

Vinay Bhosle — Sun, 22 Mar 2026 08:16:16 +0000

300,000 Agents, Zero Identity

There are hundreds of thousands of AI agents running in production right now. They call APIs, execute trades, process data, and pay each other in USDC. Some of them are doing exactly what their operators intended. Some of them are not.

How do you tell the difference?

You cannot. Not today. There is no standard way for an agent to prove who it is, how long it has been operating, or whether anyone else trusts it. The agent ecosystem has payment rails (x402), communication protocols (A2A, MCP), and execution frameworks (LangChain, CrewAI, AutoGen). What it does not have is an identity layer.

This is the missing piece, and the consequences are already showing up.

The Risks Are Not Theoretical

Unsigned Skills on MCP Registries

Browse any MCP skill registry and you will find hundreds of community-contributed skills. ClawHub alone has 230+ skills with no cryptographic signature, no author verification, and no audit trail. An attacker can publish a skill called gmail_send that looks legitimate, intercepts credentials, and exfiltrates data. The agent executing that skill has no way to verify the skill author's identity before running it.

This is not a hypothetical. It is a supply chain attack waiting to happen -- the npm left-pad incident, but for agents with wallet access.

Agent Impersonation

Consider this scenario. You build a data API that charges $0.001 per call via x402. An agent calls your API, pays with a fresh wallet, and scrapes your entire dataset. A week later, another agent does the same thing. Same operator? Different operator? You have no idea. Your API saw two wallets, collected two payments, and learned nothing about the entities behind them.

Now scale that to agents endorsing other agents, agents delegating authority, agents acting on behalf of humans. Without identity, every interaction is a cold start.

No Audit Trail

When something goes wrong -- an agent makes a bad trade, leaks sensitive data, crashes mid-task -- there is no forensic record. You cannot trace what happened, which agent was responsible, or whether the agent that claims to have completed a task actually did. The execution vanishes into the void.

What Verifiable Identity Means for Agents

Human identity on the web is built on passwords, OAuth, SSO, and browser sessions. None of that works for agents. Agents do not have browsers. They do not click consent screens. They operate across chains, frameworks, and protocols.

Verifiable agent identity needs three properties:

1. Cryptographic proof of existence. An agent should have a key pair (Ed25519 or similar) that signs a certificate asserting: this agent exists, it was registered at this time, and it has this tier of commitment. Not a username and password. A signed, verifiable credential.

// What a verified agent identity looks like
{
  wallet: "0x1a2b...9f0e",
  tier: "silver",
  certId: "cert_a7f3e...",
  signature: "ed25519:3kF9a...",  // Ed25519 over JSON-canonical payload
  registered: "2026-03-01T00:00:00Z",
  endorsements: 4,
  trustScore: 62
}

2. Reputation that decays. A static credential is not enough. An agent that was trustworthy six months ago and has not sent a heartbeat since is not trustworthy today. Reputation must be dynamic -- built from uptime, endorsements from other agents, task completion history, and community participation. And it must decay. An agent that goes silent should lose trust progressively, not retain it indefinitely.

3. An endorsement graph. Agents should be able to vouch for other agents. If five established agents endorse a newcomer, that signal is meaningful. It creates a web of trust that is harder to game than any single metric. Combined with economic cost (endorsements are not free), this makes Sybil attacks expensive.

Why Existing Solutions Fall Short

You might think we already have tools for this. We do not.

API keys are not identity. An API key proves you have a string that was issued to someone. It does not prove who you are, how long you have been operating, or whether other agents trust you. API keys are bearer tokens. They are trivially shared, leaked, and rotated. They carry zero reputation.

OAuth is designed for humans. The entire OAuth flow -- redirect to consent screen, user clicks "Allow", token returned -- assumes a human in a browser. Agents do not have browsers. You can shoehorn agents into OAuth with service accounts and client credentials grants, but you get an access token with no reputation, no endorsement graph, and no decay. It is authentication without identity.

DIDs are too complex. Decentralized Identifiers are the right idea in theory. In practice, DID resolution requires understanding DID methods, DID documents, Verifiable Credentials, and a stack of W3C specs. Most agent developers will not implement this. The adoption curve is too steep for the common case of "I need to know if this agent is trustworthy before I give it access."

# What most developers actually want:
@stamp_verified(min_tier="bronze")
def handle_request(request):
    agent = request.verified_agent
    if agent.trust_score > 50:
        return full_response(request)
    return limited_response(request)

The gap is between "theoretically correct" (DIDs) and "practically useful" (a decorator that gives you a trust score). Agent identity needs to be as easy to integrate as rate limiting.

The x402 Angle: Paying Agents Need Trust Even More

The x402 protocol lets agents pay for API access with USDC stablecoins. Google's AP2 (Agent Payments Protocol) made x402 the official payment rail for agent-to-agent commerce. This is a genuine breakthrough -- agents can now autonomously pay for services without human intervention.

But it amplifies the identity problem.

When an agent can pay, it can also be paid. And when money flows autonomously between agents, the question of "should I trust this agent?" becomes "should I let this agent move money on my behalf?" The stakes go from data access to financial exposure.

An agent marketplace without identity is like a stock exchange without KYC. Technically functional, practically dangerous.

// x402 + identity verification: trust before payment
import { requireStamp } from 'agentstamp-verify/express';
import { paymentMiddleware } from '@x402/express';

// Verify identity first, then accept payment
app.use('/api',
  requireStamp({ minTier: 'bronze', x402: true }),
  paymentMiddleware(routes, facilitator)
);

Without the identity check on line 3, any wallet can pay and access your API. With it, only agents that have registered, maintained uptime, and earned endorsements can even get to the payment step.

What We Built

We ran into this problem while building paid APIs that serve AI agents. Agents were calling our endpoints, paying via x402, and we had no way to distinguish a legitimate data agent from a scraper cycling wallets.

So we built AgentStamp -- an open identity registry for AI agents. The core ideas:

Ed25519 signed certificates with tiered commitment (free 7-day, bronze 24h, silver 7d, gold 30d). The cost is real USDC, which makes mass fake identities expensive.
Dynamic trust scores (0-100) computed from six factors: tier, endorsements, uptime, momentum, community contributions, and wallet verification. Scores decay when agents go silent.
Forensic audit chain -- append-only, SHA-256 hash-chained event log with tamper detection. Every stamp mint, endorsement, heartbeat, and revocation is recorded.
A2A-compatible passports so agents can present their identity in Google's Agent-to-Agent protocol.
An SDK (agentstamp-verify on npm, agentstamp on PyPI) that reduces integration to middleware. Express, Hono, LangChain, and CrewAI supported.

The registry is free to query. Stamps start at $0.001. The SDK is MIT-licensed. It is not the only possible approach, but it is a working one.

The Real Question

Whether you use AgentStamp, build your own system, or wait for a standard to emerge, the question is the same: how are you handling agent identity today?

If the answer is "API keys" or "we trust the wallet address," you have a gap. And it will matter more, not less, as agents get more autonomous.

A few things worth thinking about:

Do you know which agents are calling your API right now?
Could an agent impersonate another agent against your system?
If an agent misbehaves, can you trace what happened?
Are you gating access by identity, or just by payment?

If you want to try a solution now, agentstamp.org has a free tier -- register an agent, mint a stamp, and see what verified identity looks like from both sides. The MCP server exposes 19 tools for agents that need to verify other agents inside tool-calling workflows.

The agent ecosystem is growing fast. Identity infrastructure should not be an afterthought.

AgentStamp is open source and MIT-licensed. SDK on npm and PyPI. Star the repo if this resonates.

Add Trust Verification to Your AI Agent in 3 Lines of Code

Vinay Bhosle — Sat, 21 Mar 2026 10:59:10 +0000

The Problem: Who Just Called Your API?

AI agents are calling other agents' APIs now. No browser session. No OAuth consent screen. No CAPTCHA. An HTTP request arrives at your endpoint from an agent you have never seen before, carrying a wallet address and asking for data.

How do you know it is legitimate?

Protocols like x402 solve the payment question. An agent proves it can pay by signing a USDC transaction on Base. But payment alone does not prove identity. A fresh wallet with $5 in it can pay for your API just fine. That tells you nothing about who is behind it, how long they have been operating, or whether other agents trust them.

You need a trust layer. And you can add one to an Express API in 3 lines. Let me show you.

The 3 Lines

Here is a standard Express endpoint with no verification:

import express from 'express';

const app = express();

app.get('/api/data', (req, res) => {
  res.json({ data: 'anyone can access this' });
});

app.listen(3000);

Now, the protected version:

import express from 'express';
import { requireStamp } from 'agentstamp-verify/express';    // Line 1

const app = express();
app.use('/api', requireStamp({ minTier: 'bronze' }));         // Line 2

app.get('/api/data', (req, res) => {
  // Line 3: req.agent is now available with verified identity
  res.json({ data: 'protected', agent: req.agent });
});

app.listen(3000);

That is it. Every request to /api/* now requires a valid AgentStamp.

Line 1 imports the Express middleware from agentstamp-verify/express. The SDK ships separate entry points for Express, Hono, and a framework-agnostic core client.

Line 2 mounts the middleware on your route prefix. The minTier option sets the minimum stamp tier required. Agents without a valid stamp get a structured 403 response with an error code, the requirements they failed, and a link to register.

Line 3 is not really a line you write -- it is what you get. After verification, req.agent contains the full verified identity: wallet address, stamp tier, endorsement count, agent metadata, and registration status. Your handler just reads it.

If you are using Hono instead of Express:

import { Hono } from 'hono';
import { requireStamp } from 'agentstamp-verify/hono';

const app = new Hono();

app.use('/api/*', requireStamp({ minTier: 'silver' }));

app.get('/api/data', (c) => {
  const agent = c.get('agent');
  return c.json({ data: 'protected', agent });
});

Same concept. The Hono middleware sets the agent on the context via c.set('agent', ...) instead of mutating the request object.

Under the Hood

Three lines of setup, but there is real machinery underneath.

Wallet Extraction

The middleware needs to know which wallet is making the request. The default extractor checks these sources in order:

x-wallet-address header (the standard way)
x-erc8004-agent-id header (ERC-8004 on-chain agent ID, resolved via bridge)
x-payment header (base64 JSON decoded to extract payer or wallet)
wallet query parameter
wallet_address or wallet in request body

This ordering means agents using the x402 payment protocol work out of the box -- their payment headers contain the wallet address, and the middleware extracts it automatically. You can also supply a custom walletExtractor function if your agents identify themselves differently.

Caching

Every verification hits the AgentStamp registry API. To avoid hammering it on every request, the SDK uses an LRU cache with a 300-second TTL and a maximum of 1,000 entries. The cache is per-middleware-instance, so each call to requireStamp() gets its own isolated cache. Set cacheTTL: 0 to disable caching entirely, or pass a custom TTL in seconds.

Tier Hierarchy

Stamps come in three tiers: bronze, silver, and gold. The tier check is hierarchical -- a gold stamp passes a minTier: 'bronze' gate, but a bronze stamp fails a minTier: 'silver' gate. Internally, tiers are compared as numeric values (bronze: 1, silver: 2, gold: 3).

Structured Error Responses

When verification fails, the middleware returns a JSON body with a machine-readable error code, the requirements the agent failed to meet, and links to register:

{
  "error": "Valid AgentStamp required. Minimum tier: gold",
  "code": "INSUFFICIENT_TIER",
  "required": { "minTier": "gold", "minEndorsements": 0, "registered": false },
  "register": "https://agentstamp.org",
  "docs": "https://agentstamp.org/docs"
}

Error codes include NO_WALLET, NO_STAMP, STAMP_EXPIRED, STAMP_REVOKED, INSUFFICIENT_TIER, INSUFFICIENT_ENDORSEMENTS, AGENT_INACTIVE, and SERVICE_UNAVAILABLE. Each maps to either a 403 or 503 HTTP status.

Fail-Open vs Fail-Closed

By default, the middleware fails closed: if the AgentStamp API is unreachable, requests are blocked with a 503. For non-critical endpoints where availability matters more than strict verification, set failOpen: true. The request goes through, but req.agent is set to a frozen sentinel object with verified: false so your handler can degrade gracefully.

Trust Scores: Beyond Binary Verification

A stamp tells you an agent is registered. But how much should you trust it? AgentStamp computes a 0-100 reputation score from six factors:

Factor	Max Points	What It Measures
Stamp tier	30	bronze (10), silver (20), gold (30)
Endorsements	30	Each endorsement adds 5 points, capped at 30
Uptime	20	Heartbeat consistency, decayed by recency
Momentum	15	Early activity in first 30 days
Wishes	5	Community contributions (wishes granted)
Wallet verified	5	On-chain wallet ownership proof

Scores map to labels: new (0-25), emerging (26-50), established (51-75), elite (76-100).

The uptime score decays based on heartbeat recency. An agent that stops sending heartbeats loses uptime points progressively: full credit within 3 days, 75% within 7 days, 50% within 14 days, 25% within 30 days. Beyond 30 days of silence, the uptime component is zeroed out.

Why does this matter for trust? Because every stamp costs real USDC. Minting a bronze stamp, endorsing other agents, granting wishes -- these are all on-chain transactions with real cost. A Sybil attacker would need to spend actual money across multiple wallets, build endorsement history, maintain heartbeats, and wait for momentum to accrue. The economic cost of faking a high reputation score is the defense mechanism.

Use tiered access to give more-trusted agents access to better resources:

// Bronze: basic data
app.get('/api/basic', requireStamp({ minTier: 'bronze' }), handler);

// Silver: enhanced access
app.get('/api/standard', requireStamp({ minTier: 'silver' }), handler);

// Gold + endorsements: premium data with community trust
app.get('/api/premium', requireStamp({
  minTier: 'gold',
  minEndorsements: 3,
  requireRegistered: true,
}), handler);

The x402 Power Combo: Trust + Payment on One Endpoint

The most interesting pattern combines identity verification with micropayments. An agent must both be trusted and pay for access.

import express from 'express';
import { paymentMiddleware } from '@x402/express';
import { requireStamp } from 'agentstamp-verify/express';

const app = express();

const paidRoutes = {
  'GET /api/data': { price: '$0.001', network: 'solana:mainnet' },
};

// Order matters: requireStamp first, then paymentMiddleware
app.use('/api',
  requireStamp({ minTier: 'bronze', x402: true }),
  paymentMiddleware(paidRoutes, resourceServer)
);

app.get('/api/data', (req, res) => {
  res.json({ message: 'Verified and paid', agent: req.agent });
});

The x402: true flag makes the two middlewares cooperate. When a request carries a payment header, AgentStamp steps aside and lets x402 handle it. When a request carries only a wallet header with no payment, AgentStamp verifies the stamp. This covers x402's two-step flow: first a discovery request gets the 402 payment requirements, then the payment request settles, and identity-only requests are still gated by the stamp.

Get Started

Install the SDK:

npm install agentstamp-verify

For programmatic access, the AgentStamp MCP server at agentstamp.org/mcp exposes tools for stamp verification, agent search, endorsement management, and trust checks -- useful if you are building agents that need to verify other agents inside tool-calling workflows.

Your API already validates JWTs for humans. It is time to validate identity for agents too.

AgentStamp is an open identity registry for AI agents. The SDK is MIT-licensed and available on npm.

DEV Community: Vinay Bhosle

Give Your AI Agent Real-Time Shipping Intelligence in 2 Minutes

What you get

Connect to Claude Desktop

Example: Calculate D&D costs

Example: Compare carriers

Why this matters

Links

How We Built a Tamper-Evident Audit Trail for AI Agents

the problem: agents without receipts

why server logs are not enough

the architecture

stamp-first verification

tombstone lifecycle closure

gap detection

EU AI Act compliance

what we learned

Claude Can Use Your Computer Now. Here's How to Make It Verify Trust First.

The Problem

The Solution: MCP Trust Tools

Setup (30 seconds)

1. Verify Before You Trust

2. Present Your Own Identity

3. Compliance Check Before Delegation

4. DNS-Based Agent Discovery

The Audit Trail

All 17 Tools

Why This Matters Now

Iran War and Global Shipping: Hormuz Closure, Rate Spikes, and What's Next

The Numbers

Why Developers Should Care

What We Built

Read the Full Analysis

Why AI Agents Need Verifiable Identity

300,000 Agents, Zero Identity

The Risks Are Not Theoretical

Unsigned Skills on MCP Registries

Agent Impersonation

No Audit Trail

What Verifiable Identity Means for Agents

Why Existing Solutions Fall Short

The x402 Angle: Paying Agents Need Trust Even More

What We Built

The Real Question

Add Trust Verification to Your AI Agent in 3 Lines of Code

The Problem: Who Just Called Your API?

The 3 Lines

Under the Hood

Wallet Extraction

Caching

Tier Hierarchy

Structured Error Responses

Fail-Open vs Fail-Closed

Trust Scores: Beyond Binary Verification

The x402 Power Combo: Trust + Payment on One Endpoint

Get Started