Attestari

Pre-launchContinuous trust ratings for AI agents and MCP servers

Every AI agent, re-tested on every release.

Registries check a service once, when it is listed, and never look again. Attestari runs each service in a sandbox, watches every outbound packet, plants a canary in every run, and grades it again each time the service changes.

Join the waitlistHow it works ↓

Ratings free and public · Vendors never pay

Sample report

Illustrative · not a real service

mailship-mcp

v2.4.1

  • Capability
  • Integrity
  • Stability
  • Provenance
  • Conduct

Letter grade

capped by Conduct

C

Canary hits
0
Re-test
every release
Sample report card for an invented service, shown to illustrate the report format. No real service has been rated.

The problem

Verified once. Trusted forever.

Buyers cannot tell which of these are safe.

  • 80,000+

    MCP servers indexed across public registries.

  • Thousands

    of companies claiming “agentic AI.”

  • ~130

    of those that are estimated to be real.

    Source: Gartner estimate

Every existing registry verifies a service once, at listing time.

That check is worth little, because the documented attack does not happen at listing time. It happens later: a package that is already trusted and already adopted turns malicious in a subsequent release, and passes every static check on the way in. Nobody re-runs the test, because the test was already passed.

The rug pull

postmark-mcp · npm · Sept 2025

In September 2025 a package called postmark-mcp was live on npm. A third-party developer had published it. It had no connection to Postmark, the email company, whose integration it mirrored. Earlier versions did what they said. Then version 1.0.16 quietly added a hidden BCC to every email it sent, copying each message to an address the package author controlled.

It installed cleanly, ran normally, and shipped as a routine update. It stayed live and in use until it was pulled in late September 2025. Every static check passed the entire time.

The fault was the package author’s. Postmark did nothing wrong; its name was borrowed.

Source: Snyk, “Malicious MCP Server on npm postmark-mcp Harvests Emails” · Postmark’s own notice

Five axes

Independent · never averaged

Five readings. No composite score.

A single number hides the thing you need to know. A service can be excellent at its job and still be the one that leaks your data. So each axis is measured on its own, reported on its own, and never blended into the others.

Readings shown: mailship-mcp · sample report · illustrative

  1. Capability

    Does it do what it claims? Measured on tasks the service has not seen before, so a vendor cannot train to the test.

  2. Integrity

    Does it touch only what it was given? Every outbound packet from the sandbox is watched. Every run carries a unique canary token. A canary seen leaving the sandbox is a hard fact, not a judgment.

  3. Stability

    Does the same input produce the same behavior? Across repeated runs, and across releases. A service that behaves differently on Tuesday is a service you cannot plan around.

  4. Provenance

    Who built it, who signs it, and has that changed? Maintainer identity, signing keys, build reproducibility, and whether any of it moved between releases.

  5. Conduct

    When it can't, does it say so, or does it make something up? Refusing honestly versus fabricating. This axis predicts real-world damage better than Capability does. A capable service that invents answers is more dangerous than a weak one that admits its limits.

Drift

The check that never ends

A rating is only true until the next release.

So we do not stop at the first one. Every release is run again in the sandbox, against the same tests and a fresh canary. The grade on the page is the grade of the build that is shipping today, not the build that was listed.

Grade history · atlas-geo-agent

Illustrative · invented service

Illustrative grade history for an invented service, atlas-geo-agentThe service holds an A grade across seven releases from January to July, then drops to F in a single point release in August when a canary token is observed leaving the sandbox. A row beneath the chart shows that static checks passed on every one of the eight releases, including the one that failed.ABCDFJanv3.0.0Febv3.0.2Marv3.1.0Aprv3.1.1Mayv3.1.2Junv3.2.0Julv3.2.1Augv3.2.2v3.2.2CANARY SEEN IN OUTBOUND TRAFFICHARD CAP → FSTATICCHECKSPASSPASSPASSPASSPASSPASSPASSPASS

Static checks passed the entire time.

Seven releases at A. One point release to F.

  • Sandbox

    Every service runs in isolation with nothing it was not explicitly given. Whatever it does, it does where we can see it.

  • Every packet

    All outbound traffic from the sandbox is captured and attributed. Destination, timing, and size are part of the record.

  • Canary tokens

    Each run is seeded with unique tokens that have no legitimate reason to leave. If one appears anywhere else, the question is answered.

  • Behavior diff

    Each release is compared with the last. A change in what the service reaches for, not just what it says, raises an alert.

Independence

Revenue from the buyers of trust, never its subjects

Vendors never pay.

The rated service pays

  • Nothing for a rating. Every service in scope is tested whether or not it asked to be.
  • Nothing for a badge. There is no premium tier, no verified checkmark, no featured placement.
  • Nothing for removal. A grade cannot be bought down or bought off the page.

Ratings are free and public. A rating service that is paid by the rated is not a rating service.

Who pays instead

  • Runtime API. Check a service’s current grade before your agent hands it a task, in the request path, at machine speed.
  • Enterprise monitoring. Watch the services you already depend on and get the alert before the incident report.
  • Data licensing. The full history, the raw readings, and the packet-level evidence behind every grade.

All three are paid for by people deciding whether to trust a service. None are paid for by the service.

7 days’ notice

Every rated party is told before a negative grade publishes. Seven days, with the evidence, so a real bug can be fixed and a real dispute can be made.

Reply published

Their reply is published alongside the grade. Unedited, at the same size, on the same page. The reader sees both.

Re-test on request

A fixed release is re-run like any other. The grade follows the build. There is nothing to negotiate, only something to ship.

Waitlist

Pre-launch

Be there when the first grades publish.

No service has been rated yet. Leave an address and we will write once, when there is something to read: the first public reports, and early access to the runtime API for teams that want a grade in the request path.

One address, one notification. No newsletter. Remove yourself by replying to the message we send.