We now watch agentic security threats for you

Why security belongs in agent readiness

When a site publishes something for AI agents, it is publishing instructions a machine will act on without a person checking first. A server for agents, a sign-in setup for that server, a card that tells other agents where to reach you, a key that proves your bots are yours: each one is a door, and each one can be left open by accident.

These technologies are new, and most teams adopting them are learning as they go. The mistakes we see are rarely exotic. A signing key published with its private half. A sign-in address on plain http. An example key copied from a specification into production, where anyone who has read that document can sign as you. None of these breaks the page, so nothing on the site looks wrong. The first sign is often that someone else noticed.

Beyond the specification

Until now our checks answered one question: does what you published follow the rules of the protocol it belongs to? We track those specifications as they change and re-check our rules against each revision.

Following the rules is necessary, but it is not the same as being safe. Attacks on agent protocols are published every month, by researchers, by security firms and by the protocol authors themselves. So we now follow that threat landscape the same way we follow the specifications: we read it, decide which threats show up in what a site publishes, and turn those into checks.

47 of our 168 checks now look for security faults, across 12 agent technologies, and that list grows as the threats do.

What we look for

The checks fall into a few plain groups:

• Keys that should never be public. Private or shared signing keys in a published key set, and well-known example keys from the specifications, whose private halves anyone can read.
• Sign-in and transport. Sign-in and agent addresses published on plain http, sign-in settings a careful agent must refuse, and weak or outdated sign-in methods.
• Identity that does not add up. Metadata that names a different server from the one it came from, or a schema served from a host that does not own its name.
• Things that should stay inside. Internal addresses and credentials published in files meant for the whole internet.

Each finding says what is wrong, why it matters and how to fix it, names the source behind it, and maps to the security frameworks your security team already uses: OWASP Agentic Top 10 (2026), OWASP MCP Top 10 (2025 beta), OWASP API Security (2023), MITRE ATLAS (2026.09), CoSAI MCP Security (Jan 2026), OWASP ASVS (5.0.0), plus the CWE list of weakness types.

How we do it, and what we will not do

We only look at what a site publishes: its pages, its headers and the files it offers to agents. We never sign in, call a tool, start a payment or send anything designed to break a site. If proving a threat would need any of that, we say so rather than test it.

When we find something sensitive, we name the fault, never the value. A leaked key is described by type, not printed, and credentials in addresses are hidden from every report and log. The fix always includes rotating what was exposed, because a key that has been public is already in someone's copy of the web.

We also check for issues, never for absence. A site that has not adopted a technology is not marked down for it. We report the sites that tried and got something wrong.

An honest limit. These checks are new, and we have not yet measured how often each one is wrong. Until we have, we label them provisional. A clean result means we found none of the faults we look for in what you publish. It is not a security audit or a penetration test.

Our commitment

Businesses are moving into a new kind of web, where software agents read, decide and act on their behalf. That move should be a safe one. Our aim is to be a resource you can trust through it: one that follows the specifications and the threats for you, tells you plainly what it found and what it could not see, and never cries wolf to look busy.

Our full method, including every kind of request the scanner makes and how we handle anything sensitive we find, is in our documentation. If you think a finding is wrong, or you have found an exposure, tell us through our contact page.