AI agents in security operations: force multiplier or new attack surface?

In 2025, Aim Security disclosed a flaw in Microsoft 365 Copilot called EchoLeak (CVE-2025-32711) that had one particularly devious feature. A crafted email could trigger data exfiltration without a person clicking a link or opening an attachment.

When Copilot retrieved this email in the researchers’ demonstration, it followed the hidden instructions contained in it, pulling data out of the context it was trusted to access. The trust boundary failed when untrusted content became an instruction source.

Now, picture the same trust failure inside a security operations center (SOC), where AI agents can sort through alerts, run response steps, and pull together threat intelligence. Each role carries a different level of decision authority.

However, that same SOC AI agent that holds real credentials and access can become a significant threat in the hands of an attacker. Compromised workflow agents grant access to the environment, but SOC agents can have a clear view into the security stack, the very tools that are meant to catch an attacker.

• AI agents in security operations can speed up detection and response. They also hold credentials and network access that make them valuable targets in their own right.
• A compromised SOC AI agent is dangerous because the attacker gains more than access to the environment. The attacker also gains a view into the security monitoring system itself.
• Defensive AI agents need their own security program: identity controls, runtime monitoring, and deception-based detection, the same controls used for any other high-privilege system.
• Deception-based detection for SOC AI agents works on interactions with deceptive assets, exposing misuse even when the agent’s actions look legitimate on the surface.
• The benefit of SOC AI agents is real. But it comes down to the security program that makes them safe, which is what determines how much authority the agent should receive.

When a SOC AI agent is compromised, three things can happen: detection blindness, response manipulation, and forensic contamination.

Detection blindness. Whatever the agent sees, including alerts and system activity, the attacker can now see too. These attackers could watch whether they are making progress in real time, allowing them to plan each move around what the defenders are about to notice. Where permissions allow, they can also suppress or misclassify alerts.

Response manipulation. With response permissions, SOC agents can be used to ignore specific threats and instead isolate harmless systems. Attackers can use them to green-light their own moves while preventing security intervention. To anybody watching, the agent appears to be working normally, even as its authorized actions serve an attacker’s objective.

Forensic contamination. Logs and case records can be manipulated by a compromised SOC agent with write access. If the record itself cannot be trusted, the entire process of reviewing incidents may be built around incorrect information. An altered incident summary can also misdirect the investigation even when raw logs remain intact.

This is why compromising a SOC agent can have broader consequences than compromising a regular workflow agent elsewhere in the business. It is also why identity, runtime, and deception controls belong in the plan from the start, before the agent goes live. They should not get added later, once something has already gone wrong.

SOC AI agents save time and effort through features like automated alert triage, playbook execution, and threat intelligence.

For alerts, they can execute quickly and consistently, without burning out. Playbook execution can reduce handoffs, but it also delegates decisions about which systems to isolate and which credentials to revoke.

AI agents in the SOC can run threat intelligence continuously and spot connections human eyes would struggle to catch manually. Those gains should be measured alongside false closures, reopened cases, and analyst rework.

These capabilities are already running in real SOC environments today, not as a future promise. For teams stretched thin, the time saved is often the difference between catching something early and catching it after the damage is done.

Compromised SOC AI agents can grant access to your security stack when they hold credentials to SIEM, EDR, SOAR, and threat intelligence platforms. They need these credentials to support their assigned workflows, which means a compromised agent could give attackers a view of the connected security systems.

SOC AI agents can be manipulated the same way any AI agent can. Attackers can use prompt injection to insert hidden instructions for the agent to read. Supply chain compromise corrupts the agent through a manipulated dependency or integration. Excessive agency means the agent already holds more functionality, permissions, or autonomy than its actual task requires, which gives any manipulation a wider blast radius than it should have. Misconfiguration can produce the same exposure without an attacker.

The EchoLeak research showed what is possible when an AI agent gets turned against its own environment. A SOC agent could face similar manipulation while holding privileged credentials, so those non-human identities need the same scrutiny as privileged human accounts. The difference is where these credentials sit. They live inside the exact tools built to catch that kind of problem in the first place.

Setting up controls to mitigate AI agent risk does not change here, either, but you must keep the higher stakes in mind.

Start with identity controls to keep the AI agent in check by design. Implement least-privilege access, credentials set to expire quickly, and secrets manager integration.

Set up runtime monitoring so every agent API call is logged and evaluated in the context of the action sequence and assigned task, allowing you to flag unusual behavior right away, not during a post-incident review. Keep those records outside the agent’s control.

In case any gaps remain, deception-based detection can expose misuse the controls above cannot anticipate on their own. ShadowPlex Identity Protection places honeytokens where a SOC agent can reach them. Deceptive assets sit along the access paths a manipulated agent could use.

This is the same program used for any other privileged agent. What changes here are the stakes, since what a SOC agent can see and touch is the connected security monitoring stack itself.

Acalvio’s 360 Deception framework is what makes this possible. Instead of trying to recognize what an attack looks like ahead of time, it works on monitored interactions, flagging use of assets outside the agent’s assigned task.

For SOC AI agents, decoy tools such as Honey Skills can sit alongside legitimate integrations. A manipulated agent that invokes a decoy tool it has no legitimate reason to use gives a high-confidence signal something is wrong.

Decoy MCP and RAG systems provide additional detection opportunities when an agent reaches outside its assigned workflow. Their triggers should distinguish unauthorized access from routine analysis of suspicious content.

Honeytoken credentials can sit along the SIEM and SOAR access paths the agent already uses. Attempted use of one is a high-confidence signal of misuse: why did anything use a credential no legitimate process should need?

Manually maintained decoys were built with a human intruder in mind. They are harder to maintain when an agent is probing and re-probing at machine speed. ShadowPlex deploys and refreshes decoys on its own, across configured attack paths. That automation is the entry requirement for defending an agent this privileged. It is not an extra layer to add later.

None of this replaces SIEM, EDR, or SOAR. Deception simply adds a layer for a specific moment: after a SOC agent is already logged in and acting like it belongs, but is serving the wrong objective.

Given the SOC AI agent’s critical role and access, one should never go live without a formal, documented process. The process should define which actions require human approval and which may run within preauthorized playbooks.

Outside preauthorized response playbooks, human-in-the-loop review should apply to high-consequence actions such as containment, isolation, and credential revocation. For these actions, a wrong call, whether from a manipulated agent or a simple error, does the most damage. You do not need a human for every routine action the agent takes, only the high-consequence ones outside those playbooks.

You should regularly review SOC agent credentials and set a schedule for revisiting them. Just because you set it up right the first time does not mean it will not need updating as roles change.

Adversary emulation exercises should target SOC agent manipulation specifically, not just generic AI agent testing borrowed from elsewhere. The attack paths that matter most here are aimed at detection and response: getting an agent to see the wrong thing or act the wrong way, which is a different test than checking whether an agent can be tricked into leaking a document.

None of these four are optional extras layered on after deployment. They are what makes the force-multiplier case from earlier in this piece operationally sound.