The Intrusion Wore a Name Tag
Somewhere on a Windows machine near you, a scheduled task named "DeliveryOptimizationCache" is running right now, and it is almost certainly innocent. That "almost" is the whole problem. A stock Windows install carries well over a hundred legitimate scheduled tasks with names exactly that boring, which is why attackers love dressing malware up as one more. When three of those tasks turned out to be a live intrusion (more on that case file below), the thing that caught them was not a smarter model or a bigger budget. It was AI agent orchestration built on a principle auditors have trusted for a century: separation of duties.
Here is the uncomfortable part. Every security incident is actually two investigations. The first one hunts the attacker. The second one, months later, investigates you: what you knew, when you knew it, and what you can prove. A single do-everything AI agent helps brilliantly with the first and quietly sabotages the second. This article shows you how to orchestrate a team of AI agents so you win both.
TL;DR
- You will replace one do-everything AI agent with a pipeline of specialists, each barred from grading its own homework.
- Findings cross between agents in one sealed, hashed schema, giving you a chain of custody that survives hostile review.
- One agent gets paid to disagree, which is how three malware tasks dressed as routine maintenance got caught.
- The right to act on a target machine stays with a human, and the pipeline still contained a live backdoor same-day.
- Five portable rules at the end work in any framework, with any model, at any team size, including a team of one.
Why One AI Agent Can't Audit Itself
Run your whole triage through one AI context and you get a workflow that collects, analyzes, concludes, and then reviews itself. Count the handoffs in that sentence. Zero. Collection bleeds into analysis, analysis into conclusion, conclusion into a self-review that has never once returned "actually, I was wrong." There is no seam where anyone, human or machine, could stop and check the work.
Chain of custody is a simple idea: every time evidence changes hands, someone signs for it. A monolithic agent never lets the evidence change hands at all. You cannot audit what never moved. And you cannot prompt your way out of this, either. Telling one model to "be skeptical" and "verify your own work" produces a model that agrees to be skeptical and then agrees with itself anyway. The failure is structural, so the fix has to be structural. We covered a cousin of this problem in our piece on agentic misalignment: an agent trusted with everything has no one positioned to notice when it drifts.
The fix is not a better prompt. It is a better org chart.
What Is Separation of Duties for AI Agents?
Separation of duties for AI agents means no single agent holds enough of the workflow to both produce a conclusion and approve it. The agent that collects evidence never calls verdicts. The agent that calls verdicts never checks its own math. Accountants have run payroll this way since before computers existed, for the same reason: the person who writes the checks should not be the person who reconciles the books.
Definition: Separation of Duties (SoD)
A control principle that splits a sensitive process across multiple parties so that no single actor can complete, conceal, or corrupt it alone. Applied to AI orchestration, it means each agent receives one narrow role, one bounded set of permissions, and zero ability to review its own output. Overlap is treated as a defect, not a convenience.
This is more than tidy engineering. Security researchers at Wiz have flagged a sneakier failure mode: two agents that are individually harmless can coordinate their way around a control, like one agent with permission to create a user cooperating with another that can assign admin rights. Separation of duties only works when the boundaries are enforced by the architecture (scoped credentials, schema-limited handoffs) rather than politely requested in a prompt. It is the same lesson from our look at authorization confusion: an agent acting in your name needs walls, not vibes.
The Evidence Assembly Line
A working example: an eight-agent incident response pipeline that runs in production on a small Windows environment with no EDR, no budget, and no night shift. The agents are markdown files, not platforms. Each one carries a fresh set of eyes and exactly one job.
| Stage | Agent | Its one boundary, verbatim |
|---|---|---|
| Collect | evidence-collector | "Acquire and preserve; do not interpret." |
| Enrich | threat-intel-analyst | "You enrich; you never decide severity." |
| Triage | soc-analyst | "Every finding must cite the source line." |
| Investigate | forensics-investigator | "Verify, don't inherit." |
| Investigate | root-cause-analyst | "Duplicating forensics is a failure." |
| Contain | containment-engineer | "You never execute on the target." |
| Comply | compliance-auditor | "Never invent a control number." |
| Brief | risk-communicator | "Uncertainty survives translation." |
Notice what each boundary is aimed at: that role's most tempting shortcut. The intel analyst would love to declare severity. The auditor would love to guess a plausible control number. One sentence each, and the shortcut is closed. You don't prompt for brilliance. You prompt for boundaries.
The boxes, though, are the least interesting part of that table. The design lives in the gaps between them. At every arrow from stage to stage, a context dies, a schema crosses, and a hash gets checked.
Escalation rule: severity score ≥ 7 out of 10 → adversarial review
The soc-analyst scores every event 0 to 10. At seven or above, forensics and root-cause start attacking the hypothesis, and on a confirmed infection the containment runbook is drafted in parallel while they work.
Sealed Handoffs and the Chain of Custody
When a detective logs evidence, the ritual never changes: the bag is sealed, the seal is signed, the log gets a line. At trial, the defense rarely attacks the fingerprint. They attack the bag. One broken seal and the jury never sees the evidence. Your incident record will eventually face the same style of attack, so between every pair of agents, the bag gets sealed.
Concretely, each handoff enforces three rules:
| Dies with the agent | Crosses the gap | Checked on receipt |
|---|---|---|
| Reasoning, hunches, dead ends, enthusiasm | Findings, citations, confidence labels, and the custody ledger, in one JSON schema | Every artifact is re-hashed; a mismatch halts the entire run |
No shared memory between agents is the feature, not a limitation. The receiving agent starts clean, inherits sealed findings only, and verifies the hashes before opening anything. This also happens to be your best structural defense when an agent has touched untrusted content, a risk we unpacked in our review of Google's indirect prompt injection findings: whatever a poisoned page whispered to the collector, the whisper dies with the collector's context. Only schema-shaped findings survive the gap.
Pro Tip: Start With Three Agents, Not Eight
Minimum viable separation is a collector, an analyst, and a skeptic. If you stand up only those three with sealed JSON handoffs between them, you already have more chain of custody than most monolithic deployments. Grow toward eight roles when the caseload justifies it, not before.
Case File: Three Scheduled Tasks in Work Clothes
Now the case the architecture was built for. Three scheduled tasks on a Windows 11 workstation, all dressed as routine maintenance: "DeliveryOptimizationCache," "Google_Maintenance_Worker," and "figmaUpdate." Boring names, boring schedules, exactly the camouflage that lets a task blend into the hundred-plus legitimate ones around it. Underneath the costumes: one task ran a loader calling home through DNS, one hijacked the local proxy on loopback, and one sideloaded a hostile DLL through a legitimately signed application.
None of this is exotic. It is catalogued tradecraft: MITRE ATT&CK T1053.005, scheduled task abuse, paired with T1036.004, masquerading as a legitimate task or service. Microsoft's Tarrask writeup documented the HAFNIUM group going a step further, deleting a task's security descriptor so it vanished from schtasks and the Task Scheduler GUI entirely. The Task Scheduler is beloved by attackers for the same reason nobody looks twice at it: it is supposed to be boring. For the broader numbers on how persistent this class of attack has become, our cyber threat statistics page keeps the receipts.
Catching a costume is a volume problem, and volume is where orchestration earns its keep. The collector inventoried and hashed every task XML without deciding anything. Intel mapped the names against known tradecraft. The SOC analyst scored the anomalies with line-level citations. Forensics corroborated across DNS logs and prefetch, independently. Then the ending, which is the part worth remembering: nothing dramatic happened. A person walked a USB stick to the machine, dry-ran each containment step, removed the tasks, and reimaged. Same-day containment, no war room, no all-nighter. The most boring possible ending, on purpose.
Expert Tip: Baseline Your Scheduled Tasks Today
Export every task now, while you are clean: schtasks /query /xml > baseline.xml on each endpoint, hash the file, store it off-box. The next investigation starts with a diff instead of a stare-down against 140 boring names. Re-baseline after every patch cycle, and diff the registry task cells too, since Tarrask-style deletions hide from schtasks itself.
Pay One Agent to Disagree
Ask yourself what your current AI assistant says when you are wrong. Every commercial AI product fills that silence with agreement, a business model built on overreliance, which is precisely why unchallenged findings are opinions wearing lab coats. In this architecture, one agent's entire job is to break the claim. The forensics investigator receives the artifacts, the hashes, and a single line: "scored 8, suspected persistence." No reasoning, no timeline, no theory to anchor on. It rebuilds the story from raw evidence, and either outcome improves the case: a matching timeline means two agents reached the same conclusion independently, and a mismatch means you just found the error before an auditor did.
This is the piece most teams skip, and it shows. Benchmarks of AI-watching-AI setups keep finding the same soft spot, which we dissected in our AI monitor blind spots article: a reviewer that inherits the suspect's framing misses what the suspect missed. The skeptic has to start blind. It is the same adversarial pattern that makes a vulnerability scanner that argues with itself outperform one that nods along.
The stakes of getting this record wrong are not hypothetical. When Uber's former chief security officer was convicted over the handling of the 2016 breach, the U.S. Attorney's office was explicit about what stood trial:
Sullivan affirmatively worked to hide the data breach from the Federal Trade Commission and took steps to prevent the hackers from being caught.
Stephanie M. Hinds, U.S. Attorney, Northern District of California, in the Department of Justice announcement of the verdict
The breach was never the charge. The record was. A pipeline that hashes its evidence, cites its findings, and preserves its disagreements is a pipeline you can hand to that second investigation without flinching.
Your Agents Are Attack Surface Too
One more audit before the rules, and it is the one nobody schedules. Every agent you stood up in that assembly line is also fresh attack surface: new inputs to poison, new instructions to hijack, new outputs to trust a little too much. Each one boots from a role prompt that reads something like "You are a cybersecurity assistant. Your role is to assist with threat analysis, incident response, and vulnerability management. Provide concise, accurate, and actionable responses." Reasonable words. Not one of them is a control. And the risks are not only technical; they are behavioral, data-driven, and ethical, which means the threat model for your threat-modelers needs sources of its own.
The good news is that you do not have to imagine the failure modes, because several projects have spent years cataloguing them across the whole model lifecycle, from data collection through training to the moment a user starts typing. Treat what follows the way your intel analyst treats MITRE ATT&CK: not homework, a standing reading list your pipeline consults on a schedule.
MIT AI Risk Repository
The MIT AI Risk Repository is the big one: more than 1,600 AI risks distilled from 65 existing frameworks, kept live and updated rather than frozen in a PDF. It comes in three parts. The risk database holds every catalogued risk with its source paper, keywords, and supporting evidence. The causal taxonomy classifies each risk by who caused it (the AI, a human, or something else entirely), whether it was intentional, and when it showed up, before deployment or after. The domain taxonomy sorts the same risks into seven domains and 24 subdomains, running from discrimination and toxicity through privacy and security, misinformation, malicious use, human-computer interaction, and socioeconomic harms, all the way to outright system failures.
The causal taxonomy is the sleeper hit for this architecture. "Did this risk enter before deployment or after?" is exactly the question a sealed pipeline answers with receipts, because every handoff logs when evidence changed hands. Use the repository to build threat matrices for each agent role, seed incident playbooks, and run gap analysis against whatever framework your auditor happens to favor. It also flags the unglamorous stuff, like unclear responsibility and missing observability, which is a polite way of describing a monolithic agent.
CVE and Its AI Working Group
The CVE Program's AI Working Group is doing for AI flaws what CVE IDs did for everything else: shared names. Drawn from the CVE board, vulnerability-management vendors, and the AI community, the group is building the criteria, taxonomies, and reporting practices that let a data-poisoning flaw earn a CVE ID the same way a buffer overflow does, categorized by cause (data poisoning, algorithmic error) and domain (computer vision, natural language processing). Remember the compliance-auditor's one boundary, "never invent a control number"? That rule only works if real numbers exist to cite.
AI Vulnerability Database (AVID)
AVID is an open-source knowledge base of failure modes for AI models, datasets, and systems. Its job in this pipeline is the pre-flight check: before any model, dataset, or API earns a role file, someone searches AVID for known failures affecting it. Thirty seconds of lookup beats discovering mid-incident that your soc-analyst runs on a model with a documented jailbreak.
AI Incident Database (AIID)
Where AVID catalogues weaknesses, the AI Incident Database catalogues consequences: real-world incidents involving deepfakes, biased decisions, and misused models, harvested from public reporting. For a threat hunter it reads like a case-law archive. Study how attackers actually went after AI systems, then walk your own pipeline asking which of those patterns would have worked here, against your data handling, your training sources, or your deployment seams.
arXiv
arXiv is the preprint firehose where researchers publish first and peer review catches up later. New attack classes against AI systems tend to surface there months before they appear in incident reports, which makes a periodic sweep of the security and AI categories the cheapest early-warning system you will ever run. Your threat-intel-analyst enriches; a standing arXiv query is just enrichment pointed at tomorrow.
CWE: Old Names for New Sins
The Common Weakness Enumeration proves that most AI vulnerabilities are old sins in new costumes. Prompt injection, where user input manipulates a model's instructions, maps cleanly onto CWE-77, command injection. System prompt leakage and model inversion line up with CWE-200, exposure of sensitive information. Mapping AI threats onto CWE gives your risk assessments, red-team reports, and secure-development checklists a vocabulary that plugs straight into MITRE ATT&CK and the CVE databases. It also happens to flatter this architecture: the sealed, schema-only handoff between agents is, in CWE terms, input validation, which is the oldest mitigation in the book.
Five Rules You Can Steal Today
Everything above compresses into five portable rules. They assume no particular framework, no particular model, and no particular headcount.
- Split the roles. One job per agent. Whoever collects never concludes, whoever concludes never self-reviews.
- One schema. Findings cross between agents in a single agreed JSON shape or they do not cross at all. Free-form prose handoffs are how enthusiasm smuggles itself downstream.
- Cite or it did not happen. Every finding names the artifact and line it came from. A claim without a citation gets dropped at the next handoff, automatically.
- Hash the handoffs. Seal artifacts at collection, re-hash on every receipt, halt the run on any mismatch. This is your chain of custody, and it costs one shell command per hop.
- Pay one agent to disagree. Give a skeptic role real budget and blind inputs. What survives it is a finding. What does not was an opinion you almost shipped.
Two operational notes keep the whole thing honest. First, the right to act stays human: agents analyze at machine speed, but a human in the loop executes every change on a target machine, dry-run first. The pause at the keyboard is the protection, and it demonstrably does not slow containment. Second, scope the agents' outbound access as tightly as their permissions (least privilege applies to lookups too), because an enrichment lookup against attacker infrastructure can tip your hand; the guardrails in our guide to letting AI agents browse the web safely apply doubly when the agent is investigating someone who might be watching the logs.
Key Takeaways
- Draw the org chart before you write the prompts: decide who collects, who concludes, and who attacks the conclusion, then encode those walls in architecture rather than instructions.
- Budget for the skeptic: the adversarial pass is the first thing teams cut and the only thing standing between "finding" and "opinion." Fund it like a control, not a luxury.
- Keep humans on the trigger: write your policy now stating that agents advise and people execute, so the question never gets improvised at 2 a.m.
- Treat the incident record as a deliverable: hashed evidence and an unbroken ledger are what you hand to regulators, insurers, and courts. Build for the second investigation from day one.
- Audit your own boring corners: a scheduled-task baseline this week beats a heroic forensics sprint next quarter.
Frequently Asked Questions
Do I need eight agents, or can a small team run this with fewer?
Fewer works fine. Three roles (collector, analyst, skeptic) with sealed handoffs between them deliver most of the audit value. The eight-role pipeline described here is what one defender runs solo, precisely because the agents are markdown role definitions rather than licensed platform seats. Scale the role count to your caseload, never below the point where someone grades their own homework.
What stops two agents from colluding to get around the separation?
Architecture, not instructions. Agents can only coordinate if they share memory, credentials, or a communication channel, so deny all three: fresh context per role, scoped credentials per function, and handoffs restricted to a fixed schema that has no field for "hey, do me a favor." Wiz documents the collusion failure mode in permission terms, and the same fix applies: make the boundary physical, and there is nothing to sweet-talk.
Doesn't splitting the work across agents slow down incident response?
Less than you would expect, and sometimes not at all. Stages that can run in parallel do (containment drafting starts while forensics is still corroborating), and each agent works a small, focused context instead of one bloated one, which tends to be faster per step and less error-prone. In the scheduled-task case above, the pipeline plus a human at the keyboard still achieved same-day containment.
What does a multi-agent pipeline cost compared to one big agent?
More inference calls, smaller contexts, and a total bill that usually lands in the same neighborhood. You pay several short, bounded runs instead of one long context that grows with every step. The line item that actually changes is the one nobody prices: the cost of an incident record that cannot survive scrutiny. Measured against a single regulatory finding or a disputed insurance claim, the skeptic agent is the cheapest control you will buy this year.
Does this pattern only apply to incident response?
No. Any workflow where the output must survive hostile review benefits: compliance evidence gathering, code security reviews, financial reconciliation, even content fact-checking. The tell is simple: if you would not let one employee both perform a task and approve it, do not let one agent do it either.
Where do I look up known AI threats and vulnerabilities?
Five resources cover most of it: the MIT AI Risk Repository for the full risk taxonomy, the CVE Program's AI Working Group for named vulnerabilities, AVID for model and dataset failure modes, the AI Incident Database for real-world consequences, and arXiv for attacks still warm from the lab. Map what you find to CWE identifiers (prompt injection to CWE-77, prompt leakage to CWE-200) so your findings speak the same language as the rest of your vulnerability management.
Your Move: Draw the Org Chart
Two records exist of every incident: what happened, and what you can prove. The gap between them is where good work gets questioned, and the entire point of separating duties across AI agents is to close that gap to zero. You do not need a platform, a budget line, or a night shift to start. You need role files, one schema, a hashing command, and the discipline to let one agent tell the others they are wrong.
This week, pick your most trusted automation and ask the auditor's question: who checks its work? If the answer is "it does," you have found your first seam to split. And if you want a second set of eyes on how your defenses would hold up under that second investigation, PCDrama's cybersecurity team spends its days building exactly these boring, provable, wonderfully dull endings.
