Open SOAR + MCP + Slack: An Architecture Note

Comparing n8n, Tines, and Tracecat as automation layers — and where to draw the line when you add an AI agent to the loop.

The problem this solves

Once a security team gets more alerts per day than analyst-hours to triage them, there are two options: tune detections down until the volume is manageable, or automate the triage. The first hides real attacks. The second is what SOAR tooling exists for.

Adding a conversational agent on top — ask a question in Slack, get an enriched answer in-thread — is an obvious next step, and a genuinely useful one. It also introduces a failure mode that is easy to miss and expensive to discover. Most of this note is about the platform choice; the last section is about that failure mode, and it matters more than which platform you pick.

Three platforms

n8n

General-purpose automation that happens to work well for security.


License	Fair-code (source-available, self-hostable)
Hosting	Self-host via Docker, or managed cloud
MCP	Client and server nodes — consumes MCP tools, exposes workflows as MCP tools

Strengths

Largest integration library of the three by a wide margin
Mature Slack integration
Self-hosting is well-trodden; Docker Compose and you're running
Fast time-to-value — most SOAR playbooks are API calls in a trench coat, and n8n is very good at API calls

Weaknesses

No security-native primitives. No case object, no artifact model, no MITRE tagging. You model all of that yourself.
Workflow sprawl is real; without discipline you end up with sixty near-duplicate flows
Fair-code license has restrictions worth reading if you plan to offer it as a service

Tines

Commercial SOAR with the best interface of the three.


License	Commercial, with a usable free community tier
Hosting	SaaS-first
MCP	Supported

Strengths

Markedly better UX — the builder is genuinely pleasant, which matters more than it sounds when you're debugging a twelve-step playbook at 2am
Security-native concepts built in rather than bolted on
The community tier is a real product, not a demo
No infrastructure to operate

Weaknesses

Workflow definitions and run history live on their infrastructure. Whether that's acceptable depends entirely on your data and your clients'.
Scaling past the free tier means a commercial conversation
Less appealing if self-hosting is a requirement rather than a preference

Tracecat

Open-source SOAR built security-first.


License	Apache 2.0
Hosting	Self-host
MCP	Supported

Strengths

Genuinely permissive license — no fair-code caveats
Security-shaped from the ground up: cases, artifacts, YAML-defined integrations
Temporal-backed durable execution, which means long-running and retried workflows behave sanely
The clearest long-term answer for "open SOAR" if it keeps maturing

Weaknesses

Youngest of the three. Smaller community, thinner docs.
Integration breadth well behind n8n — expect to write connectors
You are an early adopter, with everything that implies

Choosing

The honest decision rule:

Self-hosting is non-negotiable and you need breadth now → n8n
SaaS is fine and UX is worth paying for → Tines
You want security-native structure, open license, and can absorb early-adopter cost → Tracecat

For a small team or a one-person shop, integration breadth almost always beats conceptual fit in the first year. You will miss a missing connector every week; you will miss a case object approximately never, because you can model one in Postgres in an afternoon.

Migration between these is also cheaper than it looks. Playbooks are mostly HTTP calls and branching logic — a weekend of work, not a quarter. Don't over-optimize the initial choice.

Adding MCP and Slack

The appealing version: an alert lands in a Slack channel. Someone asks in-thread, "what is this IP?" An agent calls MCP tools, enriches it, and answers inline. No context switch, no copy-pasting into five tabs.

That's real value, and it's low risk — every one of those operations is a read.

The version that bites you is the same loop with write tools attached.

The problem

Alert content is attacker-influenced by definition. A hostname, a user-agent string, an email subject line, a filename, a process command line — all of these can be set by whoever triggered the alert, and all of them flow into the agent's context.

An agent that can both read alert content and take action has a prompt-injection surface. The attacker doesn't need to compromise your SOAR platform; they need to get text into an alert that your agent will read and act on.

This is not hypothetical and it is not solved by prompting the model to be careful.

The boundary

Reads go to the agent. Writes stay deterministic.

Layer	What belongs there
MCP tools (agent-accessible)	Enrichment lookups, threat intel queries, log searches, case history, asset context — anything read-only
Workflow automation (deterministic)	Blocking, isolating, banning, disabling accounts, closing cases — anything that changes state

The agent answers questions. It does not pull triggers.

The pattern that works

Alert fires
  → posts to Slack with context
  → analyst asks questions in-thread (agent, read-only MCP tools)
  → analyst clicks an action button
  → webhook to n8n / Tracecat
  → deterministic workflow executes the action
  → result posted back to thread

Human intent is explicit. The action path is auditable. The agent never holds the trigger.

A Slack interactive button hitting a webhook is unglamorous, and that's the point. It's a clear boundary between "a model produced this" and "a person decided this," and you want that boundary to be visible in your logs, not inferred.

Where the line can move

Auto-remediation without a human is defensible for narrow, reversible, well-understood cases — auto-banning an IP that three independent intel sources agree is malicious, for instance. The test is: is this reversible, and is the decision rule simple enough to express as a rule rather than a judgment?

If the answer involves the agent weighing context, keep the human in the loop.

Prerequisites nobody mentions

None of this works without the unglamorous groundwork underneath it:

Logs that actually ship. Centralized collection that doesn't silently stop.
Consistent formats. A playbook that parses alerts can only be as reliable as the structure of what it's parsing.
Known-good configuration. If you can't tell what changed, you can't tell what's an incident.

Automation amplifies whatever instrumentation you already have. If the instrumentation is inconsistent, automation makes the inconsistency faster rather than fixing it.

Summary

Pick the platform on integration breadth and hosting constraints, not on feature-matrix completeness. Migration is cheap.
MCP in Slack is a strong addition for enrichment and triage.
Give the agent read tools only. Keep state-changing actions in deterministic workflows triggered by explicit human action or by simple, reversible rules.
The boundary between "a model suggested this" and "a person authorized this" should be visible in your audit log, not inferred from it.

Drafted with Claude; the framing and the errors are mine.