A security engineer built an orchestration layer between their SIEM and their response workflows. Opus reads incoming alerts, enriches them with threat intelligence, and either kicks off a remediation runbook or escalates with context attached. It also writes the ticket notes: timeline, indicators of compromise, actions taken. The engineer estimates it saves 30-40 minutes per day on documentation alone.
This is the best tool in this series. It's also the most dangerous.
The failure mode you're optimising for
Alert fatigue is the reason the tool exists: too many alerts, not enough human attention. The AI triages what humans can't review fast enough. But the failure modes of human triage and AI triage are different in kind.
When a human misses an alert, the failure is a missed detection. The threat continues unnoticed. This is bad, and it's the problem the AI solves.
When an AI auto-remediates incorrectly, the failure is a self-inflicted outage. The model misclassifies a benign network anomaly as an active intrusion and executes a containment runbook: isolating a server, rotating credentials, blocking IP ranges. The damage comes from the response, not the threat.
The engineer who built this described "real iteration to get the triage logic reliable." Reliability in classification doesn't address the governance question: who authorised the AI to act, under what constraints, and where's the proof?
Three gaps a creed would fill
Escalation thresholds
The creed defines a severity boundary. Below the threshold, the AI executes runbooks autonomously. Above it, the AI prepares the runbook, attaches context, and waits for human approval.
The threshold isn't a technical parameter. It's a values decision about how much autonomous authority the builder is comfortable granting. A creed makes that decision explicit and reviewable, rather than implicit in whatever if-statement the builder happened to write at 2am during an incident.
Separation of observation and action
The creed distinguishes between "enrich and recommend" and "execute remediation." These are different categories of action with different risk profiles.
The AI can read every alert, pull all the threat intel, draft all the ticket notes it wants. Reading is safe. Writing ticket documentation is safe. Executing changes to production systems is a fundamentally different act that requires governance.
Most security engineers understand this distinction intuitively. A creed codifies it so the tool reflects the distinction structurally, not just in the builder's head.
Decision records
Every auto-remediation gets a decision record: what alert triggered it, what the AI classified it as, what action it took, what policy authorised it. When the CISO asks "why did our east-coast database get isolated at 3am," there's a cryptographic proof chain, not a log file and a shrug.
Where this connects to the stack
This case study is the natural bridge between personal creeds and production governance.
A solo engineer building a triage tool starts with a personal creed. The creed says: "I value human oversight for high-severity actions. I value separation between observation and response. I value provable decision trails."
When the tool moves to a team, the creed becomes a constitution: a shared document the team agrees on, versioned alongside the code.
When it serves the enterprise, the constitution becomes a Guardian policy with Gateway enforcement. Every auto-remediation produces a signed decision token that proves governance happened: what policy applied, what the AI decided, what evidence it used.
The values stay the same at every scale. A personal creed for a weekend project and an enterprise compliance framework for a SOC team encode the same principles. The enforcement mechanism grows; the principles don't change.
That's the point. Start with what you believe. Let it shape what you build. The tool already works. The creed makes it accountable.
Third in a series on tools built without creeds. Create your own personal creed →