The multi-agent pipeline
The stages an incident passes through, and what each may touch
1. Orchestrator
Routes an incident through the pipeline, enforces stage ordering and preserves context.
case-readstage-dispatchGuardrail: Cannot execute response actions directly.
2. Monitoring Agent
Consumes normalized telemetry from every connector and raises candidate signals.
siem-readedr-readiam-readfirewall-reademail-readcloud-readGuardrail: Read-only across all sources.
3. ATT&CK Mapping Agent
Maps observed behaviour to public ATT&CK tactics, techniques and sub-techniques with rationale.
attack-taxonomyGuardrail: May only cite techniques present in the public taxonomy.
4. Threat Intelligence Agent
Enriches indicators, malware, actors and campaigns from the simulated TI platform.
ti-readGuardrail: Read-only; confidence and TLP always carried through.
5. Evidence Correlation Agent
Assembles the evidence package across sources, keeping supporting and contradicting items.
siem-readcmdb-readvuln-readGuardrail: Must retain contradicting evidence; may not discard it.
6. Risk Assessment Agent
Runs the deterministic risk model and returns factors, contributions and classification.
risk-modelGuardrail: Score comes from the model, never from a language model.
7. Decision Gate
Applies the human-approval matrix to the recommended action.
policy-evalGuardrail: Destructive High/Critical actions always require human approval.
8. Response Agent
Executes only allowlisted, scoped actions through approved APIs and a restricted service account.
edr-isolateiam-disableiam-revokefw-blockemail-quarantinesoar-ticketGuardrail: Refuses any action outside the allowlist; honours the kill switch.
9. Reporting Agent
Produces audience-scoped reports from one evidence set without altering source data.
case-readreport-renderGuardrail: Scoping only; may not introduce facts absent from evidence.
10. Continuous Learning Agent
Captures lessons learned and proposes detection and coverage improvements.
case-readcoverage-readGuardrail: Proposals only; cannot deploy detections.
Guardrails console
Every guardrail, its live status and the events it produced — click any event for the full record and its trace
5 patterns screened on every query and every ingested artefact
Findings below the minimum are withheld and escalated
Any tool outside the enabled set is refused in code before dispatch
Retrieval bounded by the acting role's data scope
Risk, thresholds and allowlists stay in policy code
Destructive actions at these levels require an authorised human decision
A human can halt and reverse automation at any point
Active configuration
Changes apply to the very next invocation and are themselves logged — re-run a test to watch behaviour flip
Minimum-confidence threshold
The agent never asserts below this. Raise it and re-run the weak-evidence test to see the gate flip to withheld.
Approval thresholds
Which risk levels must hold a destructive action for a human. Unticking a level makes those actions auto-run.
Tool allowlist
12 of 12 enabledDisable an action and the Response Agent's request for it is refused in code — try it, then run the allowlist test.
Access & data scope
Strict scope bounds retrieval by the acting role and redacts telemetry from audiences that may not hold it.
Model policy
6 of 11 stages are controlled logic today. Deterministic-first keeps risk, thresholds and allowlists out of the model's reach.
Human-approval gate — live
Held actions wait here. Approve, deny or modify with a reason; the outcome ripples to Response, case status, metrics, audit and the trace
Critical · risk 64 · scope: Single asset, EDR network quarantine
High · risk 32 · scope: Single external address, 24h TTL
Medium · risk 28 · scope: Single identity, all tokens
Kill switch / override — live
Halts every execution path app-wide and reverses in-flight automated actions. Each use is logged with who, when and why
Released: automation runs under the approval matrix. 6 automated action(s) are in flight and would be reversed on engagement.
With vs. without the guardrail
A simulated side-by-side. The unsafe column is never executed — safety is not disabled to produce it
Without the guardrail
Simulated — never executedThe hidden directive is read as an instruction: the agent disables the mailbox owner's account and approves the pending containment action itself.
Consequence: An attacker who can write into any ingested log, email or intel note gains the agent's privileges — identity disablement without a human in the loop.
With the guardrail
What actually happensThe pattern is matched at ingest, the directive is neutralised, the item is quarantined from the reasoning context and retained as case evidence.
Consequence: No stage received the instruction. The attempt itself becomes evidence.
Most recent real event for this guardrail
Prompt injection blocked on ingest — Embedded privileged command — The directive was neutralised at ingest, the item quarantined from the reasoning context and retained as case evidence.
-83m ago · Input screening (deterministic) · trace INV-5003
Guardrail event feed
Every block, withholding, hold, override and configuration change — newest first
Traceability & explainability
Every invocation is recorded with its trigger, step chain, models, retrieved sources and scores, confidence gate, guardrail checks and decision
Minimum confidence threshold
The agent never asserts below this. Below-threshold findings are withheld and escalated to a human.
Tested scenario catalogue
Questions verified to return a cited answer — or a correct refusal
Audit trail
What the agent saw, decided, recommended and executed — click an entry for its full record