AI SOC Agents

AI SOC agents investigate alerts, follow evidence across security tools, and coordinate response within approved limits. They adapt each step to what they find and record the evidence behind their conclusions for analyst review.

Download the guide Request a demo

What AI SOC agents are

An agent is a language model working toward a goal, with tools, inside a policy. It runs as a loop: given a task, such as reaching a verdict on an alert, it calls a tool, reads the result, and decides what to do next, repeating until it has enough evidence to conclude or a reason to stop and ask a person. The model supplies the reasoning, while the tools, instructions, memory, policy, and runtime decide what that reasoning can reach and what it is allowed to change.

Term	What it usually means	Who drives each step	Typical output
AI assistant or copilot	A chat interface over security data	The analyst, prompt by prompt	Answers and drafted queries
AI SOC agent	A model running a task with tools, within a policy	The agent, from the evidence so far	A finished piece of work, such as a verdict
AI SOC analyst	The investigation agent, named for the role it fills	The agent	A case with verdict, evidence, and recommended actions
Skill	A packaged, repeatable investigation an agent or assistant runs	Defined by its author	A structured result or report

Anatomy of an AI SOC agent

An agent’s effectiveness depends on its tools, investigation skills, context, and operating controls as well as its model. The model decides what to investigate next; the surrounding platform determines what evidence it can access and which actions it can take.

Component	Purpose	SOC example
Model	Interprets evidence, tests explanations, and selects the next step.	Checks sign-in activity after finding a suspicious inbox rule.
Tools	Provide defined functions for querying data and performing approved actions.	Search sign-ins, retrieve a process tree, or revoke sessions.
Skills	Supply reusable investigation methods, evidence requirements, and escalation guidance.	Microsoft 365 sign-in forensics or an endpoint persistence hunt.
Memory	Preserves the current investigation and relevant, validated tenant context.	Recognizes a scheduled job previously confirmed as legitimate.
Policy	Defines permitted tools, tenant scope, approval rules, and execution limits.	Read-only investigation; session revocation requires approval.
Runtime	Enforces isolation, credential handling, network restrictions, and resource limits.	Allows access to approved APIs while limiting query volume and execution time.

Policies and runtime controls are enforced outside the model. Instructions embedded in alerts, logs, or emails must not be able to grant permissions or bypass approval requirements. Models, tools, skills, and policies should be versioned, tested, and reviewed when changed.

An investigation agent might have read-only access to one tenant, a defined query budget, and escalation rules for missing evidence or conflicting findings. Response actions are handled through a separately authorized workflow with its own permissions and approvals.

Investigation agentpolicy v14

Tools

search_signins get_process_tree search_mailbox revoke_sessionsResponse actions run in a separate, authorized workflow

Tenant scope

acme-corp · read only

Skills

M365 sign-in forensicsInbox rule investigation

Memory

Current case and validated tenant context

Query limits

40 queries per case · 90-day lookback · 5 min run time

Escalation

Low confidence, conflicting findings, or missing evidence → analyst

How AI SOC agents investigate

AI SOC agents open an investigation with access to live security data and rich context about the environment. They query connected tools, examine related activity, and build an evidence-backed account of what happened.

ALERTEncoded PowerShell

PAYROLL-PC-03

The agent checks the evidence

Process treeStarted by the management agent

Script contentDownloads approved software

Network destinationInternal software repository

Other devicesSame job on 40 workstations

ASSESSMENTExpected deployment

Evidence recorded for review.

An encoded PowerShell alert, for example, can prompt the agent to retrieve the process tree, inspect the script, check network destinations, and search for similar execution across other hosts. Asset details, user privileges, approved changes, and previous findings help it interpret that activity.

The investigation expands where the evidence leads. A suspicious connection may reveal another affected endpoint; an unfamiliar account may require checks of sign-ins and privilege changes. Agents connect these findings across tools rather than relying only on the original alert.

The resulting case includes a timeline, supporting evidence, query history, a proposed verdict, and recommended next steps. Missing data and conflicting findings remain visible so analysts can validate the assessment and direct further investigation.

Tools, API's, and MCP

Tools let AI agents query security data and perform authorized actions. They connect to platform services and product APIs to search sign-ins, retrieve process trees, enrich indicators, revoke sessions, or propose detection changes. Each tool defines its purpose, accepted parameters, and expected results.

Well-designed tools make investigations precise and access controllable. A sign-in search can require a specific user, tenant, and time range, returning only relevant fields. Broader search tools need additional controls over query cost, result size, and execution time.

The Model Context Protocol (MCP) provides a standard interface through which agents and analysts’ AI assistants can discover and call these tools. The platform must enforce permissions and operating limits at the server; MCP itself does not supply those controls.

Caller identity

Authenticate the caller and check whether their role permits the requested tool and operation.

Tenant scope

Enforce authorized tenant boundaries across queries, returned evidence, memory, and response targets.

Arguments and query limits

Validate parameters and constrain time ranges, result sizes, query complexity, and execution time.

Execution controls

Apply rate and concurrency limits. Require approval for actions outside the caller’s explicitly authorized autonomy.

Audit records

Record the caller, tool, parameters, outcome, and relevant evidence references, linked to the investigation case.

Customer context for every investigation

The same activity can mean different things in different environments. A large transfer may be routine for a finance reconciliation service but unusual for a staff workstation. AI agents need customer-specific context to interpret the evidence, assess its significance, and recommend an appropriate response.

Business and asset context

Asset roles, business-critical services, data sensitivity, and system dependencies help agents assess potential impact. A suspicious process on a payroll server may require different handling from the same activity on a test device.

Identity and access context

User responsibilities, privileged access, service accounts, and expected sign-in patterns help agents identify activity that falls outside an account’s normal purpose.

Expected operational activity

Approved administration tools, deployment jobs, maintenance windows, and change records help distinguish authorized work from suspicious behavior. Exceptions should have a defined scope, owner, and expiry date.

Previous investigations

Validated case findings provide useful history about users, devices, and applications. Agents can reference earlier investigations to recognize recurring activity, compare current evidence, and avoid repeating completed work.

Analyst feedback

Recorded corrections explain why an assessment changed, such as a missed indicator or misunderstood business process. Reviewed feedback can improve customer context and investigation skills without automatically treating every past decision as correct.

Context informs an investigation but does not establish that activity is safe. An agent should still check whether the current user, device, destination, timing, and behavior match the earlier explanation, and cite the records it relied on.

Customer context must remain tenant-scoped, access-controlled, and subject to retention and review. Entries need source references and validity dates so outdated tools, permissions, or business practices do not continue shaping investigations.

Guardrails for SOC agents

SOC agents read attacker-controlled content, access sensitive data, and call tools with operational permissions. Guardrails must account for both mistakes and deliberate manipulation. Controls work across several layers, so a failure in one does not give an agent unrestricted access or authority.

Investigation controls

Evidence requirements, escalation criteria, and checks for missing or conflicting data help prevent unsupported conclusions. Confidence scores support these checks but cannot establish that a verdict is correct.

Action controls

Permissions and approval rules define which actions an agent can take, against which targets, and under what conditions. Scope limits, execution caps, and recovery procedures constrain the impact of an incorrect action.

Runtime controls

Isolated execution, restricted network access, brokered credentials, and least privilege limit what an agent can reach. Query budgets, concurrency limits, and execution timeouts also protect shared systems from excessive workload.

Data controls

Tenant boundaries apply to queries, memory, case records, and response targets. Data filtering, approved processing locations, retention policies, and model service terms govern how customer information is handled.

Human oversight

Analysts approve material actions, review investigation quality, and investigate incorrect closures or unintended behavior. Authorized staff can suspend individual workflows and return affected cases to manual handling.

Queries, relevant results, verdicts, actions, approvals, and policy events are recorded with the case. Protected audit logs preserve the history for review and export.

Protecting against prompt injection

Attackers can place instructions inside content an agent examines. A scheduled task description might claim that suspicious activity is approved maintenance, or a phishing email might tell an AI reviewer to mark it safe. The attacker only needs their content to reach the investigation.

Agents must treat that content as evidence, with permissions and execution policies enforced outside the model. Suspected manipulation should be flagged for review, while the verdict remains grounded in the underlying activity. An injection attempt is a suspicious finding; it does not, by itself, establish the full incident verdict.

Testing the guardrails

Controls need validation during deployment and after material changes to models, tools, skills, or policies. Tests should use an authorized environment and produce an inspectable audit record.

Test malicious instructionsPlace instructions in test telemetry asking the agent to close a case or ignore evidence. Confirm that the assessment follows the evidence and that unauthorized actions cannot execute.

Test credential and network boundariesAttempt to induce secret disclosure or access to an unapproved destination. Confirm that credentials remain protected and prohibited requests are blocked and recorded.

Test execution limitsExceed configured query, concurrency, or response-action limits. Confirm that excess work is stopped, queued, or held for approval, and that the event is recorded.

Test missing contextDisconnect a source a workflow depends on. Confirm that affected cases are escalated with a clear statement of the missing evidence.

Test recovery and suspensionRun a documented rollback on a test identity, then suspend one workflow. Confirm that the action is reversed and the remaining workflows continue.

Building your own skills

Skills capture investigation methods that agents and analysts can reuse. Each defines the objective, relevant tools, evidence to collect, checks to perform, and expected output. Agents apply that guidance while following findings that need further investigation.

Start with work your team repeats: Microsoft 365 account investigations, endpoint persistence checks, vendor remote access reviews, or hunts based on a recent advisory. Document how an experienced analyst approaches the task, including legitimate explanations, evidence gaps, and escalation criteria.

Test the skill against known cases before release. Keep instructions and queries in version control, assign an owner, and review updates as tools, threats, and customer environments change. Query scope and resource limits should be part of the design.

Evaluating AI SOC agents

Evaluate agents on representative investigations with verified outcomes. Analyst agreement is useful, but investigation quality also depends on evidence completeness, missed threats, incorrect closures, and appropriate escalation.

Build a test setSelect historical cases covering confirmed attacks, legitimate activity that looks suspicious, ambiguous findings, missing data, and prompt injection attempts. Include enough examples to assess each important alert class.

Run without response actionsLet the agent investigate in recommend-only mode using evidence available at the time of each case. Compare its findings, verdict, and escalation decision with the verified outcome.

Review disagreementsDetermine whether each difference came from unavailable data, incorrect queries, misinterpreted evidence, an unsupported conclusion, or an inaccurate reference label. Record the impact, especially where an attack was incorrectly classified as benign.

Retest material changesRepeat evaluations after changes to models, skills, tools, or policies. Check for regressions and variation between runs, including query cost and execution time.

Resolve significant gaps before expanding autonomy. In production, continue reviewing sampled closures and escalated cases, using findings to improve skills and controls. Incorrect closures need particular attention because they may never generate another alert.

The ThreatDefence AI SOC platform

ThreatDefence connects AI agents to the security tools you already use, providing one operational layer for triage, investigation, response, threat hunting, and detection engineering. The platform supports self-managed, managed, co-managed, and white-label delivery.

The ThreatDefence Auto Triage dashboard showing AI-investigated alerts, automatically resolved benign cases, evidence-backed escalations, and verdict distribution

The platform integrates with your existing security stack and provides native capabilities you can add as your needs grow:

Brand protection

Dark web monitoring

Attack surface management ITDR NDR Cyber risk management AI governance

Operating modes

Workflows support recommend-only, approval-required, or autonomous operation within approved limits. Customers authorize increases in autonomy, every change is recorded, and individual workflows can be suspended immediately.

Agent runtime

Agents run in isolated sandboxes based on OpenShell, governed by declarative policies maintained in version control. Network access is restricted to approved destinations, and credentials are represented to agents as placeholders rather than exposed secrets.

Data regions

The platform operates in Australia and the United States, with customer data and AI processing remaining in the designated region. Model requests are filtered and anonymized before submission. Enterprise model terms exclude training on customer data, and customer data is never used to train shared models.

Compliance support

The platform supports security operations aligned with applicable SOCI Act obligations. Essential Eight reporting provides visibility into assessed controls and areas requiring improvement.

Quality reporting

Senior analysts review investigation quality and sample AI-closed alerts. Monthly reporting tracks analyst agreement, verdict overrides, incorrect closures, and reversed automated actions, with metrics also available in the portal’s SOC performance views.

Tools for analysts and partners

Analyst AI assistants

Analysts can use their own AI assistants to investigate through the platform. Plugins for Claude and OpenAI connect to tenant data and tools through the ThreatDefence SOC MCP server, enforcing authorized roles and tenant access while logging every tool call.

Skills library

The updatable skills library covers endpoint behavior, persistence, Microsoft 365 investigations, data exfiltration, network anomalies, exposure, leaked credentials, and threat hunting. Authorized MSP and MSSP analysts can also search across client tenants within their assigned permissions.

White-labeled for partners

MSPs and MSSPs can deliver the platform under their own brand, with shared case access for co-managed investigations and procedures and autonomy configured per client. Investigation skills developed by a partner remain that partner’s intellectual property.

See the ThreatDefence AI SOC in action

Faster investigations. Clear evidence. Coordinated response.

By submitting this form, you accept the terms in our privacy policy.

Frequently Asked Questions

What are AI SOC agents?

AI SOC agents investigate alerts, query connected security tools, and coordinate response within approved limits. Their findings include supporting evidence and recommended next steps for analyst review.

How do AI SOC agents investigate an alert?

Agents retrieve related activity, apply customer context, and follow findings across systems. They build a case containing evidence, a timeline, query history, and a proposed verdict, highlighting missing data and unresolved questions.

How do AI SOC agents differ from AI assistants?

An assistant usually works through an analyst-led conversation. An agent can carry out an assigned investigation without a prompt for every step. The capabilities overlap: an analyst’s assistant may also use agents and investigation tools.

What makes up an AI SOC agent?

A model, tools, investigation skills, memory, policies, and runtime controls. Together, these determine how the agent investigates, what context it uses, and which data and actions it can access.

What is an MCP server in a SOC?

An MCP server provides a standard interface for agents and AI assistants to discover and call security tools. The platform enforces access permissions, tenant boundaries, execution limits, and logging around those calls.

Can AI SOC agents take response actions?

Yes, when explicitly authorized. Actions follow configured approvals, target restrictions, and execution limits. Investigation access does not automatically grant permission to change systems.

How are agents protected against prompt injection?

Alerts, logs, and emails are treated as untrusted evidence. Permissions and action controls are enforced outside the model, supported by input handling, security testing, and monitoring for attempted manipulation.

How do you evaluate AI SOC agents?

Test representative cases with verified outcomes and review evidence quality, incorrect closures, missed escalations, and analyst corrections. Repeat testing after material changes and continue quality reviews in production.

Do AI SOC agents replace analysts?

Agents reduce manual evidence gathering and routine investigation work. Analysts direct complex investigations, validate findings, authorize material actions, and remain accountable for decisions.