AI assistants and identity: the new attack surface
When corporate AI assistants gain access to email, documents, and systems, a new class of threats emerges that managers need to understand.
By mid-2025, corporate AI assistants have moved from experiment to standard workflow. They read email, summarise documents, answer questions from the knowledge base, draft replies. That is useful. But behind that usefulness sits a new access management layer that many companies have not yet thought through.
The problem is not that AI assistants are inherently insecure. The problem is that they receive access to data and systems, and that access is often configured quickly, without a systematic risk assessment.
What the new attack surface looks like
When an employee connects an AI assistant to their corporate email or to the company's document storage, they are delegating part of their permissions to that tool. The tool can read what they read, write on their behalf, or take actions in systems they have access to.
From a security standpoint, this creates several vectors:
Compromise through the provider. If the AI service the assistant is connected to is breached or starts behaving incorrectly, it potentially has access to the employee's data. This is the same class of risk as any other SaaS tool compromise, but with expanded access to correspondence and documents.
Prompt injection. A new class of attack specific to AI: an attacker embeds instructions in the content of a document or email that the AI assistant reads. The assistant, following these instructions, performs unwanted actions - forwards data, creates files, takes actions in systems. From the employee's perspective this looks like normal assistant behaviour.
Excessive permissions. An AI assistant is often connected with the same permissions as the user. If the user has access to financial documents, HR documents, and operational systems, the assistant has access to all of those too. The principle of least privilege is violated by default.
What companies should do
I am not advocating for banning AI assistants - that is counterproductive. But there are several practical steps that reduce risk without sacrificing utility.
First - inventory. Which AI assistants or AI integrations are currently in use at the company, and which corporate systems are they connected to? Many companies do not have an answer to this question.
Second - a connection policy. A new AI tool with access to corporate data goes through the same minimum security review as any other SaaS. This is not bureaucracy - it is basic control.
Third - access limitation. Where possible, an AI assistant receives access only to the data needed for its tasks. If the assistant helps with customer support, it should not see financial documents.
Fourth - action monitoring. If an AI assistant can take actions on behalf of a user, those actions should be logged and periodically reviewed.
Why this is not only a technical question
The security of AI assistants is primarily a policy question, not a technical one. Technical measures - logs, permissions, monitoring - are implemented quickly once a decision is made. The harder part is this: the company needs a position on which tools, and under what conditions, can be trusted with corporate data.
That position should not be a blanket ban. But it should exist. While it does not, each employee makes this decision independently - and differently.
The question for a manager: does the company have a policy that answers "under what conditions can an AI tool access corporate data?" If not - that is a gap worth closing before an incident closes it instead.