You can tell whether an AI agent filled in your form by looking at three things: whether the request carries a verified signature from the agent's operator (Web Bot Auth), whether the page reported that an agent submitted it (WebMCP), and whether the browser itself was automated. Only the first is proof. The other two are strong evidence, and together they separate four kinds of sender: a person, an agent driving a browser, a verified agent, and a bot.
Why does it matter who filled in the form?
Assistants that act in a browser are no longer a demo. People ask them to find a plumber and request a quote, book a table for Friday, or send the same question to five agencies. Each of those ends in a form submission that looks exactly like one typed by hand.
The difference shows up after the form. A person who asked an assistant to send ten quote requests is shopping, not committed. A reply sent to the address on the form may be read by the assistant first. And a sales team that treats every submission as a warm lead will spend the afternoon calling people who never saw the form at all. None of that makes agent submissions bad. It makes them a different kind of lead, which is worth knowing before you act on it.
What are the four kinds of sender?
- Human: a person in an ordinary browser, typing.
- Browser agent: an AI assistant operating a browser for someone. The page may report it through WebMCP, the browser may be under automation, or the assistant may name itself in its user agent.
- Verified AI agent: an agent that signed the request with a key its operator publishes. You know which company runs it, not just that it claims to be an agent.
- Bot: no browser at all (a script or a crawler), or a sender that fell into a spam trap such as a honeypot field.
What can actually be proven?
A user agent string is a label the sender chooses. Anything can claim to be ChatGPT, and anything can claim to be Chrome. That is why the only tag worth calling verified is one backed by a signature.
Web Bot Auth, a proposed standard several large operators already use, works like this: the agent signs each HTTP request with a private key, names its domain in a Signature-Agent header, and publishes the matching public key at a well-known address on that domain. The receiving site fetches the key, rebuilds the signed parts of the request (at minimum the host it was sent to), and checks the signature and its short validity window. A pass means the request came from whoever controls that domain's keys. A forged or replayed request fails.
POST /wft_your_key HTTP/1.1
Host: send.webforms.to
Signature-Agent: sig1="https://agent.example.com"
Signature-Input: sig1=("@authority" "signature-agent";key="sig1");created=1794330000;expires=1794330060;keyid="poqk...";tag="web-bot-auth"
Signature: sig1=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZDsi6nJKuHxUi/5Syp3rLWBA==:Everything short of a signature is a careful reading of signals the sender controls. That is still useful, as long as the label says so. A good tool shows you which signals decided each tag, so you can disagree with it.
How do you spot an agent that does not sign?
Three signals do most of the work. First, WebMCP: when a page marks up its form for AI agents, the browser tells the page whether an agent submitted it, and a small script can pass that along with the submission. Second, automation: browsers driven by automation tools announce it through navigator.webdriver, and headless browsers often name themselves. Third, the user agent: several assistants add their product name when they act for a user.
Bots are the easier case. A request with no browser behind it (curl, a Python library, a crawler) or one that filled a hidden honeypot field is not a person and not an assistant acting for one. Note that your own server posting to the form from a backend is also, correctly, not a browser.
What should you do with each kind?
Treat origin as routing information, not as a spam verdict. A few patterns that work:
- Send verified and browser agent submissions to their own channel, where someone checks intent before a salesperson calls.
- Keep agent bookings out of your CRM until a human confirms, so pipeline numbers stay honest.
- Reply to agent submissions with something an assistant can act on: a clear next step and a link, rather than "we will be in touch".
- Keep spam filtering independent. Origin tells you who sent it; the spam check tells you whether it is worth reading.
How WebForms tags submissions
WebForms tags every submission with one of the four kinds, on every plan, with nothing to set up. Signed requests are verified against the operator's published keys and tagged with the operator's domain, such as chatgpt.com. The inbox shows the tag and the reasons behind it, and an AI agents tab lists only agent submissions.
The tag is also data you can act on. In a routing rule, the field _meta.sender holds human, browser_agent, verified_agent or bot, and _meta.agent holds the agent when one is known. Webhooks, the Submissions API and the MCP tools carry the same two values.
{
"name": "AI agents to #bookings",
"conditions": [
{ "field": "_meta.sender", "op": "in", "value": ["browser_agent", "verified_agent"] }
],
"integrationIds": ["int_slack_bookings"]
}