On-Chain Trust: How EAS Attestations Make AI Agent Certifications Verifiable

When an AI agent connects to an MCP server for the first time, it has no reliable way to verify whether that server has been audited, certified, or reviewed by anyone. The agent simply connects and hopes for the best. This is the trust-on-first-use problem, and it is one of the most significant unsolved challenges in the agentic AI ecosystem.

CraftedTrust solves this by anchoring every certification as an on-chain attestation using the Ethereum Attestation Service (EAS) on Base. The result: any person, system, or AI agent can independently verify a server's certification status without trusting a single API or centralized authority.

The Problem with Traditional Certifications

Today, certifications in cybersecurity and software compliance are delivered as PDFs, email confirmations, or self-reported badges on a website. These formats share a common weakness: they are trivially forgeable and impossible to verify programmatically.

Consider what happens when an enterprise wants to confirm that a vendor holds a SOC 2 report. Someone sends an email. Someone else forwards a PDF. A compliance analyst eyeballs it and checks a box in a spreadsheet. The entire chain of trust depends on manual human processes, and none of it is machine-readable.

Now scale that problem to AI agents. An autonomous agent deciding which MCP server to connect to cannot read a PDF. It cannot call a vendor's compliance team. It needs a trust signal that is structured, permanent, and verifiable in milliseconds. Traditional certifications were never designed for this world.

"If a certification cannot be verified by a machine, it does not exist in the agentic world."

What Is EAS?

The Ethereum Attestation Service (EAS) is an open-source, on-chain attestation framework. It allows anyone to make structured, cryptographically signed claims about anything - and store those claims on Ethereum (or an Ethereum L2) so they can be independently verified by anyone else.

An EAS attestation consists of three key components:

• Schema: A predefined structure that describes what the attestation contains - similar to a database table definition. CraftedTrust's schema includes fields for the server name, trust score, certification tier, compliance mappings, and timestamp.
• Attester: The Ethereum address that creates and signs the attestation. In CraftedTrust's case, this is our platform's verified wallet address, which serves as the root of trust.
• Attestation data: The actual claim being made - for example, that a specific MCP server achieved a trust score of 87 and passed certification on a given date, with mappings to CoSAI, OWASP, and NIST frameworks.

EAS attestations are not tokens. They are not NFTs. They are purpose-built data structures designed for making verifiable claims, and they are composable - meaning other attestations can reference them, building layered trust graphs over time.

Why Base?

CraftedTrust deploys its attestations on Base, the Ethereum Layer 2 built by Coinbase. The decision was driven by three factors:

• Low gas fees: Creating an attestation on Base costs fractions of a cent, making it economically viable to attest every certification without passing costs to server maintainers.
• Ethereum security: Base inherits the security guarantees of Ethereum mainnet. Attestations settled on Base are backed by the same validator set and finality model as Ethereum itself.
• Ecosystem alignment: Base is the native chain for Coinbase's USDC infrastructure, which aligns with CraftedTrust's use of USDC for certification payments and x402 micropayments. Agents operating in the Coinbase ecosystem can verify trust and pay for services on the same chain.

How CraftedTrust Uses EAS

When an MCP server passes the CraftedTrust certification process - completing our 12-factor trust assessment and manual review - the platform creates an EAS attestation on Base. This attestation is a permanent, immutable record that contains:

• The server's unique identifier and name
• The overall trust score at the time of certification
• The certification tier and review scope
• Compliance framework mappings included with the certification
• The certification timestamp and expiration date
• A content hash linking to the full assessment report

The attestation is created from CraftedTrust's verified attester address, which is publicly documented. Anyone can look up the attestation on the EAS explorer for Base and confirm its authenticity without contacting CraftedTrust at all.

If a certification is revoked - for example, if a server is found to have introduced a vulnerability after certification - CraftedTrust revokes the on-chain attestation. The revocation is also permanent and publicly visible, ensuring that stale certifications cannot be used to misrepresent a server's status.

Agent-Verifiable Trust

The real power of on-chain attestations emerges when AI agents consume them programmatically. Today, most agent-to-server connections operate on a trust-on-first-use model: the agent connects, and the developer hopes the server is safe. There is no verification step.

With CraftedTrust's EAS attestations, an agent can verify a server's certification before establishing a connection. The verification flow works like this:

1. The agent receives an MCP server URI it has not connected to before.
2. The agent queries the CraftedTrust API (or reads the Base chain directly) to check whether a valid, non-revoked attestation exists for that server.
3. If an attestation exists, the agent inspects the trust score, certification tier, and compliance mappings to determine whether the server meets its policy requirements.
4. If the attestation meets the agent's trust threshold, the connection proceeds. If not, the agent refuses the connection and logs the reason.

This entire flow happens in milliseconds. No human is involved. No PDF is opened. The trust decision is fully automated, cryptographically backed, and auditable after the fact.

Trust Gating in Practice

We have published a reference implementation showing how agents can consume CraftedTrust attestations as trust gates. The trust-gated-agent repository demonstrates an agent that:

• Reads a list of candidate MCP servers from a configuration file
• Queries the CraftedTrust attestation registry for each server
• Filters out any server that lacks a valid attestation or falls below a configurable trust score threshold
• Connects only to verified servers and logs the attestation UIDs for audit purposes

The implementation is intentionally minimal - under 200 lines of TypeScript - to show that trust gating is not a heavy lift. It is a pattern that any agent framework can adopt with minimal integration effort.

// Verify attestation before connecting
const attestation = await craftedTrust.getAttestation(serverUri);

if (!attestation || attestation.revoked) {
  logger.warn(`No valid attestation for ${serverUri}. Refusing connection.`);
  return null;
}

if (attestation.trustScore < policy.minimumTrustScore) {
  logger.warn(`Trust score ${attestation.trustScore} below threshold ${policy.minimumTrustScore}.`);
  return null;
}

// Attestation valid - proceed with connection
const client = await connectToMcpServer(serverUri);
logger.info(`Connected to ${serverUri} (attestation: ${attestation.uid})`);

Why This Is a Unique Differentiator

No other MCP trust platform has on-chain verification. The existing approaches to MCP server trust fall into three categories, and all of them have significant limitations:

• Registry-based trust: Some platforms maintain curated lists of "approved" servers. These lists are centralized, opaque, and offer no way for an agent to independently verify the approval criteria or current status.
• Reputation scoring: Other platforms compute reputation scores based on community signals. These scores are useful but ephemeral - they exist only in the platform's database and disappear if the platform goes offline.
• Self-reported badges: Server maintainers can claim compliance with various frameworks by adding badges to their documentation. There is no independent verification, and the badges are trivially forgeable.

CraftedTrust's on-chain attestations eliminate these weaknesses. The attestation exists on a public blockchain, independent of CraftedTrust's infrastructure. Even if CraftedTrust's servers went offline tomorrow, every attestation ever created would remain verifiable on Base. The attester address is public and immutable, so the provenance of every certification can be traced back to CraftedTrust's verified identity.

This is not blockchain for blockchain's sake. It is the only architecture that satisfies a specific and critical requirement: trust verification must not depend on the continued availability or honesty of a single centralized party. For AI agents making autonomous decisions about which servers to connect to, this property is not optional - it is foundational.

Explore CraftedTrust

On-chain attestations are live today for all CraftedTrust certifications. Every certified MCP server has a permanent, verifiable record on Base that any agent can query before connecting.

If you are building AI agents and want to integrate trust gating, start with the trust-gated-agent reference implementation. If you maintain an MCP server and want to earn a verifiable certification, start at CraftedTrust Platform and follow the registry and certification workflow from there.

Trust in the agentic world needs to be machine-readable, independently verifiable, and permanent. EAS attestations on Base deliver all three. Explore CraftedTrust Platform to see how on-chain trust connects with registry, certification, and governance workflows.