AI Agent Security: That AI Agent You Just Connected? It Can Read Every Mailbox in Your Organization.
Your team just found a useful new AI tool…Maybe it is an AI-powered project management integration. Maybe it is a smart assistant that connects to emails and calendars. Maybe it is an agentic platform that promises to automate workflows across Microsoft 365 or Google Workspace.
The onboarding feels simple:
- A few clicks.
- An OAuth consent screen.
- A permissions prompt.
- An administrator approves access (because the tool seems legitimate, the vendor looks credible, and the setup guide says access is required).
The risk is what many teams do not see clearly when time for approval comes around.
Depending on the permission model, that approval may not grant access to one user’s mailbox. It may grant access across the organization, without any restrictions. Which means mailboxes, calendars, contacts, files, directory information, and collaboration data can all become available to the application if broad tenant-level permissions are approved without proper scoping.
For IT leaders and security teams, this is no longer a side issue. AI adoption is moving faster than access governance in many organizations, and the gap is creating real security exposures.
If your AI tools connect to sensitive business data, start with the data layer. Learn how Arcadion helps organizations strengthen AI Data Security before new tools create unnecessary exposure.
The Explosion of SaaS AI Agents and the Permissions They Demand
Platforms like Jira, Claude, OpenClaw, and dozens of others are all building AI agents that integrate with enterprise productivity suites, Microsoft 365, Google Workspace, etc. to deliver genuinely useful capabilities such as:
- Intelligent email triage.
- Automated meeting summaries.
- Context-aware task creation.
- Workflow orchestration across multiple systems.
The value and benefits are real. The problem is the level of access many of them need to function.
An AI assistant that summarizes email needs mailbox access. A scheduling agent needs calendar access. A workflow agent may need directory context, file access, chat access, and the ability to act across multiple users or departments.
That access is usually granted through OAuth consent flows, Microsoft Graph permissions, Microsoft Entra app registrations, Google Workspace domain-wide delegation, or similar API permission models. These systems are powerful, but they are often misunderstood outside of identity, security, and cloud administration teams.
The result is a simple approval process sitting on top of a very serious access decision.
Access control should be part of the architecture, not an afterthought. Explore how Arcadion approaches AI Architecture for secure, governed, and business-ready AI systems.
The Permission Model Most Teams Misread
| Permission type | How it works | Where the risk shows up |
| Delegated permissions | The app acts on behalf of a signed-in user. It can only access what that user can access. | The risk usually follows that user’s access level. If the user has access to sensitive inboxes, files, groups, or calendars, the app may reach those too. |
| Application permissions | The app acts on its own, without a signed-in user. These permissions are usually approved by an administrator. | The risk can extend beyond one user and reach many users, shared resources, or the broader tenant, depending on what was approved. |
| Google Workspace domain-wide delegation | A service account can be authorized to access Google Workspace data across users, based on admin-approved scopes. | The risk can become organization-wide when broad scopes are approved without tight controls or review. |
In Microsoft 365, apps can use delegated permissions or application permissions. This decides whether an AI agent has access to one person’s data or a much larger part of the organization.
Microsoft separates delegated and application permissions in Microsoft Graph. Both require consent before an app can access protected data like email, calendars, files, or directory information. The problem is that consent screens often explain the technical permission, but not the business risk behind it.
This becomes a bigger concern with AI agents and automation tools.
If an AI agent is given broad application-level access, the risk may go beyond the person who connected it. It could reach shared mailboxes, executive calendars, internal files, customer records, team groups, or other data across the organization.
Google Workspace has a similar issue with domain-wide delegation. A service account can be approved to access data across users, depending on the scopes granted by administrators. Google recommends using domain-wide delegation carefully and avoiding it when narrower access will work.
The issue is not that teams ignore permissions. It is that the wording often hides the real business impact.
- “Mail.Read” sounds simple until it gives an app access to sensitive inbox data.
- “Calendar access” sounds routine until it reveals meetings, hiring plans, customer conversations, deal timelines, and leadership activity.
The wording is technical. The impact is operational.
The Access Control Gap
The tools to limit app access exist, but they are not always easy to find or apply.
In Microsoft 365, many organizations used Application Access Policies to limit app permissions to specific Exchange Online mailboxes. Microsoft now says those policies have been replaced by RBAC for Applications in Exchange Online, and new setups should use RBAC instead.
That creates a problem. Older vendor guides, setup documents, and internal processes may still point admins to the old method.
RBAC for Applications gives administrators more control. Instead of giving an app broad Exchange access, admins can limit the app to specific mailboxes. For example, an AI agent may only need access to one shared support inbox, not every mailbox in the company.
Approving the app is only one step. Security teams still need to check:
- What data the app can access
- Which users, mailboxes, or resources are included
- Whether the access is properly scoped
- Whether tenant-wide permissions were granted somewhere else
- Whether the app still needs that access over time
Google Workspace has a similar issue. Admins can restrict OAuth scopes, which helps control the type of data an app can access. But that does not always answer the bigger question: should this app have access across the whole domain, or only to certain users and resources?
This is the access control gap.
SaaS tools and AI agents are often approved faster than organizations review the permission model, limit access, and set rules for long-term oversight.
What Is Actually at Stake
When an AI-powered SaaS tool receives broad access to Microsoft 365 or Google Workspace, the exposed data can include much more than email.
| Data source | What may be exposed | Why it matters |
| Internal strategy discussions, customer communications, legal correspondence, HR messages, financial planning, sales activity, support issues, vendor negotiations, and executive communications. | Email often contains the most sensitive day-to-day business context in the organization. | |
| Calendars | Who is meeting with whom, how often, and around which business events. | Calendar metadata can reveal deal activity, board schedules, hiring plans, regulatory discussions, restructuring activity, and customer escalations. |
| Directory data | Employee names, roles, reporting lines, departments, locations, phone numbers, and group memberships. | Directory access can expose the structure of the organization and help identify privileged users or sensitive teams. |
| Files and shared drives | Documents in OneDrive, Google Drive, SharePoint, shared drives, and collaboration workspaces. | File access can expose contracts, financial records, HR documents, client files, proposals, strategy decks, and intellectual property. |
| Teams, chat, and collaboration tools | Internal conversations, project updates, decisions, links, attachments, and informal discussions. | These conversations were often never meant to leave the tenant or be processed by an external AI platform. |
The risk is not only whether the AI tool behaves maliciously. The larger issue is that a third-party platform may now process, store, transmit, or analyze sensitive organizational data under terms, infrastructure, and retention practices the organization has not fully reviewed.
For regulated organizations, this can create legal, operational, and audit risk. For every organization, it creates a basic security problem: too many tools with too much access and too little control.
The Vendor Incentive Problem
Most vendors are not hiding the permissions they request. The permissions are usually visible in the consent flow or documentation.
The issue is how the decision is framed.
Setup guides often treat consent as a basic onboarding step. The application needs access, so the administrator grants access. The risk review is left to the customer.
A vendor may explain that the integration requires mailbox, calendar, file, or directory access. What the documentation may not explain clearly is whether that access applies to one user, a group of users, or the entire tenant. It may not explain how to scope access. It may not explain whether the permission can be limited through RBAC, access policies, admin units, service account controls, conditional access, or other governance layers.
That creates a bad default.
The vendor wants adoption. The business wants productivity. The admin wants the tool to work. Security review often happens after approval, if it happens at all.
AI makes this risk harder to ignore because these tools are no longer passive integrations. They are being designed to read, summarize, classify, recommend, create, and act across business systems. That makes permission design a security priority, not a setup detail.
What IT Leaders Need to Do Now
If a tool can read mail, files, calendars, chats, or directory data, it should go through a clear review before access is approved.
Start by reviewing which applications already have access.
| Environment | What to review |
| Microsoft 365 | Enterprise applications, app registrations, Microsoft Graph permissions, admin consent grants, and Exchange Online application access. |
| Google Workspace | Domain-wide delegation, service accounts, OAuth scopes, connected apps, and marketplace applications. |
From there, confirm whether the access matches the business need. Ask clear questions:
- What data does this tool need?
- Which users, groups, mailboxes, drives, or workspaces should it access?
- Does it need tenant-wide access, or can access be scoped?
- Is the permission delegated or application-level?
- Does the vendor store or process customer data outside the tenant?
- Are AI outputs, prompts, logs, or retrieved documents retained?
- Can the organization revoke access quickly if needed?
- Who approved the app, and when will access be reviewed again?
For Microsoft 365, review RBAC for Applications in Exchange Online when mailbox access needs to be limited to specific mailboxes. Some organizations may still have older application access policies in place, but Microsoft’s current direction for new Exchange Online application scoping is RBAC for applications.
For Google Workspace, review domain-wide delegation carefully and limit authorized scopes to the minimum required. If domain-wide delegation is not needed, use a narrower access model.
Most importantly, make SaaS and AI consent part of a formal governance process. No AI tool should receive admin consent without review from IT, security, privacy, and the business owner responsible for the tool.
AI governance does not stop after launch. Arcadion supports the AI MLOps Lifecycle, helping teams manage access, monitoring, model operations, and ongoing security review.
Where Arcadion Comes In
AI tools can help teams work faster, automate tasks, and improve productivity. But they need the right access controls in place.
Without permission scoping, consent governance, and regular access reviews, a useful AI tool can become a serious security risk inside Microsoft 365 or Google Workspace.
Arcadion helps organizations review and manage this risk. Our team works across managed IT, cybersecurity, and AI implementation, so we understand both the business value of these tools and the controls needed to use them safely.
We can help your organization:
- Review SaaS and AI app permissions
- Identify high-risk consent grants
- Assess Microsoft 365 and Google Workspace exposure
- Configure access controls
- Build a governance process for future AI adoption
If your organization has connected AI-powered SaaS tools to Microsoft 365 or Google Workspace, now is the time to review what those tools can access.
Arcadion can help you find the security gaps before they become audit findings, security incidents, or uncontrolled data exposure.
Contact us to request an AI application security review from Arcadion or learn how you may benefit from an assessment and architecture review of your application.
Related Reads: