← All articles
Cloud Security 10 min read

AI Agents Finally Have Passports. That Does Not Give Them Visas.

AWS WAF can now cryptographically verify participating AI agents. Security teams still need to decide which verified bot may perform which action, on which route, at what rate.

CloudDefender Team ·

Listen to article

Narrated by Andy · 8:30

Download

The web’s bot-control model was built for an era when software announced itself with a user-agent string and tended to come from recognizable network ranges. AI agents break both assumptions. A consumer assistant may browse through shared infrastructure, rotate addresses, invoke a remote browser, and act for millions of different users. Blocking the platform blocks legitimate customers. Trusting the platform gives every customer of that platform the same privilege.

AWS’s July release of Web Bot Authentication for WAF Bot Control is an important answer to the identity problem. Participating agents can cryptographically sign HTTP requests. WAF verifies those signatures against public keys published in a signature directory, then attaches labels describing the bot, vendor, and—in supported cases—the account behind the request. Amazon Bedrock AgentCore Browser signs automatically. WAF Bot Control version 4 or later can classify the traffic, and version 5 expands the managed catalog to more than 650 bots.

For defenders, this is the moment automated traffic begins to acquire something like a passport. But a valid passport says who presented it. It does not say whether that identity may scrape a catalog, change an address, submit a claim, or buy 800 concert tickets. Authentication is evidence for an authorization decision, not the decision itself.

A verified bot still passes through policySigned requestkey · account · expiryWAF verificationidentity labelsRoute policyaction · rate · contextAllow / challengelogged outcomeDecision recordsignature result · bot account · URI · method · user session · rate · rule versionIdentity reduces uncertainty. It does not erase application-level abuse.
Web Bot Authentication establishes a principal; application and WAF policy still determine the principal’s permitted behavior.

Why IP reputation is no longer enough

IP intelligence remains useful for compromised hosts and crude automation, but it is a poor identity primitive for multi-tenant agents. One address can represent thousands of unrelated users. Reverse DNS can say which platform operates a network, not which customer initiated a request. User-agent strings are cheap to copy. Allowlisting any of those signals gives an attacker a large impersonation surface.

Web Bot Authentication uses HTTP Message Signatures, standardized in RFC 9421, so a receiver can validate selected components of the request and the signer can bind the signature to an expiry. WAF classifies the result as verified, invalid, expired, or unknown and emits granular labels. That turns “this resembles Vendor X” into “this request was signed by a key Vendor X currently publishes.”

The advance is real, but bounded. A key can be stolen. A participating vendor can misclassify an account. A legitimate user can instruct a legitimate agent to perform abuse. Signed traffic can also be replayed if implementations and downstream controls mishandle validity windows. Identity raises the cost of impersonation; it does not make the represented actor benevolent.

Do not make verified synonymous with allowed

AWS changed the managed Bot Control behavior so verified AI traffic is not automatically blocked by the Category:AI and token-absent rules. That is a sensible default for preventing newly authenticated traffic from being caught by broad bot categories. It is not a recommendation to bypass every custom control.

Build a route matrix. Public read-only pages may allow verified agents at a rate substantially above unknown bots. Search endpoints may require tighter query budgets because one request can trigger expensive downstream work. Login, checkout, password reset, account recovery, benefit applications, and inventory reservation should continue to require the same user authentication, anti-automation, and fraud controls applied to interactive browsers.

Then decide at the account level where labels permit it. An enterprise customer may register an approved agent account for procurement workflows. That account can receive a narrowly scoped policy without granting identical access to every user of the agent vendor. Where account identity is unavailable, treat the vendor label as a weaker signal and keep privileges correspondingly broad but shallow.

Bind the bot to the human session

The hardest abuse cases sit above WAF. A verified agent can carry a valid site session belonging to a real person and still take an action the person did not understand. Sensitive applications need delegation semantics: what the user authorized, for how long, against which resource, and with what transaction ceiling.

Until an application has a formal delegation model, require step-up confirmation for consequential writes. An agent may assemble a cart, compare insurance plans, or draft a transfer; the user should confirm the final purchase, enrollment, or payment through a trusted channel. Record both identities—the agent principal and the user principal—rather than collapsing the request into the user’s session.

This is also where authorization policy becomes intelligible to customers. “Automated access permitted” is too vague. State whether an agent can read, prepare, submit, or approve, and expose revocation. A customer should be able to see and terminate active agent connections as readily as connected applications.

Make signature failure operational

An invalid or expired signature is a security signal, not merely a reason to fall back to generic bot handling. It may indicate clock drift, a vendor rotation error, a damaged intermediary, replay, or impersonation. Alert on changes in failure rate by claimed bot and route. Preserve the signature-result label, key identifier, covered request components, expiry, source network, method, and URI in security logs.

Unknown is different from invalid. Unknown agents may be legitimate software that has not joined the ecosystem, so the policy can challenge or rate-limit rather than categorically block. An invalid signature from a bot claiming a known identity deserves stricter treatment because the sender attempted a verifiable assertion and failed it.

Key lifecycle deserves a runbook. Monitor directory availability and staleness, understand caching behavior, rehearse vendor key rotation, and decide how long a previously valid key remains acceptable. A fail-open policy protects availability but increases impersonation risk; fail-closed protects identity-sensitive routes but may block a vendor during an outage. The answer can differ by route.

Defend the application economics

Authenticated agent traffic can be legitimate and financially destructive at the same time. An agent that executes hundreds of product comparisons may amplify database, search, and model-inference costs. Establish budgets in units the application understands: searches per account, expensive queries per minute, checkout attempts per user, and concurrency per workflow.

Rate limits should incorporate identity but not depend on it exclusively. Apply a vendor-level ceiling, an agent-account ceiling where available, a human-account ceiling, and endpoint-specific cost weights. This layered model prevents one compromised account from consuming the vendor’s full allowance and stops a vendor-wide surge from overwhelming the service.

The AI Activity Dashboard can help establish a baseline, but dashboards are retrospective. Put the critical limits in enforceable WAF and application rules and test them under burst conditions.

A safe 30-day rollout

Begin in count mode. Upgrade Bot Control deliberately, capture the new labels, and measure which existing rules would change behavior. Inventory routes by consequence and computational cost, then create the identity-and-action matrix before allowing anything new.

In the second week, permit verified traffic only on low-risk read routes and compare completion, error, and abuse rates with human traffic. In the third, add account-specific policies for known partners and test invalid, expired, missing, and replay-like requests. In the fourth, enable a small set of delegated write flows with step-up confirmation and explicit rollback.

Success is not a higher volume of agent requests. It is a lower false-block rate for legitimate automation without an increase in fraud, resource exhaustion, account takeover, or unexplained writes. Track all five.

The durable boundary

The web needs stronger machine identity, and cryptographic request verification is a better foundation than a string and an address. The danger is organizational relief: once a control displays a green “verified” label, every downstream team is tempted to stop asking what was verified.

Treat the label as the beginning of policy. The bot has presented a passport. Your application still controls the border, the visa, and every action after entry.

Sources and reporting notes


CloudDefender helps teams see the identity, route, exposure, and control context around internet-facing resources—so a verified automated caller receives precisely the access its workflow requires, and no more.

CloudDefender

Defend your cloud. Continuously.

CloudDefender Suite gives security teams continuous posture management, threat detection, and compliance automation across AWS, Azure, and GCP — with zero false-positive fatigue.

Try CloudDefender →