Connect a calendar tool and the agent can see your schedule. Connect an email tool and it can read your inbox. The boundary of what the agent can see is determined entirely by which tools you have authorized and with what scope.
How permissions gate access
AI agents interact with external systems through discrete tools: a calendar integration, an email integration. Each tool is backed by a permission grant, typically via OAuth, the same delegated authorization mechanism most app integrations use. When you authorize a tool, you are granting a specific scope: read-only access to one calendar, or read but not send on email.
The agent works inside those declared scopes. It cannot reach beyond them. An agent connected to your calendar and nothing else cannot read your email regardless of what you ask it to do.
What the agent cannot see by default
Any system you have not connected is out of reach. Sensitive data behind an undeclared permission is never retrieved in the first place. Scoping before retrieval is a meaningfully stronger privacy guarantee than systems that fetch broadly and filter at display time.
Most agents also carry no persistent memory across sessions by default. What was accessed during one task does not automatically carry into the next unless the platform has a memory feature and you have enabled it.
The footprint of a single run
One characteristic that distinguishes agents from direct app integrations: a single task can chain multiple tool calls in sequence. An agent asked to prepare notes ahead of a meeting might read the calendar event, retrieve relevant email threads, pull a linked document, and query a project management tool within one run. Each step is individually authorized, but the combined data surface of that one task is larger than any single tool access would suggest.
NIST’s National Cybersecurity Center of Excellence made this precise in its February 2026 concept paper on AI agent identity and authorization (NIST NCCoE, February 2026): agents draw on multiple data sources within a single task and should operate with task-scoped permissions rather than broad persistent grants.
Where data goes when a task runs
During a run, retrieved data enters the agent’s context window, the working memory the model reasons over. That context clears when the task ends. The more consequential question is what the platform retains in logs: most providers record inputs and outputs for debugging and safety review. For how long and under what controls depends on the provider’s data processing agreement.
If the platform operates in the EU or processes data about EU residents, that agreement must comply with GDPR. Under Article 5(1)(b), personal data collected for one purpose cannot be repurposed for an incompatible one. This applies to agent session data as directly as to any other form of data processing.
Controlling and revoking access
OAuth grants are revocable. To remove an agent’s access to any connected service, revoke the authorization from that service’s connected-apps settings. The agent loses that data path immediately. Revoking does not erase data the agent retrieved in past sessions, but it stops all future access.
Some platforms support human-in-the-loop review points before an agent accesses a sensitive system or takes a consequential action. That positions a person as a gate before access occurs rather than as a catch-up audit afterward.
The actual risk: over-permission, not circumvention
Agents do not read more than their permissions allow. The genuine risk is different. Permissions granted once apply broadly: an email integration authorized to help with one task gives the same reach across every subsequent task the agent runs, unless scope is restricted per task. A single overly broad grant becomes a persistent exposure.
Least-privilege design addresses this directly: each run should use only the minimum scope needed for that specific task, not the full extent of the agent’s granted permissions. Narrowing individual integrations (scoping each to the minimum required rather than granting broad access) and revoking unused tool connections reduces the impact of a misused permission or a prompt injection attack, where malicious content embedded in data the agent reads attempts to redirect its actions using the permissions it already holds.
Sources
- National Institute of Standards and Technology. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization (Initial Public Draft Concept Paper). NIST NCCoE, 5 February 2026.
- European Union. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 5(1)(b). Official Journal, 4 May 2016.
Questions, answered
Can an AI agent read my emails without permission?
No. Reading email requires an explicit email tool integration, typically authorized via OAuth. Without that connection, the agent has no path to your inbox.
Does an AI agent store the data it reads?
Data passes through the agent's context window during a task. Whether the platform retains logs afterward depends on the provider's data processing and retention policy, not on the agent itself.
Can I revoke an agent's data access?
Yes. OAuth-based integrations can be revoked from the connected service's settings or your identity provider's authorized applications page. The agent loses that data path immediately.
What is least-privilege access for AI agents?
Each task should draw only on the minimum data it actually needs, even if the agent holds broader permissions overall. An agent authorized to read all email should ideally receive only the threads relevant to the current task, not full inbox access on every run.
Brief is a team of AI associates you direct in plain language. Opening to a small group at a time.
Request access