StormView

The clearest AI signal this week was not a new model release. It was a security scan.

Hard2bit published its AI Agent Readiness 2026 report on June 6 after scanning 60 large European company and agency domains. Fifty-nine scans completed. Across those 59 domains, adoption of 11 emerging agent-readiness signals was exactly zero.

No llms.txt. No API Catalog. No OAuth Protected Resource metadata. No MCP Server Cards. No Agent Skills. No Web Bot Auth. The only control with real uptake was defensive bot policy in robots.txt, found on 28 of 59 domains.

That gap matters because AI agents are starting to move from chat windows into workflows. They read product pages, compare services, retrieve documents, call APIs, and trigger actions. But most websites and API estates still give them no clean map, no declared boundaries, and no reliable way to prove who is calling what.

We have seen this pattern before. A business wants agents to help with sales, support, procurement, or operations, then discovers the agent has to scrape half-broken pages, guess which documentation is current, and work around APIs that were designed only for internal developers. That is not autonomy. That is brittle automation wearing better clothes.

Agent readiness is the missing layer between public web presence, API design, and security.

The basics are not exotic. An llms.txt file can point trusted AI systems to the best version of your public information: services, policies, pricing notes, support pages, and documentation. RFC 9727 API Catalog gives software a standard way to find public APIs. RFC 9728 helps protected resources declare the OAuth metadata needed before access happens. MCP Server Cards and Agent Skills describe what tools can do. Web Bot Auth gives bot traffic a path toward signed identity instead of anonymous scraping.

None of those controls means "let every agent in". That would be reckless. The better move is selective readiness.

Start with the domain. Decide which AI crawlers you want to allow, block, or throttle, then make that visible in robots.txt and supporting policy pages. Publish a small llms.txt that reflects what you actually want machines to read. Clean the sitemap. Remove dead documentation paths. Make sure service pages say something useful rather than polished fog.

Then move inward. Inventory the APIs an agent might need. Split read-only actions from write actions. Put anything operational behind identity, least privilege, rate limits, and logging. If you expose MCP tools, treat them like privileged infrastructure. Each tool needs a named owner, a narrow scope, and audit records that tie actions back to a human, service account, or approved agent.

This is why the Linx Security announcement on June 9 landed at the right moment. Their Agentic Access Control pitch frames MCP governance as an inline enforcement problem: policy before tool execution, controls down to the individual tool, and logs mapped to identity. JFrog and Anthropic pointed the same way on June 10 with a Claude Code plugin focused on verified MCP servers and Agent Skills for software supply chain governance.

That is where the practical work is going. Not bigger prompts. Not more unchecked autonomy.

For mid-market companies, the first useful agent project may be a readiness audit: scan the site, publish the minimum machine-readable map, document the APIs, and put every tool surface behind policy. The companies that do this in 2026 will give trusted agents something far better than access. They will give them a controlled path to do real work.