The research, published by Exabeam and reported by SecurityBrief Australia, surveyed 600 security and finance decision-makers at organizations with at least 500 employees in the United States, Canada, the United Kingdom, France, Germany, the Netherlands and Australia. Among security leaders, 48% named AI agents as the largest current threat, compared with 28% for external threat actors and 12% each for compromised and malicious insiders.
That ranking is striking chiefly because it recasts the insider category. An AI agent is not necessarily malicious, and it does not need to be hacked to cause damage. It can operate with legitimate credentials, access files and APIs it was provisioned to use, and take a series of technically authorized actions that no person intended when the workflow began.
Exabeam’s survey identifies a perception shift, not an incident census
Exabeam defines the risk around goal-driven autonomous systems rather than ordinary chatbots. That distinction is important. A chatbot that drafts an email or summarizes a Teams meeting has a much smaller operational footprint than an agent that reads SharePoint content, opens service tickets, runs Power Automate workflows, queries a database, calls Microsoft Graph and sends messages or changes records without a user approving each step.
The survey’s 48% figure is therefore best read as a measure of where decision-makers see their exposure concentrating. It does not establish that AI agents are responsible for more breaches than external attackers, nor does it disclose a comparable count of agent-caused security incidents. Exabeam’s public summary emphasizes the findings and its own security-monitoring approach, but it does not provide the survey fieldwork dates, respondent-selection method, weighting, margin of error or full questionnaire.
Those omissions do not invalidate the survey. They do mean the numerical ranking should be treated cautiously, especially when it is being used to support spending decisions. A vendor-sponsored survey can show that a concern is widespread among its chosen audience; it cannot, by itself, quantify the probability that a particular Copilot Studio agent, Azure-hosted agent or third-party automation will be compromised.
The core concern nevertheless matches the direction of official security work. In May, CISA and partner agencies including the NSA, the UK National Cyber Security Centre, Australia’s ACSC and Canada’s Cyber Centre issued joint guidance on adopting agentic AI services. Their guidance warns that autonomy and interconnected access can produce privilege escalation, unintended behavior and accountability gaps, and it recommends limiting agents’ access to sensitive data and critical systems.
NIST has reached a similar conclusion. Its 2026 work on AI-agent security identifies the need to constrain and monitor agent access in deployment environments, while its proposed work on software-agent identity and authorization focuses directly on identification, authorization, auditing and non-repudiation. The industry argument is no longer that agents require a wholly separate security discipline. It is that conventional identity and monitoring practices must work at the speed, scope and delegation model of autonomous software.
The dangerous agent is often a legitimate one
The most useful way to think about agent risk is as a non-human identity problem. Enterprises already know the pattern from service accounts, API keys, scheduled tasks and automation runbooks: access created for one limited purpose expands over time, credentials become long-lived, ownership becomes unclear, and the account eventually holds more privilege than its current job requires.
AI agents add two complications. First, their actions can vary based on unstructured input, including documents, emails, web pages, ticket text and retrieved knowledge. Second, agents may combine otherwise harmless permissions across several systems. Read access to a mailbox, a document repository and a customer database may sound routine when reviewed separately; combined with the ability to send mail or invoke a workflow, it can enable large-scale data disclosure or convincing business-email fraud.
Prompt injection is one route to that outcome, but it is not the whole issue. An agent can make a harmful decision without being directly compromised if its goal, source data, connected tools or approval boundaries are poorly designed. A customer-service agent instructed to resolve requests quickly, for example, may disclose information through an overly broad retrieval connection. A coding agent with a repository token and deployment capability may turn a flawed or manipulated instruction into a production change.
Microsoft’s recent security guidance frames the same operational problem in identity terms. Microsoft says agents should receive a lifecycle-managed identity, explicit roles, tightly scoped permissions and a preconfigured set of permitted tools. Its documentation also warns that broad roles, shared keys and incomplete authorization checks make it difficult to disable an agent cleanly during an incident.
For Windows and Microsoft 365 administrators, the immediate question is not whether an agent has a polished conversational interface. It is whether the agent has a distinct identity, a named owner, a defined business purpose, bounded access, and an audit trail that links every consequential action back to the initiating request and authorization context.
Monitoring alone cannot reconstruct intent
Exabeam reports that 60% of respondents use dedicated AI-security or governance tools, while 56% extend existing SIEM or detection platforms and 56% use behavioral monitoring and baselining. Yet 27% identify limited behavioral context and correlation as their largest monitoring weakness.
That gap is credible, and it exposes a limitation in many early deployments. Logging an individual Microsoft Graph call, a SharePoint file read or an Azure API action is useful, but it does not necessarily show why the agent did it, which user or workflow delegated the authority, what input influenced the decision, which tools were called before and after it, or whether the action matched the approved task.
An investigation needs to answer more than “which service principal accessed this file?” It needs to establish the chain: which agent acted, which human or process invoked it, which model or workflow version was running, what tools and data sources it could reach, what policy decision allowed the action, and whether it delegated work to another agent. If the organization cannot assemble that sequence promptly, it has telemetry rather than accountability.
This is why an existing SIEM remains relevant but may need new data sources and correlation rules. Security teams should capture agent registrations, identity changes, consent grants, delegated permissions, token issuance, tool calls, retrieval sources, workflow execution, data-access events and high-impact outputs. They should also retain a versioned record of the agent configuration. A change to an agent’s tools, instructions, connector permissions or model can materially change the risk profile without changing the agent’s name.
Start with permissions and kill switches, not behavior analytics
The Exabeam survey’s emphasis on behavior monitoring may encourage organizations to buy more detection tooling before they fix the access model. That would reverse the order of importance. Least privilege is the control that reduces blast radius before an alert arrives. Behavioral detection is necessary, but it is a compensating control if an agent can already read every document library, modify production records or act as a highly privileged user.
Administrators deploying agents in Microsoft environments should establish several controls before permitting autonomous actions:
- Give every agent its own managed identity or equivalent non-human identity; do not let multiple agents share a generic service account, API key or administrator credential.
- Scope permissions to a defined task and resource set, and use read-only access by default. Write operations, external communications, financial changes, privilege changes and bulk data exports should require a separate approval boundary.
- Bind agents to an explicit allowlist of tools, connectors and APIs. An agent should not gain broad Microsoft Graph, SharePoint, Exchange or Azure access merely because a developer might need it later.
- Record a business owner and technical owner for every agent, along with its data sources, delegated permissions, connected systems and retirement date. Ownerless agents should be disabled until someone accepts accountability.
- Test whether the agent can be stopped quickly. Revoking a user-facing license or disabling an interface is insufficient if persistent tokens, shared secrets, downstream automations or cached credentials can continue to execute actions.
- Build detection around unusual sequences and privilege use, not only unusually high event counts. An agent opening a ticket, accessing a sensitive SharePoint site and sending an external message may deserve investigation even if each action falls within an ordinary baseline.
Finance agreement does not close the control gap
Exabeam’s second finding is that 93% of security and finance leaders say they agree on cyber-risk tolerance, yet 55% of security leaders say they have delayed or reduced a security initiative because they could not express the risk in terms their CFO would accept. The apparent contradiction is familiar: broad agreement that cyber risk matters does not tell finance which specific control will reduce exposure, by how much, and at what cost.
Agent security may be easier to justify when framed around measurable operational questions rather than an abstract fear of AI. How many agents have access to regulated or sensitive data? How many use persistent secrets? Which can send external communications, execute writes or make changes in production? How long would it take to identify, contain and reconstruct an agent-driven incident?
Those are governance and resilience questions with a cost model. They also reveal whether an organization has expanded autonomous access before building the administrative controls that ordinary privileged accounts already require.
Exabeam’s survey is persuasive as a signal that security leaders are worried about that expansion. Its figures are not proof that AI agents are the leading source of enterprise compromise. The action for IT teams is more concrete: treat every agent that can use enterprise tools as an identity with delegated authority, restrict what it can do, and make sure its actions can be traced and stopped before “legitimate access” becomes the explanation for a preventable breach.