Your Employee's AI Assistant Has Your Email Open: Managing the Agents Now Connected to Your Business

AI assistants are moving beyond answering questions. With permission, some can read and send email, work with files, schedule meetings, and browse connected services. That makes the key security question less about what an employee might paste into a chatbot and more about what an agent can do inside company accounts.

A connected assistant may hold delegated access to the real inbox, calendar, or cloud drive of the person who approved it. If the account belongs to an executive, that reach could include sensitive financial, personnel, customer, or strategic information. For a business owner, the practical questions are straightforward: Who connected which tools, what can they access or change, and how would you know if something went wrong?

Recent security research offers reasons to ask those questions now. It does not mean every AI product is unsafe. The specific issues described below were disclosed and resolved by their vendors. The broader lesson is that an agent can act with permissions granted in good faith, and those permissions need to be managed like access to any other business system.

The risk changed when AI started taking action

Traditional chat tools generally respond to what a person types or uploads. An agent connected to company services can take actions through those services, using access authorized by the employee. Depending on its permissions, it might read messages, edit or delete files, or send information.

That creates a larger exposure than an employee accidentally sharing a confidential sentence with a chatbot. A connected agent can be exposed to sensitive content as part of its normal operation. It may also encounter untrusted instructions inside an email or document and act on them.

In September 2026, Check Point Research described a flaw in ChatGPT that let a hidden channel pass tasks between separate accounts. In a demonstration, the victim’s session retrieved data from the victim’s connected Gmail during an otherwise ordinary-looking interaction. The attack’s reach was limited to what the victim had already connected. OpenAI confirmed that the specific internal instance involved had been decommissioned. Read Check Point Research’s findings.

In October, Salt Labs reported that a single email containing hidden malicious instructions could hijack the Manus agent in its test scenario. Researchers found that the agent ran attacker-controlled code in its environment, where OAuth tokens for connected services (including Gmail, Drive, and GitHub) were exposed. The issue has since been resolved. Salt’s central warning: a guardrail that alerts only after an action has run may be too late for an autonomous system. Read Salt Labs’ research.

Reco’s October research focused on consumer agents connected to company Google Workspace and Slack environments, sometimes by executives. Among its reported observations: one Grok app performed about 1,700 Drive actions over six weeks, including file changes and deletions; researchers also identified roughly 200 Drive reads by agents connected through people outside the file-owning organizations. Reco found broad grants that remained active despite no recorded file activity, describing them as “dormant agent debt.” Read Reco’s findings.

These are different findings involving different platforms. Together, they show why businesses should focus on access and activity, not just an AI tool’s brand or whether an employee intended to use it for work.

Identify: Find out what has been connected

Start by reviewing connected applications in the administration consoles for the services your company uses. In Google Workspace, check API access controls and app access lists. In Microsoft Entra ID, review enterprise applications and OAuth consent. Entra audit logs can help surface events such as “Consent to application” and “Add service principal.” Review Slack app installations and permissions as well.

Look for consumer AI assistants and integrations employees may have connected themselves, not only tools formally approved by IT. Remember that a person may have linked a personal account or used a personal device to access work services. Where appropriate, ask employees and executives directly about AI tools they have connected to company accounts.

Distinguish between signing in to a tool with company single sign-on (SSO) and granting it access to company data. SSO may let an employee sign in; OAuth consent can separately authorize an application to read or change data. Those are different permissions and should be assessed separately.

Quantify: Understand the possible business impact

For every connected agent, record which services and data it can reach: email, calendar, files, messages, or other business applications. Then check whether its access is read-only or includes actions such as sending, editing, deleting, or sharing.

Ask what sensitive information sits within that reach. Consider customer records, contracts, payroll information, financial forecasts, credentials, and confidential correspondence. An executive’s account may have access to a much wider range of sensitive material than a junior employee’s account, so the potential impact can differ significantly even when the same tool is involved.

Do not dismiss an authorization because it appears inactive. An unused grant may still be valid, and it can become relevant if the agent or its vendor is compromised. A lack of recorded activity is not the same as a lack of access.

Mitigate: Reduce unnecessary access

Restrict self-service OAuth consent for business accounts. Use an allowlist for vetted applications and require administrator approval for others. In Microsoft Entra ID, review whether end-user consent for third-party multi-tenant applications should be disabled or limited to approved workflows.

Apply least privilege: provide only the data and actions needed for a legitimate business purpose. Where possible, use read-only access or purpose-built enterprise tools that provide administrative controls and audit logs. Avoid giving a consumer agent broad access to email, files, and calendars simply because those connections are convenient.

Treat SSO and data authorization as separate decisions. An employee being able to sign in to a service does not automatically mean that service should have permission to read company mail or modify files.

Review external file-sharing settings, particularly “anyone with the link” access. Blocking an agent inside your own tenant does not prevent an external partner’s agent from reading a file that your organization has made accessible through a link. Reco reported that agents connected by people outside the file-owning organizations could read externally shared files. Tightening sharing rules can reduce that exposure.

Also review vendor data-retention terms. Revoking an OAuth token can stop future access through that grant, but it does not necessarily delete information the vendor has already received or stored. Make sure employees understand the company’s rules before they connect personal AI agents to corporate accounts.

Finally, be clear about what multi-factor authentication (MFA) does, and does not, protect. MFA helps protect the sign-in process. Once an employee has approved an application and it holds an authorized token, the agent can use that access without asking the employee to sign in again. MFA does not, by itself, limit what the token can do or prompt the user before each action.

Monitor: Keep track of changes and activity

Connected apps and permissions change over time, so make reviews recurring rather than one-time. Re-audit applications and granted scopes periodically, and set alerts for new OAuth consents, newly added service principals, or changes that expand an application’s access.

Review audit logs for activity that could have a meaningful business impact: unusually large file operations, unexpected edits or deletions, new Slack app or bot registrations, and activity from a grant that had been dormant. Also decide who is responsible for responding when an unfamiliar app or unusual action appears.

Some conventional access controls may not give a complete view of an agent’s behavior. For example, API activity can come from the AI vendor’s cloud infrastructure rather than the employee’s device. That means device-based policies alone may not tell you which user-authorized agent is acting. Review application consent, scopes, and SaaS audit logs as part of the same process.

Put the permissions, not the promise, at the center

AI agents can save time, but a business should know what each connected tool can reach and change before that access becomes routine. The appropriate response is not necessarily to block every assistant. It is to identify the connections, understand their potential impact, reduce unnecessary access, and monitor what happens next.

The ChatGPT and Manus flaws described above were disclosed and resolved by their vendors. The point is not to single out those products. It is to recognize a broader pattern: when an agent receives access to business accounts, its permissions can carry business consequences, whether the cause is a software flaw, a compromised vendor, or instructions hidden in content it reads.

For practical guidance on business technology and security, visit B&R Computers’ resource library. To review how connected apps fit into your company’s wider risk picture, request a Business Review or Strategy Session.