SecOps / AI for security operations

AI SOC agents: autonomous triage and governed response

Let agents read the alert queue, build the investigation and prepare the response, while analysts keep the authority to approve it.

A security operations center does not have a detection problem so much as a throughput problem. Alerts arrive faster than people can read them, context lives in six tools, and the response step needs a human who is already tired. AI SOC agents take the repetitive reading, enrichment and drafting work, and they act only inside limits your team sets.

Build with AI Talk to our team

The problem: the queue grows faster than the team

Most SOC time goes to work that is necessary but not interesting. An analyst opens an alert, pivots to the endpoint tool, checks the identity provider, looks up the asset owner, searches for the same indicator in last month's tickets, and writes a note. Then does it again. The judgment at the end of that chain is the valuable part, and it gets the least of the analyst's attention.

Simple automation helped, but playbooks written as rigid scripts break the moment an alert does not look like the one they were written for. Fully autonomous response is the opposite failure: an agent that can disable accounts and isolate hosts on its own, with no limits and no record of why, is a new incident waiting for a trigger. Security leaders want the speed of automation and the accountability of a person, and most tools force a choice between the two.

The answer is not a smarter model alone. It is a model inside a control system: a defined identity, a defined set of permitted actions, thresholds that route risky steps to a human, and a record of every step that stands up in a review. That is what governed agents mean in a SOC.

How Swfte runs AI SOC agents under control

SOC agents are built and run as governed agents on the platform, so the same identity, permission and audit controls apply to them as to any other agent. The sequence below is how a typical alert moves through.

Triage
The agent reads the alert, pulls context from connected sources, deduplicates against open cases and recommends a severity with its reasoning attached. At the lowest autonomy level it stops there and a person decides.
Investigation
The agent assembles the timeline: related alerts, the asset and its owner, the identity involved, recent changes and prior incidents from your knowledge base. It writes the case summary an analyst would have written, with every source cited so the analyst can check it.
Response preparation
For a confirmed or likely threat the agent prepares the response: the containment step, the affected scope and the rollback. It does not execute until policy says it may, or a person approves it.
Governed execution
Approved actions run through the runtime policy layer. Actions inside configured limits can proceed under supervision; anything beyond a threshold, such as a critical asset or a wide blast radius, escalates to a named approver.
Evidence
Every step is recorded: the alert, the data the agent read, the model used, the tools called, the policy applied, the approval and the outcome. The case closes with its own evidence trail rather than a note someone remembered to write.

Where it sits on the platform

One platform with several entry points. Each product below plays a defined part in this capability.

Platform products and the role each plays
Platform entry point	Role in this capability
SecOps Agents	The SOC agent product. Currently in beta; see the product page for status and the waitlist.
Studio	Build the triage, investigation and response agents and the workflows with approval gates between steps.
Nexus	Governs the agents: identity, in-flight policy blocking before an action executes, inventory and audit.
Connect	Reaches the tools a SOC already runs. <supported SIEM, EDR, identity and ticketing connectors - founder to fill>
Cortex	Gives agents your runbooks, asset context and past incidents as controlled knowledge, not as a prompt paste.
BuildX	The model gateway. Route sensitive telemetry only to the models you have approved.

What a SOC triage agent can and cannot do

Every agent gets a Trust Profile before it touches an alert. This is the shape of one for a SOC triage and response agent. The exact limits are set by your team.

SOC Triage Agent

Reads alerts, investigates, recommends severity and prepares containment.

SOC Triage Agent: what it can do, cannot do, requires approval for, and records
Can	Cannot	Requires approval	Records
Read alerts and approved telemetry sources Enrich indicators with approved threat intelligence Correlate with open cases and past incidents Recommend severity and a next step with cited evidence Draft the case summary and the ticket	Read data outside its approved sources Disable its own policy or raise its own autonomy level Close a high-severity case without a human Delete or alter logs and evidence Contact external parties on its own	Isolating a host above the configured asset tier Disabling an account outside a standard user class Any action whose blast radius exceeds the set threshold Notifying customers, regulators or the press	Agent identity and owner Alert and data accessed Model used Tools called Policy applied Recommendation, approval, action and outcome

Controlled autonomy for SOC actions

Autonomy rises per action type, as the record earns it. Destructive or hard-to-reverse actions can stay at an approval level permanently.

L1 Assist
Triage recommendations and enrichment. Humans take every decision and every action.
L2 Approve
The agent prepares containment; a named analyst approves each action before it runs.
L3 Supervise
The agent contains within limits, for example a non-critical endpoint or a single standard user session, and is monitored live. Exceptions above threshold escalate.
L4 Autonomous
Narrow, well-understood, reversible playbooks run independently inside strict policy and risk bounds, with sampled human review.
L5 Adaptive
The agent proposes detection or playbook tuning. Changes are versioned, tested and gated; the agent cannot modify its own boundaries.

The five-level model is described in full on the controlled autonomy page.

Frameworks the design is mapped to

The controls are designed to line up with the main AI security frameworks. This is a mapping of intent, not a certification or an assessment result.

Framework entries and how the controls are designed to address them
Framework	Entry	How the design addresses it
OWASP Top 10 for LLM Applications (2025)	LLM06 Excessive Agency	Scoped permissions, approval thresholds and a hard stop on actions outside the allowed set limit what a SOC agent can do if it is manipulated.
OWASP Top 10 for Agentic Applications (2026)	ASI03 Identity and Privilege Abuse	Each agent has its own identity and least-privilege access rather than borrowing an analyst's credentials.
MITRE ATLAS	AML.T0051 LLM Prompt Injection	Alerts and tickets are untrusted text. The agent treats their content as data and cannot be instructed by it to widen its own permissions.

EU angle: evidence for the people who audit you

Swfte provides technical controls and evidence that can support your obligations. Whether a given use is compliant depends on your facts, jurisdiction and configuration.

EU instruments and what Swfte supports evidence for
Instrument	Reference	Supports evidence for
NIS2 (Directive (EU) 2022/2555)	Art. 21 risk-management measures; Art. 23 incident reporting	Supports evidence for incident handling and for the timeline you need when an early warning, notification and final report are due.
DORA (Regulation (EU) 2022/2554)	ICT-related incident management and reporting	Supports a classified, time-stamped record of what was detected, decided and done, for financial entities in scope.
GDPR	Art. 32 security of processing	Supports evidence of access control, minimization and logging around personal data that passes through SOC tooling.
EU AI Act	Art. 14 human oversight; Art. 15 accuracy, robustness and cybersecurity	Supports evidence of human oversight points and of controls against manipulation, where a SOC agent falls within a regulated use.

Swfte is built compliance-by-design. It provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration. Nothing on this page is legal advice. Swfte's own security attestations are listed on the trust page.

What this page does not claim

No detection rate, accuracy figure, mean-time-to-respond improvement or customer result is stated, because none is published here.
SecOps Agents is in beta. Capabilities described here are what the platform is designed to let your team do; the product page carries the current status.
Swfte is not presented as a replacement for your SIEM, EDR or your analysts. It sits alongside them.
Nothing here claims that your use of the platform is compliant with any regulation. Swfte's own security attestations are listed on the trust page.

Frequently asked questions

What is an AI SOC agent?

An AI SOC agent is software that uses a language model to do parts of a security analyst's work: reading alerts, gathering context, correlating with past incidents, recommending a severity and preparing a response. On Swfte it runs as a governed agent with its own identity, permitted actions, approval thresholds and an audit trail.

Will an autonomous SOC agent act without a human?

Only where you allow it. Controlled autonomy runs from L1 (recommend) to L5 (adaptive), per action type. Many teams will keep destructive actions at an approval level for good, and let routine, reversible steps run within limits.

Can the agent be manipulated by the alerts it reads?

Alert text, ticket bodies and log lines are untrusted input and can carry instructions aimed at the agent. The design answer is not only filtering: the agent's permissions are scoped so that even a successful manipulation cannot reach beyond what it was allowed to do. See the prompt injection defense page.

Does it replace our SIEM or our analysts?

No. It reads from your existing tools and works alongside your people. The aim is to give analysts their time back for judgment, not to remove the judgment.

Where do the telemetry and the model run?

The platform is designed so you choose where agents and models run, including on infrastructure you control, and which models may see which data. The exact deployment depends on your configuration.

Is this compliant with NIS2, DORA or the EU AI Act?

Swfte is built compliance-by-design: it provides technical controls, governance mechanisms and evidence that can support your regulatory and policy requirements. The exact posture depends on your use case, jurisdiction, deployment and configuration.

The rest of SecOps

Nine pages cover both halves. Each has a different job.

AI for security operations

AI incident response

Security for AI

Frameworks and evidence

Back to the SecOps hub.

Build AI SOC agents with Swfte

Start with one agent and one policy, or talk to the team about your environment, your data and your regulators.