Your AI assistant trusts that website. Should it?

You ask an AI assistant to review a supplier proposal and prepare an internal summary.

It opens the supplier’s website, follows a document link and reads the proposal. Inside that material is a request to upload supporting company information to a separate portal to “complete verification”.

The assistant has access to internal files. It also has tools capable of submitting information.

Should it follow the request?

Your instruction was to review a proposal. The supplier’s content has introduced a new action, a new destination and a potential disclosure of company information.

This fictional scenario illustrates a central challenge for business AI: distinguishing information relevant to a task from instructions that have no authority to change it.

A website can provide information your assistant needs without gaining permission to tell it what to do.

When reading becomes an instruction risk

AI assistants can extract useful information from websites, emails and documents. Some can also use tools to update records, send messages, upload files or interact with applications.

That combination creates an opportunity for an attacker to place instructions inside material the assistant is expected to read.

This is commonly called indirect prompt injection. The attacker may have no direct access to the assistant or its user. Instead, they influence external content that enters the assistant’s working context.

The NCSC describes this as untrusted material being interpreted as instructions and cautions that language models do not provide a robust security boundary between instructions and data within a prompt.

The content does not need to announce itself as an attack. It might resemble a helpful process update, an administrative requirement or a necessary step towards completing the user’s task.

A legitimate website can still contain untrusted instructions

Checking the website’s identity is useful. It answers only part of the question.

A recognised platform might host documents supplied by customers. A supplier portal might include messages from outside contributors. An otherwise legitimate website could contain compromised content.

The assistant therefore needs to distinguish trust in the platform from authority granted to the material it reads.

Anthropic identifies untrusted web content as a prompt-injection risk for browser agents and explicitly states that no browser agent is immune.

Even wholly legitimate instructions on a website may exceed the user’s request.

A supplier can reasonably ask visitors to create an account. That does not mean an assistant asked to summarise the supplier’s services has permission to register, accept contractual terms or upload internal documents.

The same boundary matters whether the request is malicious, mistaken or simply outside scope.

The consequence depends on what the assistant can do

An assistant that produces a draft summary and an assistant that can send files to external recipients have different exposure.

A misleading instruction might distort the first assistant’s answer. With broader access, it could also influence an external action.

The practical questions are therefore specific:

Which information can the assistant read? Which systems can it change? Where can it send data? What checks happen before those actions execute?

Google’s guidance for browser agents notes that they may operate within a user’s authenticated session, making protections against malicious input particularly important.

A signed-in session can make a task convenient. It can also give the assistant access that an unauthenticated visitor would never have.

The business needs to decide which of those capabilities the task actually requires.

Three checks before an action

A useful approach separates three questions.

These checks complement one another.

A destination with a favourable reputation does not establish authorisation. A user-authorised task does not make every destination it encounters safe. Permission to read a document does not imply permission to distribute it.

A defensible action needs the relevant checks to agree.

Put important boundaries outside the model

Instructions telling an assistant to ignore malicious content can help establish intended behaviour. They should be supported by controls that enforce what the system is allowed to do.

For the proposal-review task, that could mean giving the assistant access only to the selected material and allowing it to produce a draft. Uploading company files would require a separate authorised workflow.

For an assistant updating business records, it could mean restricting which fields it can change. For outbound communication, it could mean enforcing permitted recipients and data-handling rules at the tool or application layer.

The NCSC recommends deterministic safeguards that constrain actions, alongside measures intended to reduce the likelihood of prompt injection succeeding.

The important design principle is that a model’s interpretation of a webpage should not be able to expand its own permissions.

Check the destination where the action occurs

In the opening scenario, the assistant begins at a supplier website but is directed to another portal.

That change matters.

A check on the original website does not establish the status of the upload destination. If information is about to leave the organisation, the relevant assessment concerns where it will actually go.

Domain, IP and email intelligence can contribute evidence at that point. A destination associated with phishing or other observed malicious activity may justify stopping and investigating.

The check needs to be part of the action path. A warning visible to a human in one browser session may provide no protection to an agent using a separate browser, a direct API or another execution environment.

Organisations should verify which routes their controls actually cover.

Reputation cannot resolve prompt injection on its own

External intelligence has a useful but bounded role.

It can help identify known adverse associations with destinations and infrastructure. It cannot establish that every instruction on a reputable website is safe to follow.

A new attack may have no adverse history. An attacker may use a legitimate shared service. A request may be inappropriate because of the information involved, even when the recipient’s infrastructure is entirely legitimate.

Prompt-injection resilience therefore requires several controls working together: limited access, clear task boundaries, careful handling of external content, checks on proposed actions and appropriate oversight.

A clean domain result should never grant a webpage authority over the assistant.

Make approval specific enough to be useful

“Do you want me to continue?” gives a reviewer little basis for deciding.

Where approval is required, the request should identify the action, destination and information involved. It should also make clear when the proposed step originated in external content rather than the user’s instructions.

For example:

The proposal asks for an internal pricing document to be uploaded to a separate portal. This goes beyond summarising the proposal. The upload would disclose that document to an external recipient.

That explanation exposes the decision the person is being asked to make.

Approval should apply to the reviewed action. A later change in recipient, destination or file should trigger a fresh check where required by policy.

Keep enough evidence to understand what happened

If an assistant takes an unexpected action, investigators need to reconstruct the sequence.

What did the user request? What external content was encountered? Which action was proposed? Which controls evaluated it? What information was sent, and where?

Logs should support those questions while respecting access restrictions, retention requirements and the sensitivity of the data being recorded.

A successful task-completion message is insufficient evidence that the task stayed within its authorised boundaries.

The system should be evaluated on both completion and control.

What this means for ThreatPrevent

ThreatPrevent’s focus on high-confidence signals for domains, IP addresses and email addresses is relevant wherever a digital interaction needs assessment.

For AI workflows, that creates a practical role for trust intelligence: checking destinations and counterparties as part of an action’s evaluation. Through an appropriately designed integration, those signals can inform whether the workflow proceeds, pauses or escalates.

They remain one part of the decision. They do not authenticate instructions embedded in a webpage or replace controls governing access and disclosure.

The opportunity is to make AI assistants more useful by giving them clear, enforceable boundaries and relevant evidence.

Before your assistant acts on something it reads, ask two questions: what supports trusting the destination, and who authorised the action?