Can Text On Your Website Give Orders To An AI Agent?

Can text on my website give orders to an AI agent?

In principle, yes, and that is the whole problem. AI systems that read the open web treat the words on a page as input, and input can be written to look like an instruction. Whether a given agent falls for it depends on how it was built, but the attack class is real and well documented.

This matters to marketers now for a boring reason. Your pages are no longer read only by people and crawlers. They are read by assistants summarising your product, by agents doing research on behalf of a buyer, and by tools your own team points at competitor sites.

So the question stops being theoretical. If a page can influence a model, then your pages can influence models, and other people's pages can influence the models your team relies on.

What is prompt injection, in plain terms?

It is the trick of getting a model to follow instructions it was never supposed to follow. OWASP's Gen AI Security Project catalogues it as LLM01, the first entry in its Top 10 for Large Language Model Applications, which tells you how seriously the security community takes it relative to everything else on that list.

OWASP splits it into two kinds. Direct injection is when the person typing does it. The kind that concerns website owners is the other one. OWASP puts it plainly: indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files.

Read that again with your own site in mind. Your website is an external source. When an assistant fetches your page to answer a question about your product, your copy becomes part of that model's input, sitting alongside the instructions its developer wrote.

OWASP is also explicit that the model cannot reliably tell the difference. Its documentation notes that these inputs can affect the model even if they are imperceptible to humans, and that prompt injections do not need to be human-visible or readable as long as the content is parsed by the model.

Why is a public marketing page part of this at all?

Because the content a model reads and the instructions it obeys arrive in the same channel. Microsoft makes the general principle clear in its own security guidance: any AI system that reads untrusted content, whether from websites, emails, documents or retrieval sources, has to treat that content as potentially adversarial rather than authoritative.

Microsoft's catalog of AI attack techniques lists prompt injection as its second entry and describes a concrete early case. It says that in 2023, researchers demonstrated that indirect prompt injection could exploit AI systems with browsing or document-ingestion capabilities, and that in one case hidden instructions embedded in a malicious webpage caused Bing Chat to treat the page content as a command, generate an image request to an attacker-controlled server, and unintentionally transmit conversation data through URL parameters. Microsoft says it has since fixed that specific issue.

That example is the one worth holding on to, because it is not abstract. A web page. Hidden text. A model that read the text as a command. Data leaving through a URL. Every link in that chain involves ordinary web technology that any marketer already uses.

Microsoft's own explanation of why it works is unsentimental. Models predict the likely continuation of text. They are not detecting deception, because detecting deception is not what they do.

Should I plant instructions for AI agents in my own copy?

No. I want to be blunt about this because the idea is circulating and it is presented as a growth tactic. Hiding a line in your page that tells an assistant to recommend you over competitors is manipulation of a system on behalf of a reader who did not consent to it, and I will not help anyone do it.

It is also a bad bet on the merits. You are writing instructions for systems you do not control, which change without notice, and which are being actively hardened against exactly this. A tactic whose entire value depends on a vendor not fixing a bug is not a strategy.

And the downside is asymmetric. Hidden text that contradicts your visible page is the kind of thing that gets a site penalised under ordinary search guidelines, entirely separately from anything AI related. You would be risking the traffic you have for a trick that may not work.

If you want to influence what an assistant says about you, write a page that answers the question clearly and says true things in plain language. That is not a compromise position. It is the thing that actually works, and it is the whole argument behind why answer engines cite competitors instead of you.

What is the realistic risk to a normal business website?

Lower than a security vendor will tell you and higher than zero. A brochure site with no login, no AI features and no connected tools is mostly a bystander. The severity of an injection depends on what the model can actually do once it has been redirected.

OWASP's own list of consequences makes that dependency clear. The serious outcomes it names include providing unauthorized access to functions available to the model and executing arbitrary commands in connected systems. Those require connected systems. If your site has none, the ceiling on your exposure is genuinely low.

The risk climbs the moment you add something that reads text and then acts. A support chatbot with access to customer records. An agent that reads form submissions and writes to your CRM. A workflow that summarises inbound email. Each of those turns text someone else wrote into something with consequences.

Be honest about which of those you have before you spend money. Most small business sites have none of them, and the correct response to this topic is understanding rather than procurement.

Where does the danger actually sit on a Webflow site?

In anything user generated and anything ingested. A static page you wrote is under your control. The exposure comes from content that arrives from outside and then gets read by something automated, and most sites have more of that than they realise.

Look at your form submissions first. If any automation reads the free-text field of a contact form and feeds it to a model, that field is an untrusted input from a stranger. The same goes for comments, reviews, job applications, uploaded files, and anything a partner syncs into your CMS.

Then look at your own CMS for text nobody reviews. A rich text field pasted from an unknown source can carry markup and characters that are invisible on the rendered page and perfectly legible to a parser. This is the same mechanism I described when writing about how retrieval systems actually chunk and read your content, just pointed in an unfriendly direction.

Images deserve a mention because people assume they are inert. OWASP warns that malicious actors could exploit interactions between modalities, such as hiding instructions in images that accompany benign text. If your workflow runs uploaded images through a model, that is an input path too.

What can you fix this week?

Start by writing down every place where text from outside your organisation gets read by a model. That list is the entire scope of your problem, and most teams have never made it. You cannot defend an input path you have not named.

Then strip what you accept. Sanitise pasted rich text before it enters your CMS, remove hidden and zero-width characters, and stop accepting raw HTML in fields that only ever needed a paragraph of prose. This is unglamorous input hygiene and it removes a large share of the surface for free.

Next, look at what your automations can do rather than what they read. An agent that can only draft and queue something for a person to approve has a much lower ceiling than one that can send, publish or pay. Put a human in front of any irreversible action, especially where the trigger came from a stranger.

And set your expectations correctly, because OWASP does not promise you a fix. It says that given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention. It also notes that retrieval augmented generation and fine-tuning do not fully mitigate the problem, which is worth knowing before a vendor tells you otherwise.

Who owns this problem, marketing or engineering?

Both, and that split is exactly why it goes unowned. The input path usually begins in something marketing built, such as a form or a CMS field, and ends in something engineering built, such as an automation with credentials. Neither team sees the whole line.

My view, from building automations that sit between the two, is that marketing should own the inventory and engineering should own the limits. Marketing knows what content comes in from where. Engineering decides what any automated reader is permitted to do with it. Those are different jobs and both are needed.

The practical move is to review the list together once, then again whenever you add a tool that reads text. That second habit is the one that matters, because the risk arrives with new integrations rather than sitting still. Agentic browsing is already changing what reads your pages, which I looked at separately when covering what agentic browsers mean for a Webflow site.

What should you do next?

Spend thirty minutes making the inventory: every input that comes from outside, and every automation that reads it. Then ask one question per row. If the text in this field told the model to do something, what could it actually do? That question sorts your list into things to fix and things to ignore.

Fix the rows where the answer is alarming, starting with anything that can act without a person. Ignore the rest with a clear conscience. And do not write hidden instructions into your own pages, because it is dishonest and it will not last.

If you want help mapping where untrusted text enters your site and what your automations are allowed to do with it, get in touch. I would rather look at your actual setup and tell you it is fine than sell you a worry.