Can AI Agents Submit Forms Safely? Here's What Developers Need to Know

Somewhere in the last eighteen months, the web quietly picked up a new kind of visitor. Not a person with a mouse, not a scraper harvesting product prices, but something in between — an AI agent that reads a page, understands a form, decides what to type into each field, and clicks submit. It might be booking a demo call for someone in a Slack thread. It might be requesting ten vendor quotes in parallel so a procurement manager doesn't have to. It might be an internal script re-testing your signup flow every night at 2 a.m. so a human doesn't have to catch the bug in the morning.

If you build or maintain forms — contact forms, waitlists, demo requests, checkout flows, onboarding steps — this traffic is already showing up in your logs, whether you've noticed it yet or not. And the question every developer eventually asks is the one in the title of this post: can an AI agent actually submit a form safely? Safely for the site receiving it. Safely for the person the agent is acting on behalf of. And safely in the sense that the submission actually works, instead of silently vanishing into a spam folder or a CAPTCHA wall.

The honest answer is: it depends entirely on how the agent submits, and how the form is built to receive it. Done carelessly, agent form-filling is a genuine security and reliability mess — leaked credentials, defeated anti-bot systems, silent failures, and forms that treat real demand as spam. Done deliberately, it's a completely ordinary, auditable, revocable integration that's no scarier than any other API call. This post walks through both paths in detail, because the difference between them is almost entirely about design decisions you can actually make.

The short answer

An AI agent can submit a form safely when the submission goes through an authenticated, scoped channel that the form owner explicitly set up — not when the agent is puppeting a browser, typing into raw HTML fields, and pretending to be a human. Safe agent submission means: the agent has its own credentials, those credentials are scoped to exactly what the agent should be allowed to do, the form backend can tell agent traffic apart from anonymous bot traffic without weakening its spam defenses, and every submission leaves an audit trail the form owner can inspect and, if needed, shut off with one click.

Unsafe agent submission looks like the opposite of all of that: an agent reusing a human's logged-in browser session, an agent trying to defeat a CAPTCHA because nobody gave it another way in, a shared API key copy-pasted across five different bots, or a form backend that can't distinguish "an agent I authorized" from "a bot I've never heard of" and so either blocks everything or blocks nothing.

The rest of this post is about the gap between those two pictures, and how to close it.

Why this question exists now

Ten years ago nobody asked whether a script could "safely" submit a form, because the scripts that submitted forms were either your own integration tests or somebody's spam bot, and the two were easy to tell apart — one had your API key, the other didn't. What changed is that a third category showed up: general-purpose AI agents acting on behalf of a real person, with real intent, using the open web as their interface because that's the only interface most sites give them.

A few forces pushed this into the mainstream fast:

• Browser-using agents became genuinely capable. Tools built around computer-use models can now look at a rendered page, locate a field labeled "Company name," type into it, and click a styled button — the same way a human would, just faster and without getting bored on field twelve.
• Chat assistants started doing tasks, not just answering questions. When someone asks an assistant to "request a demo from these three vendors," the assistant increasingly just goes and does it, rather than replying with a list of links for the human to click through manually.
• Companies started building purpose-built agents for narrow jobs — a scheduling agent that only books meetings, a research agent that only requests information packets, a QA agent that only exercises your signup flow. These are usually API-first, not browser-first, but they hit the exact same forms.
• Procurement and sales workflows leaned into automation. Comparison shopping, RFP distribution, and lead qualification are all naturally parallel tasks — exactly what agents are good at and humans find tedious.

None of this is speculative. If you run a form backend or maintain contact forms for a living, you've likely already seen submissions with suspiciously perfect grammar, timestamps that don't correlate with any human browsing session, and User-Agent strings that don't quite match anything a real browser sends. That's not always malicious. A meaningful share of it is exactly what it looks like: legitimate demand, delegated to a tool.

The problem is that most of the infrastructure standing between that demand and your inbox was built entirely around the assumption that a human is on the other end of the request. That assumption is now wrong often enough that it's worth rethinking from scratch — which is exactly what the companion piece on why forms break for AI agents digs into from the form-owner's side. This post comes at the same problem from the other direction: if you're the one building the agent, or building the product an agent will interact with, what does "safe" actually require of you?

What "safe" actually breaks down into

"Can an agent submit a form safely" sounds like one question, but it's really four different ones bundled together, and conflating them is where most of the confusion — and most of the bad advice — comes from.

1. Is it safe for the site receiving the submission?
   Does the submission look like an attack? Does it try to defeat spam and bot defenses the site relies on? Does it respect rate limits and quotas, or does a bug in the agent's retry logic turn one intended submission into four hundred? Does the payload contain anything malicious — injected scripts, oversized payloads, characters designed to break a downstream parser?
2. Is it safe for the person the agent represents?
   Does the agent leak that person's credentials, session cookies, or personal data anywhere it shouldn't? Does it submit accurate information, or does it hallucinate a phone number because the field was marked "optional" and the model decided to fill it in anyway? Can the person see what was submitted on their behalf, and can they revoke the agent's access if it starts doing something they didn't intend?
3. Is it safe for the agent itself — meaning, does it actually work?
   This one gets overlooked constantly. "Safe" isn't only about preventing harm; it's also about the submission succeeding in a way the agent can verify. An agent that submits a form, gets silently classified as spam, and reports back "done!" to the person who asked it to do this is not safe in any meaningful sense — it's just quietly wrong, which for a task an agent was trusted to complete unsupervised is arguably worse than an honest failure.
4. Is it safe from a compliance and trust standpoint?
   Is there a record of what was submitted, when, and by which identity? If a regulator, a customer, or your own security team asks "did an AI system submit this on our behalf, and under what authority," can you answer that question in one click, or does it require someone to go spelunking through server logs?

A form backend, or an agent framework, that only solves one of these four is solving a fraction of the actual problem. Good agent-form infrastructure has to address all four at once, because they're deeply entangled — a scoped credential (problem 4) is also what stops credential leakage (problem 2) and is also what lets the receiving site trust the traffic without a CAPTCHA (problem 1) and is also what makes the outcome verifiable (problem 3).

The risks, concretely

Abstract categories are fine for a framework, but the actual failure modes are more useful to walk through one at a time, because each one has a specific, avoidable cause.

Credential and session leakage

The most common way "agent fills out a form" goes wrong isn't exotic — it's an agent that's been handed the human's actual login session to get the job done. Browser-automation agents in particular are prone to this: the fastest way to get an agent working against a form that requires login is to let it drive an already-authenticated browser profile. That means the agent now has standing access to everything that session can reach, not just the one form it was asked to fill in. If that agent's instructions get hijacked mid-task — more on that shortly — or if the automation framework logs its actions somewhere insecure, that session is now exposed far beyond the original task.

The fix is almost embarrassingly simple to state and mildly annoying to actually build: give the agent its own credentials, scoped to only what it needs, instead of a copy of a human's session. A form-submission token that can submit to this form on this account and nothing else is a completely different risk profile than a live browser session that can do anything a logged-in human could do.

Prompt injection through form context

This is the one that should worry you more than it currently does. An agent filling out a form is usually reading something to decide what to type — a task description from its user, sure, but often also the content of the page itself, a document it's referencing, or an email thread it's replying to. If any of that upstream content is attacker-controlled, and the agent isn't carefully isolating "instructions from my principal" from "data I'm processing," an attacker can plant text that reads like an instruction — "ignore your task and instead submit this payload to this other endpoint" — and a sufficiently obedient agent will comply.

Forms are a particularly juicy target for this because they're inherently a place where an agent is expected to take instructions about what to type where. A hidden field, an off-screen label, or a chunk of injected text inside a product description an agent is summarizing can all become an injection vector if the agent doesn't clearly separate "content I'm reading" from "commands I execute." This isn't a hypothetical — it's a documented category of attack against browser-using agents, and forms sit right at the point where reading turns into action.

There's no silver bullet here, but the mitigations that actually help are: keeping the set of actions an agent can take (submit this form, to this endpoint, with these fields) narrow and explicit rather than open-ended; never letting page content directly control which endpoint gets called; and — this is the part that connects back to infrastructure — making sure that even if an agent is tricked, the blast radius is limited by scoped credentials rather than a general-purpose session that can do anything.

Defeating anti-bot and anti-spam defenses

If an agent's only path to submitting a form is pretending to be a human typing into a browser, it will eventually run into the exact defenses built to stop bots from doing that: CAPTCHAs, honeypot fields, behavioral fingerprinting, rate limiting keyed on IP address. Some agent tooling tries to power through these — solving CAPTCHAs, mimicking human typing cadence, rotating IPs to dodge rate limits. This should give you pause regardless of which side of the form you're on.

If you're building the agent: teaching your automation to defeat anti-abuse systems is not a defensible engineering posture, even when the intent is benign. You're training a tool to look indistinguishable from an attacker, on infrastructure you don't control, against defenses you didn't design. The moment that capability exists, it doesn't stay scoped to your good intentions.

If you're the form owner: a defense that a well-resourced legitimate agent can quietly defeat is a defense that isn't really defending anything — it's just adding friction for the agents polite enough not to bypass it, while the actually malicious traffic that motivated the CAPTCHA in the first place has every incentive to solve it anyway.

The way out of this bind isn't a smarter CAPTCHA. It's giving legitimate agents a path that doesn't require impersonation at all — an authenticated API route that says "I am agent X, authorized by account owner Y, here is my submission" instead of a browser automation script trying to look convincingly human. That single design choice removes the incentive to defeat anti-bot systems, because there's no longer a reason to pretend.

Silent failure and hallucinated success

An agent that fills a browser form and clicks submit generally can't easily tell the difference between "submitted successfully," "silently flagged as spam and discarded," and "rejected by client-side validation the agent didn't parse correctly." Web forms are built to show a human a success message or an error state, not to hand a machine a structured, unambiguous result. An agent working purely off rendered HTML has to infer success from things like a page redirect or a toast notification appearing — inference that breaks the moment a site redesigns its confirmation flow.

This matters because the failure mode isn't "the task didn't happen." It's "the task didn't happen, and the agent confidently reported that it did." For anything a person is relying on — a job application, a support request, a signup — a confidently wrong success report is worse than an honest error, because nobody goes back to check.

The reliable fix is structural: agents should submit through channels that return an explicit, machine-readable result — an HTTP status code and a JSON body the agent can actually reason about — rather than scraping a rendered confirmation page and hoping. This is one of the strongest arguments for API-first form submission over pure browser automation, and it's worth its own section below.

Over-broad permissions and cross-account bleed

If you operate more than one agent — a support bot, a lead-qualification bot, an internal QA suite — sharing one set of credentials across all of them is a common shortcut that causes real damage later. The failure mode is boring but expensive: one agent starts misbehaving (a bad prompt update, a bug, a compromised dependency) and because it shares credentials with everything else, you can't turn it off without turning everything off. Worse, if credentials aren't scoped per account and per form, a misconfigured agent can end up submitting to — or reading from — resources it was never meant to touch.

Scoping matters here in two directions: each agent should have its own credential, and each credential should be limited to exactly the forms and accounts it's meant to operate on. This is the same principle as least-privilege access control anywhere else in your infrastructure; forms just haven't traditionally been treated as something that needs it, because historically nothing but a human was submitting them.

Rate limits, quotas, and runaway loops

Agents don't get tired. A retry loop with a bug in its backoff logic, or an agent stuck reinterpreting a task in a way that causes it to resubmit the same form repeatedly, can generate in minutes what would have taken a spam campaign hours to produce manually. This is a risk to the form owner (their inbox gets flooded, their quota gets burned) but it's just as much a risk to whoever is paying for the agent's API usage and outbound requests — a loop that goes unnoticed can be an expensive mistake before anyone catches it.

The mitigation is symmetric: form backends should enforce quotas against authorized agents exactly as they would against anyone else, and agent frameworks should build in sane retry limits and circuit breakers rather than assuming the network and the endpoint will always behave.

Why the human-era defenses don't transfer

It's worth being specific about why the standard toolkit doesn't just port over to agent traffic, because the instinct to reach for familiar tools is strong and mostly unhelpful here.

• IP allowlisting assumes a stable network origin. Agents typically run on shared cloud infrastructure — the same provider, sometimes the same address range, serving thousands of unrelated tenants. Trusting an IP today tells you nothing about who's behind it tomorrow, and it can't tell two different agents on the same infrastructure apart at all.
• CAPTCHA assumes the thing on the other end either is a human or is trying to convincingly imitate one, and that failing to solve it is evidence of bad intent. A legitimate, authorized agent isn't trying to imitate a human — it's a different kind of caller entirely, and forcing it through a human-verification gate is solving the wrong problem. Worse, as covered above, a CAPTCHA that a well-built malicious bot can solve anyway is providing false confidence while still blocking the traffic you actually wanted.
• Session cookies assume a browser that stays open, refreshes its own session, and is being driven by something that will notice and respond when the session eventually expires. Handing a long-running or unattended agent a session cookie means someone has to babysit that session's lifecycle, and the failure mode when nobody does is the agent going dark with no clear error — exactly the silent-failure problem from above.
• Honeypot fields and behavioral fingerprinting assume the caller is trying to look human and can be caught making a mistake a human wouldn't — filling in a hidden field, moving the mouse in an inhumanly straight line. These are genuinely effective against unsophisticated bots. They're not designed to say anything meaningful about a legitimate, disclosed agent that isn't pretending to be anything other than what it is.

The common thread: every one of these defenses is built around a binary — human or bot — with no room for a third category that's automated, but authorized, disclosed, and acting on real intent. Closing that gap requires a defense that doesn't rely on behavioral mimicry at all: identity and authorization, established once, checked on every request.

What "submitting safely" actually looks like

Once you accept that impersonation-based approaches are a dead end, the design that falls out is fairly clean, and it maps closely to how you'd think about any other machine-to-machine integration.

1. Give every agent its own scoped credential
   Not a shared API key. Not a copy of someone's session cookie. A credential that identifies this specific agent, that the form owner generated deliberately, and that can be revoked without touching anything else. This single decision resolves most of the risks above at once: it removes the incentive to impersonate a human (the agent doesn't need to look human — it's already trusted), it limits blast radius if something goes wrong (revoke one credential, not a whole session), and it makes every submission attributable.
2. Make authorization explicit and visible to the human
   The form owner — not the agent, not the agent's developer — should be the one who decides an agent is allowed to submit to their form, and should be able to see that decision reflected somewhere concrete: a label like "Claude Desktop" or "internal CRM sync" attached to a credential they generated themselves. This is the difference between an agent finding a way in and an agent being let in. It sounds like a small distinction. It's actually the entire distinction between "agent traffic" and "an attack."
3. Keep humans and agents on separate trust paths, not a shared one
   The instinct to relax spam filtering "a little" so agents can get through is understandable and almost always a mistake — it weakens protection for your actual human traffic to accommodate a use case that has a cleaner solution available. The better shape is two lanes: human submissions go through your existing anti-abuse pipeline unchanged, and authorized agent submissions go through an authenticated route that skips that pipeline entirely because trust was already established at the credential level, not inferred from behavior.
4. Return structured, unambiguous results
   An agent needs to know, programmatically, whether its submission succeeded — not by scraping a confirmation page, but from an HTTP status code and a response body it can parse without guessing. This closes the silent-failure and hallucinated-success problem directly: if the API can't lie by omission, the agent can't confidently report success on a submission that didn't happen.
5. Enforce the same limits you'd enforce on anyone else
   Authorized doesn't mean unlimited. Agent submissions should count against the same per-form rate limits and account-level quotas as any other traffic. This protects the form owner from a misbehaving agent and protects whoever's paying for the agent's usage from a bug turning into a runaway bill.
6. Log everything, and make revocation instant
   Every submission from an agent credential should be tagged as such in whatever inbox or dashboard the form owner is looking at — not mixed in indistinguishably with human submissions, and not hidden away in a separate system nobody checks. And revoking an agent's access should be one click that takes effect immediately, without deleting the historical record of what that agent already did. You want the ability to stop trusting an agent going forward without losing your ability to audit what it did while you did trust it.

Put together, this is what an "agent-ready" form backend looks like in practice — not a weaker version of a normal form backend, but a form backend that has a legitimate, first-class path for a category of caller the original design never anticipated. This is exactly the model laid out in more depth in why forms break for AI agents: trusted agents submit cleanly, anonymous bots still get caught, and every submission is attributable to a real identity — human, agent, or otherwise.

API-first vs. browser-driven: which one is actually safer

This is worth addressing head-on, because it's the single biggest architectural decision that determines whether "safe agent form submission" is easy or hard.

Browser-driven agents — the ones using computer-use style tooling to render a page, locate fields visually or via the DOM, and interact with them the way a person would — are enormously flexible. They can handle a form nobody built an API for. They're also, for everything covered above, the harder path to secure: they're more exposed to prompt injection through page content, they're more likely to end up using a human's session because that's the path of least resistance, they can't cleanly distinguish success from silent rejection, and their traffic looks, by design, like it's trying to pass as human — which puts them on a collision course with anti-bot defenses even when there's no malicious intent anywhere in the chain.

API-first agents — ones that call a defined endpoint with a scoped credential and structured parameters — sidestep almost all of that by construction. There's no page to misinterpret, no session to borrow, no confirmation banner to guess at. The agent gets a clear success or failure, the form owner gets a clean audit trail, and there's no reason for the agent to imitate human behavior because it was never pretending to be one.

The practical answer for most developers building agent-facing products isn't "pick one." It's: prefer an API path wherever one exists, and treat browser automation as the fallback for forms that genuinely don't offer anything better — while being honest with yourself that the fallback path carries meaningfully more risk and deserves more scrutiny, not less. If you're building a form that you expect agents to interact with, the single highest-leverage thing you can do for safety is simply offering an API, discoverable enough that an agent doesn't have to guess it exists. A machine-readable, CORS-open OpenAPI specification that an agent can read directly — no docs scraping, no guessing at field names — turns "agent has to reverse-engineer my HTML form" into "agent reads a spec and calls an endpoint," which is a categorically safer interaction for everyone involved.

A worked example

It's easier to see this land as actual code than as principles, so here's the shape of an agent-safe submission using a scoped credential rather than browser automation.

Setting it up on the form-owner side — generating a credential and handing it to a specific agent:

# Form owner authorizes one agent, with a label so they remember what it's for
curl -X POST https://login.ollastack.com/api/forms/frm_.../agents \
  -H "Authorization: Bearer fmd_owner_..." \
  -H "Content-Type: application/json" \
  -d '{"label":"Scheduling agent"}'

# → { "agentId": "agt_…", "token": "fmd_agent_…" }

That token — and only that token — is what the agent gets. Not the owner's dashboard login, not a session cookie, nothing that reaches beyond this one form.

On the agent side, submitting is a single authenticated request:

curl -X POST https://login.ollastack.com/api/forms/frm_.../submit \
  -H "Authorization: Bearer fmd_agent_..." \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Priya Shah",
        "email": "priya@example.com",
        "message": "Requesting a 30-minute product demo, preferably next week."
      }'

# → { "status": "received", "submissionId": "sub_…", "agent": "Scheduling agent" }

Notice what that response gives the agent: an unambiguous status, a submission ID it can reference later, and confirmation of which identity the submission was attributed to. No page to scrape. No guessing whether a redirect meant success. If this request fails — bad field, quota exceeded, revoked credential — the agent gets a clear error back instead of a form that silently swallows the attempt.

On the receiving end, the form owner's inbox shows this submission tagged with the "Scheduling agent" label, distinct from anonymous traffic, and if that agent ever needs to be cut off, revoking agt_… stops it instantly without touching any other integration or losing the historical record of what it already submitted.

This is the entire pattern. It doesn't require the agent to understand HTML, doesn't require it to solve a CAPTCHA, doesn't require a shared session anyone has to babysit, and gives both sides — the agent's operator and the form owner — a clean record of exactly what happened.

What happens after the submission

A form submission is rarely the end of the task — it's usually the start of a conversation. Most forms that matter trigger a follow-up: a confirmation email, a verification code, a reply from a human on the other end. An agent that can submit a form safely but then has no way to receive what comes back is only solving half the problem.

This is where a lot of otherwise well-built agent integrations quietly fall apart. The agent submits a signup form, and now needs to read the verification email that lands seconds later to complete the flow — but the agent has no inbox, so a human has to step in anyway, which defeats the point of automating the task at all. Or the agent submits a contact form, and the business replies by email a day later, and there's no way for the agent (or its operator) to see that reply land in a thread it can act on.

The fix here mirrors the fix for form submission itself: give the agent a real, scoped identity on the receiving end too, not a workaround. A persistent mailbox the agent owns can receive that confirmation, extract a verification code or link automatically instead of the agent having to regex raw HTML, and reply in-thread if a conversation continues — all over an API the agent can drive the same way it drove the form submission. This is covered in depth in email for AI agents, and the two capabilities are designed to sit on the same API and the same token system deliberately, because in practice they're almost never used independently — an agent that fills out forms is, sooner or later, an agent that needs to read what those forms trigger in response.

Testing this before it's live

If you're the one building an agent that submits forms, "does it work safely" isn't a question you want to answer for the first time in production. The same reliability problem that makes silent form failures dangerous for end users makes them dangerous for your own CI pipeline — a form-submission test that can't verify its own outcome isn't really testing anything.

The pattern that holds up well here is to run the same kind of scoped, API-first flow against a disposable, unfiltered test mailbox instead of a real one: submit the form, then wait on a test inbox for whatever confirmation email or OTP the flow is supposed to trigger, and assert on the structured content of that message rather than scraping a rendered page. This closes the loop in a way that's genuinely automatable — no human checking an inbox, no flaky screenshot comparisons, just a request, a wait, and a structured assertion. Testing email in Docker and CI with a disposable inbox and asserting on email in Playwright and Cypress both walk through this in more depth, and the same disposable-inbox pattern is exactly what you want sitting behind an agent's own form-submission tests before you trust it against real forms.

A checklist for developers

If you're building an agent that will submit forms, or building a product that an agent might interact with, here's the condensed version to actually act on:

If you're building the agent:

• Give it its own credential per integration — never a copy of a human session, never a credential shared across multiple agents or tasks.
• Prefer an API path over browser automation whenever the form owner offers one; treat browser automation as a fallback, not a default.
• Keep the agent's set of possible actions narrow and explicit — which endpoints, which forms, which fields — rather than letting page content or upstream instructions expand what it's willing to do.
• Never let untrusted content (a page, a document, an email) directly control which endpoint the agent calls or what credential it uses.
• Check the response, not the appearance — treat a submission as successful only when a structured, unambiguous confirmation says so.
• Build in real rate limits and backoff logic, and don't assume the network or the endpoint will always cooperate.
• Log what the agent submitted, where, and when — somewhere the human who owns the task can actually review it.

If you're building the form (or the backend behind it):

• Offer an authenticated, scoped submission path — not just an HTML form — so legitimate agents never have to impersonate a human to reach you.
• Let form owners generate and label per-agent credentials themselves, rather than inferring trust from behavior or IP.
• Keep human traffic on your existing anti-abuse pipeline, unweakened, and give agent traffic a separate authenticated lane.
• Tag every submission with its source — human, or which specific agent — visibly, in whatever inbox or dashboard the owner actually looks at.
• Enforce the same rate limits and account quotas against agent traffic as against anyone else.
• Make revocation instant and make it not delete history — the owner should be able to stop trusting an agent without losing the record of what it already did.
• Publish a discoverable, machine-readable API spec so agents can find the safe path instead of falling back to scraping your HTML.

Common mistakes worth calling out specifically

Treating "it's just a form" as low-stakes. Contact forms and demo requests feel minor compared to, say, a payment API, which is exactly why they get the least security attention and the most agent traffic. The data flowing through a form — names, emails, company details, sometimes far more — deserves the same care as any other input surface.

Reusing one credential everywhere "for now." This is always framed as temporary and rarely gets fixed before it causes a problem, because the problem it causes — an incident that requires revoking everything at once — is exactly the moment nobody has time to redesign the credential model from scratch.

Assuming a CAPTCHA solved by an agent means the agent did something wrong. Sometimes it does. Often it means the form owner never gave the agent a legitimate path in, and the agent's tooling took the only route available. The fix isn't a harder CAPTCHA — it's an API.

Building the agent's success detection around page content. Confirmation banners get redesigned. Redirects change. A/B tests move things around without warning. Anything an agent infers from rendered HTML is one deploy away from silently breaking, invisibly, for exactly the reason you'd least want it to — the agent will keep confidently reporting success on a form that stopped working weeks ago.

Skipping the audit trail because "it's just automation." The first time someone asks "did our agent submit this, and under whose authority" is usually the worst possible time to discover there's no record. Build the trail before you need it, not after.

The bigger picture

None of this is really about forms specifically. It's about a broader shift that's already well underway: a meaningful share of the traffic hitting the ordinary interfaces of the web — forms, yes, but also search boxes, checkout flows, support widgets — is no longer coming from a human directly, but from a tool a human delegated the task to. Treating that traffic as an edge case to tolerate, rather than a category to design for deliberately, is how you end up with the two failure modes that define the current mess: sites that block legitimate agents by accident because their defenses can't tell them apart from attackers, and agents that resort to impersonating humans because nobody gave them a better option.

The fix on both sides is the same idea, applied from opposite directions: identity and scoped authorization, established explicitly and revocably, instead of trust inferred from behavior that's increasingly easy for both good and bad actors to fake. An agent that submits with its own credential, to an endpoint built to receive it, gets a categorically safer interaction than one trying to look human enough to sneak past defenses designed to catch exactly that. And a form backend that recognizes disclosed, authorized agents as a legitimate third category — not just "human" or "bot" — gets to keep its real defenses sharp instead of quietly dulling them to let automation through.