How Data Shapes AI Behaviour and Actions

In an AI application, a document can do more than provide information. Its contents may also influence the model’s response and, in systems that use tools, the actions it proposes. From a security perspective, the important change is the role data plays within this workflow.

Imagine a procurement team asking an AI assistant to compare supplier proposals. The assistant extracts prices, reviews delivery terms and prepares an assessment for management. The documents provide the information needed for the task.

Now take this hypothetical example a step further: one proposal contains an instruction to send the completed assessment to a particular email address. The employee never requested this. Yet if the assistant interprets the wording in the document as an instruction to follow, and has access to an email tool, material supplied for review could change the scope of the task.

A statement within a document can, in this workflow, become an input that influences a subsequent action.

This distinction explains why asking “What data was sent?” is not enough in AI security. Where the information came from, how it was interpreted and what followed from it also become part of the assessment.

What changes when we talk about data types

When we say that “AI has changed the type of data we work with”, three distinct dimensions need to be kept separate.

The first is format. A PDF, email or database record does not automatically become a different file type when it is supplied to an AI system. The second is representation: a document’s text may be extracted, for example, and relevant passages added to the model’s context. The model does not automatically see the entire document or everything the application knows; the document content available to it for that task is limited to the portions it receives.

The third dimension, and the focus of this article, is function. The user’s request defines the task. A retrieved document provides information. The model’s response may become an input to a later step. In an application that uses tools, that step might involve creating a record, drafting a message or carrying out an authorised action. These different pieces of content sit within the same workflow, but they have different roles and levels of authority.

Data influenced software behaviour long before AI. The distinction here is that task instructions and natural-language content for review can appear in the same model context, and the boundary between them is not always reliably maintained. As a result, content can influence the model’s response and, in systems that use tools, its choice of action. 1

The idea of “new data” is therefore best understood here as considering the relationships between information, context and actions as part of security assessment, rather than as a universally recognised new technical category of data.

Information and instructions share the same context

An AI application may present the model with a user’s request alongside document excerpts, previous messages and tool results. Although their wording may be similar, these inputs do not carry the same authority. The user has requested a task; the supplier’s document provides information to help complete it.

If the model fails to maintain this distinction, a direction embedded in an external source may be treated as though it came from the user. Research into preserving source information when text from different origins is processed together addresses this problem directly. 2

Using external content to steer a model’s behaviour in an unintended direction is known as indirect prompt injection. A document does not need to contain executable code to have this effect. A natural-language instruction encountered by the model can also influence its behaviour. The risk depends on what data the system can access and what actions it can perform. 3

In the procurement example, the pricing information in the proposal may be accurate. That does not give the document authority to instruct the assistant to send the assessment to another address. Information accuracy and the authority to issue instructions are separate questions.

A supplier proposal does not authorise sharing

In an AI interaction, content and permission to act are assessed separately.

Meaning develops across the interaction

The meaning of a sentence in a document may depend on the surrounding text. In a task performed with AI, that context can also extend to previous messages and the results returned by other tools. To interpret “Add this to the same list”, the system needs to know what “this” refers to and which list is intended.

The same principle matters for security. A response that appears unremarkable on its own may carry a meaning established in an earlier request. Information extracted in one step may be combined in another, and a summary may later be used to carry out an action. Looking only at the final message may not explain how the result came about.

Security classifiers that assess the input and response together make use of this relationship. Research shows that meaning missed when a response is examined in isolation can be better understood when it is considered alongside the request that produced it. This does not mean that collecting more conversation history always improves security. The context required should be determined by the task and the risk being assessed. 4

The practical implication is to preserve the connections between relevant steps, as well as classifying individual messages. This extends the assessment from the contents of a single sentence to how the task unfolds.

When a response becomes an input to an action

In a chat system, the model’s output may simply be text shown to the user. In an application connected to tools, the model may also propose which tool to call and what information to pass to it. In that setting, the scope of the resulting action needs to be assessed alongside the accuracy of the output.

A request to “draft an email” does not automatically authorise sending it. Permission to read a file does not confer permission to transfer it elsewhere. Reading, summarising and sharing the same content may require different control decisions.

A model’s proposed action must therefore pass the authorisation checks enforced by the application and the relevant backend systems. The user, the recipient, the data to be shared and the permitted scope of the action all matter. Validating tool requests against security policies should not depend solely on the model’s judgement that an action is appropriate. 5

Research designs that separate data flow from control flow approach the same question at a different level: to what extent can external information change how a task is carried out? This work shows that preserving source and authority relationships in the software surrounding the model is also an avenue for defence. 6

Security records must preserve relationships

For security, this shift means being able to examine a task’s request, the context used, the model’s output and the actions taken together. These elements can be understood as the security record of an AI interaction.

The following questions make explicit which relationships need to be preserved to understand an event.

These records do not provide a complete account of the model’s internal reasoning; they link observable steps in the system. Nor does every task require every field to be retained in the same detail. The content recorded, retention period and access permissions should be limited to a defined security purpose. These boundaries are particularly important when interactions contain personal information. 7

In the procurement example, knowing that the proposal entered the system is only part of the picture. It should also be possible to see which passages were included in the context, at what stage the suggestion to send the assessment emerged, and what decision was made about it. That makes it possible to move from identifying suspicious text to understanding which control is needed and where it should apply.

Putting this into practice

Four practices follow from this approach:

Preserve the source and role of relevant content so reviewers can distinguish task instructions from reference material.
Validate proposed tool calls against application policies and permissions outside the model.
Link the request, relevant context, response and action outcome so the task can be reviewed as a connected sequence.
Limit the information retained, retention periods and access permissions to a defined security purpose.

The changing role of data in AI is reflected in the expanding relationship between content and system behaviour. Security must therefore account for how data is interpreted and which actions it informs, alongside where it resides.