Agent Security

What an agent could do on your site

Agent readiness asks what an agent can read. Agent Security asks a harder question: what it could harvest, what it could post, and what it could be talked into doing by content on the page.

What it is

Agent Security measures two different exposures, and it's worth keeping them apart.

Exposure to agents
What an agent arriving at your site could take or do: credentials left in page source, write surfaces with no visible anti-automation, sensitive files served by accident.
Exposure of agent visitors
What your pages could do to an agent reading them: hidden text, instructions planted in content, manifests that tell an agent to behave in a particular way. This half is the Adversarial Safety score that already appears on every report.

Why now

Through 2026, a pattern showed up repeatedly: credentials that had been sitting in public page source for years started being found and used at scale. Nothing about those sites changed. What changed is that reading every script on a page, on every site, stopped being expensive. A key in a JavaScript bundle has always been public; it is now reliably found.

The second pattern was write surfaces being used as message boards. Comment forms, review forms, and open registration flows — built for humans and lightly defended because the spam was manageable — turned out to be a convenient place to leave text for other agents to find. The submission volume that makes this worthwhile is much lower than the volume that makes spam worthwhile.

The third was content that steers agents. Text addressed to a machine rather than a person — instructions in a manifest, a paragraph hidden behind CSS, a comment written to be read by the next agent that visits — turned ordinary pages into instructions. A site can be the target of this, or unwittingly the host of it, and those need different fixes.

What we check

Seven groups. Every check is a plain GET request: we never submit a form, send credentials, fuzz parameters, follow a login flow, or run GraphQL introspection.

Write surfaces
Forms an agent could submit to — registration, comments, posts, uploads — and whether the page shows any anti-automation evidence at all: a CAPTCHA widget, a honeypot field, a CSRF token.
Exposed credentials
API keys and tokens left in HTML, inline scripts, embedded JSON, and same-origin JavaScript bundles. Evidence is always masked — we record the key's class and first few characters, never the value.
Sensitive paths
Whether well-known sensitive files are publicly readable. This group requires an authorized key plus your attestation that you own the site, and a finding needs matching content, not just a 200 response.
Agent access policy
What robots.txt says about training crawlers, search bots, and the user-triggered agent fetchers that act on your pages — plus content-usage signals, security.txt, and observable edge protection.
Agent-facing endpoints
Agent cards, MCP descriptors, and llms.txt: whether an advertised agent capability declares an authentication scheme, and whether the manifest itself contains instructions aimed at agents.
Transport and headers
HSTS, CSP, and the usual response headers. Weighted lightly on their own — a missing CSP matters more on a site that accepts user-submitted content.
Untrusted-content exposure
Whether third parties can write text onto pages that agents later read as part of the page — the mechanism behind agents leaving instructions for other agents.

Because the scan is passive, it reports what is observable and says so. Server-side rate limiting and bot scoring don't appear in markup, so a form with no visible protection is reported as no evidence found — not as unprotected.

What you get

  • A shareable report at an unguessable URL, with findings grouped by severity, masked evidence, and a specific fix for each one.
  • Both halves side by side: exposure to agents, and exposure of agent visitors.
  • Re-checks on request, so you can confirm a fix landed.

How access works

  1. Request a key. Use the form below. We review each request by hand.
  2. We issue a key by email. Keys are tied to a label, and can carry an expiry or a usage cap.
  3. Toggle it on when you scan. On the homepage scan form, switch on “Include Agent Security check” and paste your key. It travels only in the request body — never in a URL, never stored in your browser.
How do I get an Agent Security key?
Fill in the request form on this page with your name, work email, and the site you want checked. We review each request by hand and issue a key by email if it's a fit.
Why are security checks gated behind a key?
Agent readiness is safe to run against any public URL. Security checks look at write surfaces and, on the authorized tier, sensitive paths — so we only run them for people who can reasonably claim responsibility for the site.
How do I run a security scan once I have a key?
On the AgentLitmus homepage, switch on 'Include Agent Security check', paste your key, and confirm that you own the site or are authorized to assess it. The key travels only in the request body.
What is the difference between the passive and authorized tiers?
Both tiers are read-only. The passive tier fetches only pages your site links to and a fixed list of well-known files. The authorized tier additionally requests a short, fixed list of sensitive paths, and requires that you attest to owning the site.
Does a security scan ever submit forms or use credentials?
No. Every check is a plain GET request. We never submit a form, send credentials, fuzz parameters, follow a login flow, or run GraphQL introspection.

Request access

Tell us what you want checked and why. We read every request, and we'll say no if a site isn't yours to assess.

Agent Security — AgentLitmus