✓ Human-authored analysis; AI used for formatting and proofreading.
Grant Oviatt spent 15 years running security operations at Mandiant and Red Canary before building AI SOC agents at Prophet Security. He describes himself as a former AI skeptic: "anything AI detection in it scared me to death". He changed his mind when he saw what happened when you break security investigations into composable pieces that agents can tackle individually.
His team ran a bake-off: 12,000 alerts over two weeks, same alerts sent to both a human SOC team and the AI system, decisions compared blind at the end. The result was 99.3% agreement between the human team and the AI, with the AI completing investigations 11x faster. Four minutes average versus the human team not even starting to look at an alert in four minutes.
99.3% agreement across 12,000 investigations is a remarkable result. For runtime security investigation, is this login suspicious? Is this lateral movement malicious? Should this alert be escalated? It may be close to the ceiling of what's achievable. These questions require judgment. They depend on behavioral context, peer baselines, historical patterns, and threat intelligence that changes daily. A probabilistic instrument, an LLM reasoning through evidence is the right tool. And 99.3% may be as good as that tool gets.
But 84 out of 12,000 alerts got a different answer from the AI than from the human team. Which 84? Were any of them the ones that mattered?
Two different trust questions
Grant identifies two pillars of trust in an AI SOC: explainability ("is the decision reasonable?") and traceability ("can you audit the entire data trail?"). Both are essential for runtime investigation, where the AI is making judgment calls about ambiguous events.
But there's a category of security questions where "is the decision reasonable?" is the wrong standard. The right standard is: "is the property satisfied?"
"Does this IAM policy allow any identity to reach production Secrets Manager through a chain of trust relationships?" That question has a definitive answer. It's not a matter of judgment. The configuration exists in a snapshot. The trust relationships are enumerated. The paths either exist or they don't. A formal reasoning engine can traverse the graph and produce a proof. Not "we're 99.3% confident no path exists" but "no path exists, here's the proof" or "a path exists, here's the chain."
For this category of questions, 99.3% is not impressive. It means 0.7% of configuration checks returned the wrong answer. At enterprise scale with thousands of IAM policies, hundreds of trust relationships, millions of possible paths 0.7% error rate means dozens of misclassified findings. Some of those will be paths to crown jewels that the system classified as safe.
The Cynefin boundary Grant already draws
Grant makes a striking statement about remediation: "Agents are very creative, maybe a nicer way of saying probabilistic." He recommends constraining that creativity for response actions. Instead of letting agents creatively determine how to remediate, use "a single call or a series of calls that are more deterministic."
He's drawing the boundary without naming it. For investigation (is this alert malicious?), probabilistic reasoning is the right instrument. The question is ambiguous. Context matters. Judgment is required. For remediation (execute this API call to revoke this session), deterministic execution is the right instrument. The action must be precise. Creativity is dangerous.
The same boundary applies to configuration verification. "Is this S3 bucket public?" is not a question that benefits from probabilistic reasoning. The bucket policy is a JSON document. The evaluation is deterministic. An LLM that answers this question 99.3% of the time is worse than a CEL predicate that answers it 100% of the time that is faster, cheaper, and provably correct.
What 99.3% means at enterprise scale
Grant's bake-off was 12,000 alerts. 99.3% agreement means roughly 84 disagreements. At that scale, 84 is a manageable number for a human to review.
Now consider an enterprise with 10,000 IAM roles, 500 trust relationships, and 2,000 resource-based policies. The configuration graph contains millions of possible paths. If a probabilistic tool evaluates reachability with 99.3% accuracy, that's thousands of paths with uncertain classification. Some of those uncertain paths lead to production databases. Some lead to KMS keys. Some lead to Secrets Manager secrets containing database credentials.
For runtime investigation "is this login suspicious?" 99.3% accuracy with human review of the remainder is a defensible operating model. Grant's architecture reflects this: 95% auto-closed as false positive, 5% escalated to humans.
For configuration posture "does a path exist from this OIDC federation through this trust chain to this Secrets Manager secret?", the question is deterministic. The answer is yes or no. Three formal reasoning engines (CEL for the predicate, Soufflé for the graph traversal, Z3 for the existence proof) can produce that answer with 100% agreement, microseconds per check, on every configuration snapshot. No disagreements across all lab validations against three public harness repositories.
The honest ceiling for probabilistic investigation is 99.3%. The achievable standard for deterministic verification is 100%. Both are real. Both are needed. They answer different questions.
Grant's MCP insight applies more broadly
Grant made another observation that extends beyond SOC operations. He evaluated MCP servers for data collection and rejected them: "When I ask an MCP agent a question, it'll give me an answer, but it won't give me the query that it ran to generate the answer. There's a mismatch in auditability."
He built custom collection agents instead for traceability. He needs to see every query, every response, every data transformation, so that an auditor can reconstruct the investigation from raw evidence to final decision.
The same auditability concern applies to configuration verification. When a tool tells you "this IAM policy is compliant," can you see the property that was checked, the configuration that was evaluated, and the reasoning that produced the verdict? If the tool is an LLM, the reasoning is a chain of thought, persuasive but not reproducible. Run the same query twice and you might get a different chain of thought with the same conclusion, or a different conclusion entirely.
When the tool is a formal engine, the reasoning is a proof. The CEL predicate is the property. The configuration snapshot is the input. The evaluation is deterministic with the same input, property, verdict, every time. The auditor doesn't reconstruct the AI's reasoning. The auditor re-runs the check and gets the same answer. That's traceability that regulated environments can audit.
The complement, not the replacement
Grant's AI SOC and deterministic configuration verification answer different questions at different layers:
The AI SOC answers: "Given this runtime event, this behavioral context, and this threat intelligence, is this activity malicious?" The answer requires judgment. 99.3% agreement with human analysts is remarkable. The remaining 0.7% gets human review. This is the right operating model for the Complex domain, runtime, behavioral, ambiguous.
Deterministic verification answers: "Given this configuration snapshot, does any path exist from any external identity to any production secret through any chain of trust relationships?" The answer is a proof. 100% agreement across three formal engines. No remaining percentage for human review because there's no uncertainty. This is the right operating model for the Complicated domain, configuration, structural, deducible.
Grant earned his credibility by spending 15 years in SOC operations, declaring himself a skeptic, and then showing the data: 12,000 alerts, 99.3% agreement, 11x faster. That's honest reporting of what probabilistic investigation achieves.
The honest complement: for the questions that have deterministic answers: configuration posture, path existence, policy compliance, the achievable standard is 100%. Because the domain is different. Some questions deserve proofs, not predictions.
Stave is an open-source tool that verifies cloud configuration against declared invariants using three formal reasoning engines (CEL, Z3, Soufflé). It operates in the Complicated domain with deterministic verification of configuration posture complementing AI SOC tools that operate in the Complex domain of runtime investigation. The 100% agreement across three engines referenced above is from lab validation against Bishop Fox IAM Vulnerable, NCC Group SadCloud, and Rhino Security CloudGoat.
Top comments (0)