What Data to Give an AI Agent First: A Ranked Guide by Risk

Connect the data that is curated, owned and read-only first: your written procedures, policies, product and service descriptions, templates and approved answers. These sources give an agent most of its usefulness at the lowest exposure, because they were written to be shared and do not identify a customer or an employee. Move next to operational history, then narrow customer fields, and leave financial, HR and credential data for later, with tighter access each time.

Key takeaways

• Rank every source on two questions: how much of the role's work depends on it, and how much harm follows if it leaks, is wrong or is misused.
• Start with curated, owned, read-only documents such as procedures, policies, templates and approved answers.
• Add operational history and customer records only after the agent uses the first sources correctly, and only the fields the role needs.
• Treat content that arrives from outside the company as its own risk, because it can carry instructions meant to manipulate the agent.
• Keep write access, financial records, HR files and credentials out of the first engagement unless a specific, approved task requires them.

Why does the order of connections matter?

Every connection you give an agent is more than a file transfer. It is a permission that must be granted and reviewed, a retrieval path that can return the wrong thing, a trail in the logs, and a source that someone has to keep current. Connect many things at once and nobody can explain afterwards what the agent knew when it gave a poor answer.

Order also protects usefulness. Guidance on building agents, such as Anthropic's writing on context engineering, makes the point that an agent works best with a small, well-chosen set of relevant information rather than everything available. A folder of outdated and contradictory files makes answers worse, not better.

The data list should follow from the role, not the other way round. If you have not yet written down what the agent is for, start with a job description for your first AI agent role, then return here to decide what that role needs to read.

How do you rank a data source by value and exposure?

Score each candidate source with questions that a small group can answer in one meeting. Start with value: how much does the role depend on this source?

• Does the role's daily work depend on this source to answer questions or draft output?
• Is the content current, and does a named person keep it current?
• Is it written clearly enough that a new hire could rely on it?

Then score exposure: what happens if something goes wrong?

• Does it identify a person, a customer or an account?
• Would a leak, or a wrong answer based on it, create legal, financial or contractual harm?
• Can people outside the company write into it, through email, web forms or public reviews?
• Can the agent change it, or only read it?
• Can access be limited to a folder, a view or a set of fields, or is it all or nothing?

The first connections are high value and low exposure. High value and high exposure sources come later, narrowed to the smallest slice that still does the job. Low value sources can wait indefinitely, whatever their exposure.

Which sources should come first, in order?

This is the order that fits most first engagements. Your role may move a source up or down a rung, but the logic holds: owned before inherited, curated before raw, read-only before anything that writes.

• First: procedures and playbooks. Step-by-step instructions, checklists, escalation rules and how-to pages. They define how work is done, they are written to be followed, and they rarely contain personal data.
• Second: policies, product and service descriptions, approved templates and tone guides. They keep the agent consistent with what the company has already decided to say.
• Third: resolved work history, such as closed tickets, past proposals and answered questions, after a review that removes personal details and anything that no longer reflects how you work.
• Fourth: team context, such as a directory, shared calendars and project boards, read-only and scoped to the team in the pilot.
• Fifth: customer records, read-only, limited to the fields the role needs, such as order status or account stage rather than the full file.
• Later: any channel that receives messages from outside, such as a shared inbox or a web form, once handling of untrusted content has been tested.
• Last, if ever in the first engagement: financial ledgers, payroll, HR files, legal matters, health information, credentials, and any connection that lets the agent write or send.

Notice what the early rungs share. A person wrote them on purpose, the company owns them, and a mistake in one is visible and fixable. The later rungs hold information that nobody wrote for an agent to read.

What should wait, and what should stay out of the first engagement?

Three categories deserve extra caution.

The first is anything that outsiders can write into. An email from a stranger, a web form or a scraped page can contain text that tries to instruct the agent. The OWASP prompt injection prevention guidance describes this risk and the controls around it, including treating external content as data rather than instructions and limiting what the agent can do after reading it. An agent that reads outside messages and can also act on internal systems needs deliberate design, so it should not be one of the first connections.

The second is write access. Reading a document and changing a record are different levels of trust. Start read-only, and when a write action becomes worthwhile, grant it for one defined task with an approval step. The OWASP authorization guidance recommends least privilege and denying by default, and that is a sound rule for agents: each connection gets its own identity with only the access the role needs.

The third is data that is simply not needed yet. Payroll, HR files, legal matters and credentials rarely help a first role and carry the most downside. Passwords and keys should never sit in documents the agent can search. Where personal data is involved, settle two questions before connecting anything: whether your provider trains on your company data, and where that data will physically live.

One more item belongs on the wait list: the entire shared drive. It feels generous, but it mixes current and obsolete files, drafts, personal folders and sensitive documents, and nobody can later say what the agent was allowed to know.

What is a practical step-by-step plan for the first connections?

Use this sequence for each source, one at a time.

• Write down the questions and tasks the role must handle in its first weeks.
• List every source that would help answer them, with the person who owns each one.
• Score each source for value and exposure using the questions above, and choose the highest value, lowest exposure source first.
• Clean that source before connecting it: remove outdated and duplicate files, take out anything sensitive, and confirm who maintains it.
• Connect it read-only through a dedicated identity limited to the specific folder or view. Where the system supports it, use standard delegated authorization such as OAuth 2.0 with narrow scopes, as described in Google's OAuth documentation.
• Test with real questions whose correct answers you already know, and record which source the agent used for each answer.
• Review the access logs for surprises, such as files retrieved that you did not expect.
• Add the next source only when the previous one behaves well, and repeat the cycle.
• Put a recurring access review on the calendar so that connections do not outlive their purpose.

The review in the final step is covered in more depth in how to run a permission review for your AI agents.

What does this look like in practice? An illustrative scenario

This scenario is illustrative, not a description of a real company. A small logistics services firm wants an agent to help its operations coordinator answer routine status questions and draft replies.

The coordinator's team lists its candidate sources: the operating procedures, the service descriptions, a library of reply templates, two years of closed tickets, the customer relationship system, the finance system, the shared inbox and the full company drive.

The first connection is the procedures and service descriptions, after an owner removes pages that describe a retired process. The second is the reply templates and tone guide. The third is the closed tickets, after a review removes names and contact details. The fourth is a read-only view of shipment status fields from the customer system, not the full customer record.

The finance system stays out because the role never needs it. The shared inbox waits until the team has tested how the agent handles messages that contain instructions. The full drive is never connected.

With this order, the agent can draft answers in the company's own wording from the first stage, and each later source was added for a stated reason that someone can explain.

How does Be Human handle first connections?

A first Be Human engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. The data inventory is part of that definition: each source is ranked, assigned an owner and connected read-only through its own scoped identity. Retrievals are logged so they can be reviewed. After launch, managed operations include recurring permission reviews, and any new connection or write permission goes through an approval step rather than being added informally.

Frequently asked questions

Should I connect the whole shared drive so the agent has everything? No. A full drive mixes current and obsolete material with drafts and sensitive files, which lowers answer quality and widens exposure. Choose the folders the role actually uses, clean them, and name an owner for each.

Is it safe to give an AI agent customer data? It can be, if it comes after the lower-risk sources and is narrowed. Limit the agent to the fields the role needs, keep it read-only, confirm your provider's data handling terms in writing, and review the logs regularly. If the role can do its job without the data, leave it out.

Do I need a special database or technical setup to connect documents first? Usually not at the start. Retrieval over a small set of curated documents is a common pattern, and the choice of mechanism matters less than the quality of the content and the narrowness of access. Get the sources and permissions right first, and refine the technology as the role grows.

How do I know the first connection is working? Test with questions whose answers you already know, and check that the agent cites the right source. Compare results against the success criterion you set for the role, and have the source owner review a sample of answers. If the agent is wrong, fix the document or the access before adding anything new.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.