What Data Should an AI Agent Be Allowed to Access?

An AI agent should access only the data needed for its assigned task, for only as long as needed, and with permissions that prevent unrelated reading or changes. Start with the least privilege: give it specific, narrow access, require approval for sensitive or consequential actions, and expand permissions only when a documented need justifies it.

Why an agent’s data access is different

A conventional search tool usually returns information in response to a person’s query. An AI agent can also take steps toward a goal: search connected services, retrieve files, send messages, update records, or call other tools. The data it can reach therefore affects not just what it can reveal, but what it might do with that information.

Access can be granted through a user account, an application programming interface (API), a shared workspace, or a service account. Each connection may expose more than a single task requires. For example, an agent asked to summarize one project document does not automatically need access to every company drive, private calendar, and customer record.

There is no universally correct list of allowed data. The right scope depends on the task, the sensitivity of the information, the agent’s capabilities, and the safeguards around its operation. A useful rule is to authorize a defined purpose and data set, not an open-ended instruction to “use whatever is available.”

Apply least privilege to data and actions

Least privilege means giving an agent the smallest set of permissions that still lets it do its job. It applies both to the data it can read and to the actions it can take. Read access to a folder is different from permission to edit or delete its contents; permission to draft an email is different from permission to send it.

Limit the scope: connect the specific folder, project, account, or record set needed, rather than an entire drive or organization.
Limit the operation: use read-only access when the task involves research or summarization. Grant write access only where changes are part of the task.
Limit the duration: use temporary access where practical, and revoke it when the task or project ends.
Separate tasks: use different permissions for routine lookup, editing, and high-impact actions instead of giving one agent broad authority for all of them.

Consider an agent that prepares a weekly project update. It may need read access to selected project notes and task status, plus permission to create a draft. It does not need access to payroll, unrelated employee files, or authority to send the update without review.

Classify information before connecting it

Organizations and individuals can make better access decisions by identifying what kinds of information a connected source contains. Labels such as public, internal, confidential, and restricted can help, but the labels need clear definitions and consistent use. A folder’s name alone is not a reliable sensitivity control.

Ordinary task data might include public reference material, a non-sensitive schedule, or the contents of a specific work document. More sensitive information includes personal identifiers, private communications, customer records, financial details, authentication secrets, and confidential business plans. Some data may be subject to contractual, organizational, or legal handling requirements; those requirements should be checked with the appropriate data owner or adviser rather than assumed.

Minimize what is shared where possible. If an agent only needs to know whether a customer’s account is active, it may not need the full account history. A system can sometimes provide a limited field, a filtered result, or a redacted copy instead of exposing the underlying record.

Match access to the agent’s task

Write down the task in concrete terms before granting access. “Help with customer support” is too broad to define safe permissions. “Find the status of this case in the support system and draft a reply using the approved help materials” is more specific and easier to restrict.

Name the outcome: specify what the agent should produce or change.
Identify necessary sources: list the files, records, or services the task depends on.
Choose the minimum permission: decide whether the agent needs to view, create, edit, send, or delete.
Set boundaries: state which data is out of scope and which actions require human approval.
Test with a limited account: check that the agent can complete the task without gaining access to unrelated information.

For example, an agent that schedules a meeting might need availability windows and the names of participants, but not the contents of their private calendar events. A carefully configured calendar connection can expose free/busy information without exposing event descriptions.

Control information returned by tools

Permissions are not the only concern. An agent may receive more information than it needs in a tool response, then include that information in a summary, prompt, log, or outgoing message. A system should filter results at the source where possible, rather than relying only on the agent to ignore irrelevant or sensitive fields.

Connected data can also contain text that looks like an instruction. A document, email, or web page might tell an agent to reveal secrets or take an unrelated action. Such content should be treated as data to evaluate, not as authority to override the task or the system’s access rules. Access restrictions should be enforced by the connected service, not merely described in a prompt.

Keep a record of which sources the agent can access and, where appropriate, what it accessed or changed. Logs support review and troubleshooting, but they can themselves contain sensitive information. Restrict log access and retention, and avoid recording secrets or unnecessary personal data.

Use approval gates and ongoing review

Human approval is most useful when an action is difficult to reverse, affects another person, or carries substantial consequences. Examples include sending an external message, changing a customer record, deleting files, publishing content, or initiating a transaction. The agent can prepare a proposed action, but a person should review the relevant details before it is carried out.

Approval should be meaningful: show the reviewer what will happen, which records are involved, and the content or changes being proposed. A general approval granted once should not silently authorize unrelated future actions. For low-risk, repetitive work, organizations may choose automated execution, but should still define limits, monitor outcomes, and provide a way to stop or reverse mistakes.

Access also needs maintenance. Review permissions when the task changes, a connected source is added, an agent gains new tools, or a user’s responsibilities change. Remove unused connections and credentials. Test that revoking access actually prevents further retrieval; deleting an agent’s visible connection may not revoke credentials held elsewhere.

Common mistakes and trade-offs

Granting access for convenience: broad access can make setup easier, but increases the amount of information exposed if the agent or its connection is misused.
Confusing read access with low risk: reading sensitive records can still expose them through summaries, logs, or later actions.
Relying on instructions alone: a prompt saying “do not open payroll files” is weaker than a system permission that makes those files inaccessible.
Leaving permissions in place: temporary projects can become permanent access paths unless someone reviews and removes them.
Assuming human review fixes everything: reviewers need enough context to identify a problem, and the agent should not be able to bypass the approval step.

Restricting access can make an agent less convenient and may prevent it from completing a task that depends on additional context. The answer is not to grant everything by default. Identify the missing data, explain why it is necessary, and grant the smallest additional permission that addresses the limitation.

Frequently Asked Questions

Should an AI agent have access to all my files?
No. Give it access only to the files or folders required for the task. Broad access creates unnecessary exposure and makes it harder to understand what information the agent can use.

Can I let an agent read data but not change it?
Often, yes. Use read-only permissions for search, review, and summarization when the connected service supports them. Confirm that the agent’s account cannot edit or delete records through another route.

Is it safe to connect an agent to email or a calendar?
It depends on the scope and actions allowed. Limit access to relevant mailboxes or calendar details, avoid exposing more content than needed, and require approval before sending messages or making consequential changes.

Should an agent see personal or confidential information?
Only when the task genuinely requires it and the access is authorized and appropriately protected. Consider redaction, filtered fields, or a limited result instead of providing the full record.

How often should agent permissions be reviewed?
Review them when the agent’s task, tools, connected sources, or responsible users change, and periodically under your organization’s access-review practices. Remove permissions that are no longer needed.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →