How to decide which data an AI agent may see

Decide field by field, from the task backwards. An AI agent may see the data each of its capabilities needs, and nothing else: named fields, from named sources, masked where the full value is not needed. The data owner approves the list, the agent's own identity enforces it, and separate decisions cover retention and the model provider.

Who decides, and what are they deciding?

Three separate questions hide inside "what may the agent see". What may it read to do the task? What may it keep afterwards, in logs or memory? And what may leave your environment, for example to a model provider? Each has a different answer and should be decided separately.

The data owner for each source decides access to it, advised by the data protection officer. The process owner explains what the task needs. Security implements it. The principle is data minimisation, which GDPR Article 5 and its UK equivalent require for personal data, and good practice requires for everything else.

What are the steps?

1. Person, process owner: lists each capability's task in plain words: "check whether a direct debit failed and why".
2. Agent, depth 1: proposes the fields that past cases for that task actually used, drawn from a sample of case records. This keeps the list grounded in real work rather than guesswork.
3. Person, data owner: approves fields per capability, removing anything not needed and marking fields to be masked, such as showing only the last four digits of an account number.
4. Person, data protection officer: reviews personal and special-category data, and whether a data protection impact assessment is needed under Article 35.
5. Person, data owner: decides retention. Which fields may appear in the agent's logs and records, and for how long.
6. Person, data protection officer, with security: decides what may leave your environment for the model provider, and on what terms.
7. Person, security: enforces access through the agent's own identity, at field level where systems allow, and through filtered views where they do not.
8. Agent, depth 1: is tested with requests for fields outside its list, including requests that arrive inside customer messages.

Which controls make it safe?

The agent's own identity. If the agent acts with the logged-in employee's access, it sees whatever that employee sees, which is usually far more than the task needs. Give it its own identity with its own grants.

Field-level views. Grant access to a filtered view or an interface that returns only approved fields, rather than the whole table.

Masking by default. Most tasks need to know an account exists and matches, not its full number. Mask unless the capability needs the full value.

Retrieval indexes mirror the source. A search index built from documents must carry the source permissions with it. An index built with an administrator account lets any agent that queries it read everything.

Provenance on every fact. Each piece of data that reaches the agent should carry where it came from, so a fact from the core ledger is treated differently from a figure in an emailed attachment.

Rules that survive a provider change. What the agent may see is your decision, independent of the model behind it; what may leave for a provider can change with the provider's terms. See does switching model providers change what an AI agent may do?

What evidence should the controls leave?

A field list per capability, signed by the data owner; the DPIA where needed; the retention decision; the outbound data decision; configuration exports showing the agent's grants; and test records showing out-of-scope requests refused. The inventory should point to all of these, because, as an agent inventory tells you what exists, not what it may do explains, a list of agents without their permissions answers the wrong question.

Which signs show it is going wrong?

• Answers include data the task did not need. A support agent mentions a customer's other products when asked about one payment.
• Logs hold whole records. Prompts and responses are stored in full, so the log becomes the largest copy of customer data in the firm.
• The field list grows without approval. Builders add fields to fix failing cases, and nobody signs the change.
• Agents read through other agents. One agent with broad access answers questions for another agent with narrow access, and the narrow limit stops meaning anything.
• Requests for out-of-scope data are not refused. Tests show the agent retrieves what a customer message asks for, rather than what its task needs.

What should you measure?

Count refused requests for out-of-scope data by capability, fields added since the last approval, and agents whose access is broader than their approved list at the last access review. Track how much personal data sits in agent logs, by category.

Where does it usually go wrong?

Access is inherited, not designed. The quickest way to connect an agent is to reuse an existing account. It is also the way to give it everything.

Seeing is confused with acting. Teams spend care on which actions an AI agent may take without a person and wave read access through. Reading is where most privacy harm starts.

Data and action lists are separate. Some data should never reach an agent at all, for the same reasons some actions should never be taken by one. Keep the list of actions no AI agent may take and the data rules side by side.

Where Pryme fits

In Pryme, each fact reaches the agent through the Pryme Context Protocol stamped with its source and provenance class, and an agent's sources are one of the five bounds every action meets. Data outside its approved sources does not reach it. The full model is in agent governance is a bound, not a model.