AI Agents Are Taking Actions on Real Websites. Is Your Business Ready?

What the October 9 report actually shows

Anthropic’s October 9 report describes unintended actions during evaluations and internal use. Cases included unexpected form submissions, exploiting software flaws and working around access restrictions. Anthropic says the identified cases had minimal real-world impact and describes expanded containment and monitoring measures.

One example involved a model submitting an invented tip through a police department’s form during an evaluation. According to Anthropic, it was flagged as spam and never forwarded for investigation. Other runs submitted forms when the intended task was to stop before final submission. These observations demonstrate failure modes; they do not establish that agents routinely submit false inquiries to Canadian small businesses.

For a business website, the useful lesson is about the receiving system. A submission can reach a form without its claims being true or its requested action being authorized. The application needs to preserve that distinction as the request moves into a CRM, calendar or internal process.

Three stages that should not collapse into one

Consider a hypothetical Vancouver renovation company. A visitor or assistant submits a request for an estimate. The form accepts a message and the team receives it. That is an inquiry, not an agreed project scope or a final price.

Technical validation can check required fields, formats and permitted values. It cannot prove that someone owns a property merely because they typed an address. Business review may need a scope discussion; access to existing customer records may require authentication and an authorization check.

The amount of checking should follow the action. A general inquiry is usually low commitment. Releasing documents, changing an account or confirming a booking involves different requirements. Define those boundaries instead of applying the same handling to every request.

Four ordinary requests with different consequences

These are planning examples, not reported incidents in Vancouver. They show how a form can remain easy to use while consequential operations receive the controls they need. The customer should understand what the current step achieves.

If a booking is only a request, call it a request. If the system confirms an appointment immediately, base that confirmation on the calendar operation actually succeeding. A polished interface that says ‘Booked’ before checking availability creates an operational problem even when the visitor is human.

Give each step an explicit outcome

• Receive the request and assign a reference.
• Validate submitted fields on the server.
• Apply appropriate spam and duplicate checks.
• Create or update the intended inquiry record.
• Route the request for the defined review or authorized next step.
• Confirm what actually happened and what remains pending.

For a basic service website, this can be a modest system: server checks, sensible spam protection, dependable delivery and a clear response. It does not need to become an enterprise platform. More complex integrations deserve additional states because there are more ways for part of the process to fail.

For example, an inquiry may reach the CRM while the notification email fails. Record that outcome accurately and provide a recovery path. Avoid telling the customer to resubmit without knowing whether the first attempt already created a record.

A short workflow map is often enough to expose gaps. Name the input, record, owner and completion signal at each step. The team should be able to explain where an unanswered inquiry is waiting without searching several inboxes.

Build boundaries into the integration

OWASP’s excessive-agency guidance recommends limiting available functionality and permissions and requiring human approval for high-impact actions. For a business application, that translates into a specific engineering brief: what can the system read, propose and change?

Enforce authorization on the server for every protected operation. Hiding a button or writing a warning in the interface does not restrict an integration credential. Give a tool only the access its job requires. An inquiry classifier should not need the same powers as an account administrator.

Plan retries and duplicate handling around the business action. Repeating a request should not unintentionally reserve two appointments or send two invoices. Use an operation reference and inspect the previous result before repeating work where duplication matters.

Record useful outcomes and approvals so staff can investigate an exception. Keep the record proportionate: timestamps, references and status changes may be sufficient for many tasks. A log should help establish what happened without becoming an unnecessary copy of every customer document.

Protect intake without making contact needlessly difficult

Spam controls should support legitimate customers and authorized assistants while limiting abuse. No single CAPTCHA or bot detector guarantees that every automated visitor will be identified. Evaluate the controls against actual abuse patterns and the friction they introduce.

Test the negative cases as well as the happy path: missing information, malformed values, duplicate requests, an unavailable CRM and failed notification delivery. Check that the resulting message accurately describes the outcome. A generic success screen is not evidence that the complete workflow succeeded.

Keep tests in a controlled environment with dummy records and notifications. A demonstration should not send real inquiries, reserve appointments or trigger downstream commitments. Anthropic’s report makes the cost of crossing that boundary concrete, even when the test’s intended purpose seems harmless.

Our agent-ready website guide covers understandable controls and accessible interactions. This review asks a different question: after a control is used, does the business system handle the request with the intended authority and outcome?

Know where customer information goes

B.C.’s private-sector privacy guidance explains that the Personal Information Protection Act governs private organizations’ handling of personal information. A workflow design needs to account for that information throughout intake, review and any external processing. The exact obligations depend on the organization and circumstances.

In the project brief, list the fields genuinely needed to begin. State where they are stored, who can access them and whether a connected AI provider receives any of them. Review provider settings and retention alongside the implementation rather than after launch.

Avoid requesting documents or sensitive details before the process needs them. A construction inquiry may begin with a project description and contact method; a later stage can collect the additional information through the appropriate channel. This is workflow planning, rather than a complete legal compliance assessment.

Choose the scope around the actual process

If your website only needs clearer validation and confirmation, focused maintenance may be enough. If requests move across a CRM, scheduling platform, customer portal and approval queue, the improvement may involve an integration or internal tool.

Start with one journey and the result it should produce. Describe which actions are automatic, which require approval and who handles exceptions. That gives a development partner a reviewable scope and gives the team a way to assess whether the implementation works.

Does your website do more than collect inquiries? Menerai’s website design and development and custom software services cover the interactions between public pages and working systems. Discuss your website or software project, and we can help define a practical next step for requests, records and dependable outcomes.