← Learn

Prompt Injection in the SOC

A SOC agent reads attacker-controlled text by definition: the alert, the ticket, the sample. Injection is not an edge case there, it is the input.

can a SOC AI agent be prompt injected

A security operations centre runs on attacker-controlled text. The alert carries fields an attacker filled in. The phishing report carries the attacker's own email. The sample carries whatever the attacker put in it. When an AI agent triages that queue, indirect prompt injection is not an edge case in its input. It is the input. The defensive question is not whether the agent will read hostile instructions, because it will, on every shift. It is what the agent is able to do once it has.

Why is a SOC agent more exposed than other agents?

Most agents read untrusted text occasionally. A SOC agent reads it by design, at volume, under time pressure, and with response tooling attached.

  • The adversary chooses the text. A crafted subject line, a filename, a command line in process telemetry, a user-agent string, a comment in a malicious document: all of it flows into enrichment and into the agent's context. MITRE ATLAS calls this AML.T0051.001 Indirect Prompt Injection.
  • The adversary knows they are being triaged. Injection payloads aimed at analyst tooling are cheap to add to whatever the attacker was already sending.
  • The tools are consequential. Isolate a host, disable an account, block an indicator, close an incident, edit a detection rule. ATLAS records reaching those tools as its own technique, AML.T0053 AI Agent Tool Invocation.
  • The trifecta is the job description. Untrusted content, access to sensitive systems, and the ability to act or communicate arrive together (Willison).

Which SOC inputs are attacker-controlled?

Input the agent readsWho writes it
Alert fields: subject, filename, URL, hostname, user-agentPartly the attacker
A user-submitted phishing report, with the original message attachedThe attacker, forwarded by your own staff
Ticket and case notes ingested from a customer-facing queueAnyone who can open a ticket
Process command lines and script blocks in EDR telemetryThe attacker, verbatim
The sample itself: document, archive, script, binary stringsThe attacker
Third-party enrichment and threat-intel commentsWhoever contributed the record

There is no version of this queue with the untrusted text removed. Reading it is the work.

What would an injected SOC agent be asked to do?

The valuable instructions are the quiet ones. An injected payload that asks for something dramatic is likely to be noticed. The useful asks are the ones that look like triage.

  • Close the incident as a false positive, and note the indicator as benign.
  • Add the attacker's domain or hash to an allowlist "to reduce noise".
  • Disable or narrow a detection rule that is "generating duplicates".
  • Turn off logging or forwarding on one host during "maintenance".
  • Isolate a production host that is not the compromised one, as a diversion.
  • Post the incident's private context into a field the reporter can read.

Each is a plausible analyst action. Each is also an attacker objective, and the last one is exfiltration that never touches the network.

Why do the usual defences fit badly here?

You cannot refuse the input. Filtering the alert queue for injection patterns means dropping evidence, and the classifier reads the same undifferentiated text the model could not parse. The UK NCSC's framing applies directly: the achievable objective is "reducing the risk and impact of prompt injection", not eliminating it (NCSC).

You cannot approve everything. A SOC agent proposes hundreds of actions a shift. OWASP's agentic threat list names T10, Overwhelming Human in the Loop: an approval surface that fires constantly is itself the attack surface, because the person stops reading (OWASP). At 3 a.m., under an active incident, that is not a theoretical failure mode.

You cannot rely on the agent's own account of what it did. OWASP names T8, Repudiation and Untraceability. An incident review that rests on the acting system's log is a review of that system's claim.

What does a defensible SOC rollout look like?

Grade the actions in advance, not the text at runtime.

  1. Write the action list. Every response action the agent can reach, with the target class it applies to.
  2. Split it by reversibility. Enrichment and a revoked session for a standard account are recoverable. Isolating a domain controller, deleting logs and disabling an executive's account are not.
  3. Decide what runs unattended. Whatever you grade as routine, you have accepted the agent may do on a wrong reading of the alert. Bound it per target class and per hour.
  4. Hold the rest for named people. Few holds, high signal, on the actions nobody can take back.
  5. Refuse what no rule covers. An action outside the written list should stop and be recorded, not be improvised.
  6. Keep a record the acting system cannot edit, because that is what the post-incident review and the auditor both want.

Related reading: indirect prompt injection, containing a successful injection, and the AI SOC agents page for the same argument on the floor.

The agent read a poisoned alert. Can it still isolate the domain controller?

Only if your policy says so, and that is the layer ZIFFER is.

The agent holds no credential on your EDR, your identity provider or your firewall. It proposes an action, and the credential that performs it sits with an executor on your side of the line. An agent fooled by a poisoned ticket and an agent that is right every time meet the same table: the grade, the reversibility and the owner of the target are recomputed from your signed policy rather than read from the proposal. Routine actions run. Irreversible ones are held for a quorum of two named on-shift approvers, who sign the exact bytes that will run, and a hold nobody signs expires with nothing run. An action no rule covers is refused and recorded, which turns an injected instruction to delete logs into evidence rather than noise. Every outcome leaves a signed receipt: the alert, the policy version, the signers, what ran.

ZIFFER is not a guardrail. It detects nothing, inspects no alert text, and prevents no injection. It decides whether a proposed response action is entitled to run. See agent authorization, the agent audit trail and every refusal.

Sources

  1. OWASP LLM01:2025 Prompt Injectionhttps://genai.owasp.org/llmrisk/llm01-prompt-injection/
  2. OWASP LLM06:2025 Excessive Agencyhttps://genai.owasp.org/llmrisk/llm062025-excessive-agency/
  3. OWASP Agentic AI: Threats and Mitigationshttps://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
  4. MITRE ATLAS AML.T0051.001 Indirect Prompt Injectionhttps://atlas.mitre.org/techniques/AML.T0051.001
  5. MITRE ATLAS AML.T0053 AI Agent Tool Invocationhttps://atlas.mitre.org/techniques/AML.T0053
  6. UK NCSC: mistaking the nature of this AI vulnerability could lead to large-scale breacheshttps://www.ncsc.gov.uk/news/mistaking-ai-vulnerability-could-lead-to-large-scale-breaches
  7. Simon Willison: The lethal trifecta for AI agentshttps://simonwillison.net/2025/Jun/16/the-lethal-trifecta/