Artificial intelligence is rapidly moving from being a passive assistant to an active participant in the workplace.
For the past few years, most enterprise AI conversations have focused on productivity: summarising meetings, drafting documents, finding information, writing code and helping staff work faster. That is still true. Tools such as Microsoft 365 Copilot can deliver real value when they are properly governed and deployed.
But a new class of risk is emerging.
The issue is no longer just, “What data might an employee paste into an AI tool?”
The more important question is becoming, “What can the AI agent access, retrieve, connect to, execute or expose on the user’s behalf?”
That distinction matters. Once an AI system is connected to email, files, calendars, collaboration platforms, enterprise search, cloud services, code repositories, browsers, terminals or automation tools, it is no longer simply generating text. It is operating inside the business environment.
That creates a new security reality: AI agents need to be governed as identities, access pathways and operational actors, not just as software features.
The SearchLeak example: why this matters
A recent vulnerability disclosed by Varonis Threat Labs, known as SearchLeak, provides a useful example of the type of risk organisations now need to understand.
SearchLeak was reported as a vulnerability chain in Microsoft 365 Copilot Enterprise Search. In simple terms, the research showed how a crafted link could potentially manipulate Copilot into searching across a user’s accessible Microsoft 365 data and leaking sensitive information.
The reports described the possible exposure of emails, MFA or two-factor authentication codes, calendar details, meeting information, SharePoint content, OneDrive files and other indexed corporate data. Microsoft has reportedly patched the issue, and public reporting indicates there was no known exploitation in the wild.
That is important context. This is not a reason to panic, and it is not a reason to abandon Copilot or enterprise AI.
But it is a very clear warning.
The risk was not simply that an AI chatbot said the wrong thing. The risk was that an AI-enabled enterprise search capability could be influenced to retrieve sensitive information from systems the user was already authorised to access.
That is the heart of the problem. AI agents inherit, amplify and operationalise access.
Why AI agents change the security model
Traditional enterprise security is built around users, applications, devices, networks and data stores. A user signs in, accesses a system, performs an action, and those actions can usually be logged, monitored and controlled.
AI agents complicate that model.
An AI agent may act on behalf of a user. It may search data, summarise content, call tools, follow links, generate code, create documents, send messages, interact with APIs or run commands. In more advanced cases, it may be given access to a browser, terminal, workflow engine or automation platform.
That creates several important security challenges.
First, the agent may have access to a large amount of information because it is operating with the user’s permissions. If the user can access thousands of emails or hundreds of overshared SharePoint sites, the agent may be able to retrieve and reason across that same material.
Second, the agent may be vulnerable to prompt injection. Prompt injection occurs when untrusted content gives instructions to the AI system in a way that overrides or manipulates the intended task. This can happen through emails, documents, web pages, links, files, tickets, chat messages or other content the AI consumes.
Third, AI agents can blur the boundary between data and instruction. To a human, a malicious instruction hidden inside a document may obviously be content. To an AI system, that same text may be interpreted as something it should follow.
Fourth, agents can operate at machine speed. A person might slowly search, open, copy and send information. An agent can potentially retrieve, summarise, combine and transmit data much faster.
Fifth, traditional controls may not provide enough context. A log entry showing that Copilot searched for a document, or that a user accessed a file, may not immediately reveal whether the action was genuinely intended by the user, triggered by a prompt injection, or caused by a malicious workflow.
This is why AI security needs to move beyond acceptable use policies and awareness training alone.
The problem is not just Copilot
It would be easy to look at SearchLeak and treat it as a Microsoft-specific issue. That would be a mistake.
Microsoft 365 Copilot is simply one of the most visible examples because it is deeply integrated into enterprise productivity environments. The broader issue applies to any AI agent or assistant that can access business data or perform actions.
This includes AI coding assistants, browser-based agents, workflow automation agents, customer support bots, internal knowledge assistants, security copilots, data analysis agents and any system connected to APIs, cloud platforms or internal tools.
The same risk becomes even more serious when agents are granted terminal access, stored credentials, long-lived tokens, API keys or broad service permissions.
At that point, the question is not just “Can the AI answer a question?”
The question becomes “What could happen if this agent is manipulated?”
Could it read sensitive files? Could it search mailboxes? Could it access HR data? Could it query customer records? Could it create tickets? Could it run scripts? Could it modify cloud resources? Could it send information externally? Could it make decisions that affect real business operations?
Those are governance questions, not just technical questions.
The specific risk of terminal access and stored credentials
Terminal access is particularly sensitive because it gives an agent a direct path into the operating environment. A terminal can be used to inspect files, run commands, install packages, call APIs, connect to servers, manipulate code, query logs, change configurations or interact with cloud tooling.
Stored credentials make this even more dangerous.
If an agent has access to API keys, SSH keys, cloud credentials, database credentials, personal access tokens or service account secrets, then a prompt-injection attack or agent failure may become a real operational compromise.
This is not theoretical. Many organisations are experimenting with AI agents that can perform development, operations, cyber security or administrative tasks. These agents may be connected to GitHub, Azure, AWS, Google Cloud, Slack, Jira, ServiceNow, Microsoft Graph, internal APIs, CI/CD pipelines or local command-line tools.
The more tools an agent can use, the more powerful it becomes.
The more powerful it becomes, the more governance it needs.
The core security principle: treat AI agents as privileged actors
A useful mental model is to treat an AI agent like a highly capable but untrusted junior administrator.
It can be helpful. It can save time. It can perform repetitive work. But it should not be given unlimited access, unsupervised execution rights or the ability to handle sensitive data without controls.
Organisations should treat AI agents as a new class of identity and access risk.
This means asking:
- What identity does the agent run as?
- Whose permissions does it inherit?
- What data can it retrieve?
- What tools can it call?
- What actions can it perform?
- Can it access the internet?
- Can it execute code?
- Can it use a terminal?
- Can it read secrets?
- Can it send data externally?
- Are its actions logged clearly?
- Can we distinguish human action from agent action?
- Can we revoke, isolate or disable it quickly?
If these questions cannot be answered, the organisation does not yet have adequate AI agent governance.
How organisations should combat this risk
The answer is not to block AI adoption. That is unlikely to be practical, and in many cases it would simply push usage into unmanaged channels.
The better approach is to govern AI agents properly from the beginning.
1. Start with data governance
AI agents are only as safe as the data environment they operate in.
If SharePoint, OneDrive, Teams or internal file shares are already overshared, Copilot and similar tools can surface that exposure more easily. AI does not necessarily create the underlying access problem, but it can make the problem visible and exploitable at scale.
Organisations should review sensitive data locations, sharing permissions, stale access, public links, external sharing, orphaned sites and broad groups such as “Everyone” or “All Staff”.
This is especially important before rolling out AI assistants across email, files and enterprise search.
2. Apply least privilege to AI agents
Agents should only have access to the systems and data needed for their purpose.
A meeting summarisation assistant does not need access to source code. A coding assistant does not need HR records. A security investigation agent does not need unrestricted write access to production systems unless there is a very specific and controlled use case.
Least privilege should apply to data access, tool access, API permissions, cloud roles, file system access, network access, terminal access, external connectivity, and the ability to send messages or files.
Access should be narrow, time-bound and reviewed regularly.
3. Separate human identity from agent identity
Where possible, organisations should avoid having agents operate invisibly under a user’s normal identity.
Agent actions need to be attributable. If an AI agent searches a repository, creates a ticket, sends a message or runs a command, logs should make it clear that the action was agent-assisted or agent-executed.
This matters for audit, investigation, non-repudiation and incident response.
4. Control terminal and code execution carefully
Terminal access should be treated as a high-risk capability.
If an AI agent can run commands, it should be placed inside a restricted environment with strong isolation. That may include sandboxing, containerisation, allow-listed commands, restricted file access, no access to secrets by default, limited network egress and human approval for sensitive operations.
5. Protect secrets from agent access
Secrets should not be sitting in plain text where agents can read them.
This includes API keys in documents, credentials in scripts, tokens in chat messages, passwords in knowledge bases, keys in code repositories and secrets stored in local environment files.
6. Defend against prompt injection
Prompt injection is one of the most important security issues in AI-enabled systems.
Organisations should assume that agents will encounter malicious or untrusted content. This may appear in emails, documents, websites, PDFs, tickets, chat messages, code comments, pull requests or knowledge base articles.
7. Monitor agent behaviour
Security teams need visibility into what AI agents are doing.
Useful monitoring questions include: What did the agent access? What did it retrieve? What tools did it invoke? What prompts or inputs influenced the action? Did it access sensitive data? Was a human approval step involved?
8. Add human approval for high-risk actions
Not every AI action needs human approval. But high-risk actions such as sending external emails with sensitive content, running terminal commands, modifying production systems or accessing highly sensitive data should require explicit confirmation.
9. Red-team AI workflows before broad rollout
AI agents should be tested like any other high-risk technology. This includes prompt injection attempts, malicious documents, crafted links, overshared data scenarios, tool misuse, data exfiltration paths and privilege escalation attempts.
10. Build an AI agent register
Most organisations have asset registers, application registers and privileged access registers. They now need an AI agent register.
This should capture: agent name, business owner, technical owner, purpose, connected systems, data access, tool access, identity model, permissions, external connectivity, logging coverage, approval requirements, risk rating and review date.
What this means for Microsoft Copilot adoption
Microsoft 365 Copilot can be valuable, but it should not be treated as a simple productivity add-on. It sits across email, files, meetings, chat and enterprise knowledge. That makes governance essential.
Before enabling Copilot widely, organisations should review SharePoint and OneDrive permissions, Teams sprawl, external sharing settings, sensitivity labels, data loss prevention rules, Purview configuration, conditional access, insider risk controls, audit logging, Microsoft Graph permissions, privileged roles, user training, incident response playbooks and third-party plug-ins and connectors.
The key point is that Copilot will often reflect the state of the existing Microsoft 365 environment. If the environment is clean, well-labelled and well-governed, Copilot is easier to secure. If the environment is messy, overshared and poorly monitored, Copilot may expose those weaknesses.
The cultural challenge
There is also a human and organisational side to this.
Many staff see AI assistants as helpful, friendly and authoritative. That can create over-trust. People may assume that if an AI tool is provided by a major vendor, it must be safe in every context.
Security teams need to communicate a more balanced message.
AI is powerful and useful, but it is not magic. It does not remove the need for access control, data classification, monitoring, approval workflows or cyber hygiene.
The bigger lesson
SearchLeak will not be the last AI agent security issue.
The lesson is not that Microsoft 365 Copilot is uniquely unsafe. The lesson is that enterprise AI is becoming deeply connected to business systems, and that changes the threat model.
AI agents sit at the intersection of identity, data, automation and decision-making. That makes them valuable, but it also makes them attractive targets.
The organisations that benefit most from AI will not be the ones that simply enable every feature as quickly as possible. They will be the ones that pair adoption with governance, visibility and control.
AI agents should be treated as powerful digital workers. They need job descriptions, access limits, supervision, audit trails and clear accountability.
That is how organisations can unlock the benefits of AI without sleepwalking into a new class of security risk.