AISecOps
Who validates an AI system's output when the system generating it can't validate itself? Hands-on integration work, plus a framework for reading AI security research from both sides of the fight.
The Hands-On Foundation
I integrated the Anthropic Claude API directly into a production-style pipeline (Pawsome Provisions), not as an autonomous decision-maker, but as a design and thinking partner whose output gets checked, not assumed. That distinction matters: a correlation engine I built collapses 20 raw multi-source signals into a single correctly-attributed event with zero false positives on the simulated Pawsome Provisions dataset, across the runs I've tested — real, hands-on experience with the signal-quality problem that sits underneath most AI-governance conversations, though I want to be clear this is a result against synthetic data I built myself, not a claim about performance against real-world or adversarial traffic.
I also built a portfolio-triage prototype (FetchTrack) with a real accountability workflow baked into the interface itself: a flag cannot be cleared without a substantive written justification. The point wasn't to let AI decide — it was to make sure nothing, human or AI, gets to validate its own work without a check.
The Core Principle: The Generator Cannot Be Its Own Validator
A system — or an AI model — cannot reliably certify its own output as safe. This shows up as a measurable, not just theoretical, problem: a write-up of a July 2026 talk by Manoj Nair (CTO, Snyk) at the AI Engineer World's Fair cited LLM self-validation catching only around 50% of vulnerabilities across repeated runs, with a fairly low F1 score. I want to be precise about the sourcing tier here: this figure comes from secondary write-ups of the talk, not a primary Snyk publication I was able to verify directly — treat it as "cited," not "confirmed."
The OWASP Flip: Reading a Defensive Checklist From the Other Side
The OWASP Top 10 for LLM Applications was written for someone building an LLM application, worried about vulnerabilities in their own system. What if the same list describes an adversary's own AI tooling too?
Case: GTG-10007 — the exploit foundry
Anthropic's September 2026 threat report documents a Chinese-speaking group (some members undergraduate students) running Claude as "the engineering and orchestration layer" of a round-the-clock vulnerability-research operation against major endpoint-security products — described as "a collection fleet running on a pre-set schedule with no human in the loop."
The flip — LLM06, Excessive Agency: this is structurally close to the exact scenario Booz Allen's "Guile" deception system already exploits in testing. Booz Allen's own published research found its strongest Counter AI configuration reduced autonomous attacker success by more than 95% against a no-deception baseline, using a fixed 2-hour test window and defined success criteria (full access, compromise, or exfiltration). A secondary source (daily.dev) frames this as AI agents "falling for" decoys more than 90% of the time — directionally consistent, but I'm citing the primary 95%+ figure since I could verify it directly against Booz Allen's own methodology. A honeypot security appliance, deliberately seeded with fake vulnerabilities, could waste this kind of exploit-foundry's compute and attention on nothing. Confidence: primary-sourced precedent (Guile), applied here to a real, documented adversary.
Case: GTG-20006 — the autonomous evasion loop
Russian espionage operator "JackPoterz" (Midnight Blizzard-consistent) built AI agents that monitor their own deployed malware for detection, then autonomously rebuild and redeploy it until it evades security tools — confirmed directly from Anthropic's primary report text.
The flip — LLM06 / LLM09: the monitoring agent trusts its own detection-status signal without independent verification. A defender who could feed that agent false detection signals could manipulate the rebuild loop itself. Confidence: reasoned, mechanism-specific — no known real-world deployment of this counter-tactic yet.
Case: GTG-50014 — the credential pipeline
A ShinyHunters-affiliated operation ran a distributed credential-harvesting pipeline across 10 AWS EC2 workers, mass-scanning 1.8 million Android APKs with the named open-source tool TruffleHog, feeding verified findings to Telegram.
The flip — LLM03 / LLM10: the entire pipeline depends on one identifiable tool's specific detection patterns (supply chain), and processes targets at real scale — a defender could seed decoy APKs deliberately engineered to be resource-intensive, wasting the pipeline's compute on worthless targets (a "tarpit," extended from network security into token/compute economics). Confidence: reasoned; the tarpit concept itself has real precedent in a different domain.
Sources
Anthropic's September 2026 Threat Report
Anthropic, "Detecting and countering misuse of AI: September 2026" (primary source, read in full) —
anthropic.com
Booz Allen Cyber Weapon Index & Guile
Booz Allen Hamilton, "Booz Allen Charts Autonomous AI Threats and Unveils New Counter AI Defense" (Sept. 2, 2026, primary press release) —
newsroom.boozallen.com
Booz Allen Hamilton, "Cyber Weapon Index" (primary, ongoing results) —
boozallen.com
Booz Allen Hamilton, "Counter AI Defeats AI Adversaries" — the primary source for the 95%+ figure, including test methodology (2-hour fixed window, defined success criteria, no-deception baseline) —
boozallen.com
Sourcing note: the commonly-repeated "90%+ of AI agents fall for decoys" framing traces to a secondary source (daily.dev), not Booz Allen's own materials in that exact wording — I'm citing the primary 95%+ attacker-success-reduction figure instead.
Mantis (Academic Precedent for the Prompt-Injection Flip)
"Hacking Back the AI-Hacker: Prompt Injection as a Defense Against LLM-driven Cyberattacks" —
arxiv.org
Manoj Nair / Snyk Self-Validation Statistic
daily.dev, summary of a July 20, 2026 talk at the AI Engineer World's Fair —
daily.dev
Sourcing note: this is a secondary summary of a talk, not a primary Snyk publication I could independently verify — the specific figure is cited, not confirmed.
Status
This framework — "Turning the Mirror" — is an active, in-progress research direction. Submitted as a talk proposal to the Après-Cyber Slopes Summit (Feb. 24–26, 2027, Park City, UT) — not yet accepted or presented. It is built as a direct companion to Stop the Silos: the same underlying principle, aimed at AI-vs-AI conflict specifically.