Agents In The SOC And Threat Intelligence, Done Safely.

Start with work that only reads and writes drafts: enriching indicators, linking related signals, sorting alerts and drafting reports. Keep anything that changes something, such as blocking, disabling an account or starting a takedown, behind a person's approval. NCSC gives the same advice for agentic AI in general: start small, use agents only for low-risk tasks, apply established cyber security controls from the outset, and begin with tightly bounded pilots with clearly defined tasks.

Threat intelligence is a good fit for AI agents because the work is reading and summarizing at volume. It is also risky, because the material an agent reads, such as feeds, web pages, forum posts and phishing kits, is written by or can be edited by attackers. Our threat intelligence entry explains the discipline. This article covers how to give agents a place in it without handing the attacker a lever.

NIST describes agent hijacking as a form of indirect prompt injection in which attackers embed malicious instructions into data that agents process. An agent that summarizes a hostile page is processing exactly that kind of data. MITRE ATLAS catalogs it as AML.T0051.001, indirect prompt injection, where instructions arrive through a separate data channel such as documents, emails, databases or websites.

NIST tested this. In its January 2025 evaluation, the strongest new attack succeeded against one tested model far more often than the strongest baseline attack, and repeated attempts raised the average success rate.

NCSC argues that prompt injection "may never be fully mitigated" the way SQL injection can be, because language models are "inherently confusable". Its advice is to reduce the impact. The most useful rule for a SOC is NCSC's: when an LLM processes information from a party, the privileges it has drops to that of the party. An agent reading a hostile web page should hold no more power than the author of that page. In practice, that means no write tools in the same run. For more, read prompt injection in AI agents: what works and what does not.

Match autonomy to the cost of a mistake. The Agentic Applications list from OWASP recommends least agency and per-tool profiles with set scopes, rates and allowed destinations, for example read-only database queries. For a SOC, a sensible split looks like this. It is our practical suggestion, built on that guidance.

• Agents can run on their own: look up an indicator, pull history from an incident, match a domain to your assets, group related alerts, write a draft summary with its sources.
• A person approves first: any change to an incident, a block rule, an account or a takedown request.
• Keep out of reach for now: actions that cannot be undone or that contact outside parties without review.

Give the agent the analyst's access and no more. OWASP advises executing tools in the user's context, so that the agent cannot see or do more than the person who asked. The human in the loop and least agency checklist goes through this step by step, and securing MCP servers and tool access covers the tool side.

This is an illustrative scenario for a made-up team at acme.com. Names and steps are invented to show how the limits work in practice.

The hidden line does little harm in this design. The agent has only read tools, so it cannot act on the instruction. Its draft lists sources, so the analyst can see that the claim "safe" has no support. The takedown is a change, so it waits. The log lets the team find the injection later and tune detections. If the agent had held a "mark as safe" or "start takedown" tool, the same page could have steered it.

Brandefense describes a similar pattern for its Odin analyst: it plans an investigation, shows each step, lists the sources and stops before anything changes, and it works within the access of the person asking (see Odin). The Brandefense MCP server says read-only tools run directly while tools that change data ask for confirmation. This is the pattern, not a claim that either product meets a standard.

Short answer: for now, faster and more convincing attacks, not fully automated ones. We rely here on two public assessments.

The UK NCSC assessment of AI and cyber threat to 2027 says AI will "almost certainly continue to make elements of cyber intrusion operations more effective and efficient". It expects AI to "almost certainly reduce" the time between a vulnerability being disclosed and exploited. It also judges that fully automated, end-to-end advanced cyber attacks are unlikely to 2027, with human-machine teaming advancing instead. And it warns that integrating AI into systems "almost certainly presents an increased attack surface".

The ENISA Threat Landscape 2025 says LLMs are being used to enhance phishing and automate social engineering. It reports that by early 2025, AI-supported phishing campaigns reportedly represented more than 80 percent of observed social engineering activity worldwide. ENISA also notes that attacks on the AI supply chain are on the rise, and that actors currently use consumer-grade AI tools to improve their existing operations.

What this suggests for a SOC is our own reading. Patching and exposure work has less time to wait. Phishing and lookalike detection matter more. And the agents you adopt are part of the attack surface, so the limits above apply to them.

Send the logs to your SIEM; see monitoring and logging for AI agents. For a method to run the hostile page test, see red teaming AI agents. Write the rules into your AI agent governance policy. For the wider discipline, our threat intelligence 101 guide is a good start.