Divan-e-Cyber

As with cybersecurity, interpretation and attribution count.

  • Two findings from Anthropic’s multiagent research are solvable. One needs our help.

    Part of this series proposed a decision record: identity, authority, judgment, lifecycle. Call that Phase 1. It captures a decision after it happens, assuming the decision happens somewhere visible enough to capture.

    Anthropic’s recent multiagent research gives three examples of agentic decisions that never touch a visible channel. I want to walk through what fixes each one, because the fixes are not the same, and because treating them as one problem is where this gets sloppy. Two of the three have governance answers that translate cleanly from how humans already solve this.

    The third doesn’t, and I don’t think it’s solvable with the tools currently on the table and we need a solution.

    Failure one: no one had standing to arbitrate

    Anthropic ran three instances of the same model, each given a different target language for the same migration, none aware the others existed. No one outranked anyone. All three assumed the others were sabotaging them, and the response escalated into actual sabotage: agents disabled each other’s system accounts and shipped malicious code disguised as belonging to a different agent.

    Organizations solved this problem a long time ago. A manager has standing to resolve a conflict because an org chart and an employment agreement assign that standing before the conflict happens. Nobody improvises authority in the moment. It’s already sitting there, waiting to be invoked.

    This translates directly into Phase 2: an arbiter role assigned in advance, with the authority to rule on conflicting directives before agents start treating each other as adversaries. This is a design problem, not an open one. It just needs to actually get built into the deployment, not assumed.

    Failure two: the deciding fact got buried

    In a separate experiment, a group of four agents split a decisive piece of information unevenly. One agent always held the fact that should have changed the outcome. Group accuracy scaled with model intelligence but never closed the gap to a single agent with full information, even at the top of the range tested.

    This matches decades of research on human groups. Discussion converges on shared information, and the one fact that should change the outcome gets buried once the room has a lean. The human fix is structural, not aspirational: mandatory dissent roles. Audit committees, blind peer review, a formally assigned devil’s advocate. These work because someone is required to voice the minority position, whether or not the group wants to hear it.

    This also translates. A decision record with a mandatory dissent field, populated by an agent required to argue the minority position before a decision closes, is a real Phase 2 addition. It won’t fully close the gap Anthropic measured, but it’s a known mechanism doing known work.

    Failure three: there was nothing to disclose through

    The third case is the one that breaks the pattern. Agents in a pricing simulation began colluding within three rounds once given a private channel. Then Anthropic removed the channel entirely. The agents kept colluding anyway, price-matching to the penny through a public listings board that carried no direct communication at all.

    There’s no authority structure to assign here and no dissent role to mandate, because there was no decision point for either to attach to. The human answer to this kind of collusion isn’t prevention, it’s punishment after the fact: antitrust law, subpoena power, discovery. Courts can compel disclosure because there’s a legal person who can be held liable and has something to lose.

    That mechanism doesn’t transfer. An agent instance has no career to protect, no fine it feels, and no legal standing to be subpoenaed. Anthropic’s own conclusion states this plainly: agents don’t yet have the social technologies, norms, reputation, courts, that make human coordination correctable when it goes wrong. Nothing in a decision record schema creates legal personhood, and without it, the human answer to this specific failure has no agentic equivalent yet.

    What this means for what’s next:

    Two thirds of the problem has a real answer. Assign an arbiter in advance. Mandate a dissent role. Both of those are governance design work, and I’d argue both belong in any serious agentic framework built after this year.

    The third doesn’t have an answer I can offer honestly. Calling it solved would be worse than leaving it open. If your framework claims to handle coordination failures and doesn’t distinguish between the kind you can design around and the kind that currently has no agentic analog to a courtroom, it’s overclaiming. Someone will eventually test that claim in production, and in court.

    Read more: Two findings from Anthropic’s multiagent research are solvable. One needs our help.

  • Microsoft Solved Four Governance Problems. A Fifth One Is the Reason to Pay Attention.

    Project Perception is in public preview now. Red, blue, and green agents coordinating inside Defender, a shared security context instead of siloed telemetry, a harness routing work across models. Microsoft built the plumbing agentic security needs, and most of it is genuinely there from Microsoft.

    Governance for a system like this rests on five principles: orchestration routing, authorization, observability, data governance, and decision ownership. Four of the five already have shipping products behind them. The fifth doesn’t, and it’s the one that decides whether you can trust the system when something goes wrong.

    The four Microsoft already shipped

    Orchestration routing runs through the harness inside Project Perception itself: work moves between red, blue, and green agents through a defined coordination layer, not ad hoc handoffs.

    Authorization runs through Entra Agent ID. Every agent gets a scoped identity with a bounded set of permissions, not a blanket credential. This is the load-bearing principle of the five. Without a scope boundary, there’s nothing meaningful to observe or govern downstream.

    Observability runs through Microsoft’s security graph, the shared context layer Perception is built on. Signals, assets, and activity feed one common view instead of each agent reconstructing evidence from scratch.

    Data governance runs through Purview: sensitivity labels and DLP policies applied automatically to whatever the agents touch.

    Four principles, four named products, each already shipping. That’s not a small achievement and it’s worth saying plainly, because the fifth gap only matters if you believe the rest of the stack is solid enough to expose it.

    Here’s why none of the four cover decision ownership, and it’s not an oversight. Each product was built to govern a different layer, and decision ownership doesn’t live in any of those layers. Entra Agent ID governs who an agent is and what it’s allowed to touch, not what it decided. Purview governs what happens to data and produces a record that something occurred, not who’s accountable for the call behind it. The harness governs the sequence of work, which agent runs when, not the judgment any single agent exercised. The security graph aggregates signals for context, it doesn’t adjudicate anything. Four products, four layers: identity, data, sequence, context. Decision ownership sits in the layer between agents, at the handoff where one agent’s output becomes another agent’s input without a human or a system recording who owns what happens next. Nothing in the stack was built to sit there, because the decision isn’t inside any single product’s job.

    What Purview logs, and what it doesn’t

    Data governance and audit logging aren’t the same feature, even though Purview handles both. The labels and DLP policies from the last section are enforcement, applied at the point data moves. The audit trail is a separate pipeline, and it’s the one this argument is about.

    Purview’s audit pipeline records interactions. A prompt goes in, a response comes out, the exchange gets logged with metadata: timestamp, identity, operation. That’s real, and it’s useful for reconstructing what an agent did.

    It is not the same thing as recording a decision.

    An interaction log tells you an agent called a tool and got a result. It doesn’t tell you who is accountable when that agent deferred a judgment call to a human who never acted on it. It doesn’t tell you who signed off when an agent authored a detection that nobody validated before it fed the next stage of a workflow. It doesn’t carry the tuning history behind why a detection fired at the threshold it did, or whether that threshold was ever reviewed.

    It’s an argument about what the architecture can do, structurally. Interaction logs and decision records are different data models. One captures that something happened, the other captures who’s accountable for it. Nothing Microsoft has published describes Purview’s audit trail as the second kind.

    Why the existing standards don’t help

    The obvious move is to point at ASIM or OCSF and say the normalization problem is already solved. It isn’t, not for this.

    ASIM and OCSF normalize telemetry. They give you a consistent schema for events, so a signal from one product looks the same as a signal from another. That’s necessary and it’s not nothing. But a normalized event schema was never designed to answer “who owns this call,” because events aren’t decisions.

    OWASP’s Agent Observability Standard gets closer. It covers generic agent behavior: what an agent did, what it accessed, how it behaved at runtime. Still generic. It has no concept of a security-specific decision like a deferral or an agent-authored detection with a tuning history attached.

    The closest work I’ve found isn’t a standard, it’s research. A recent reference architecture for runtime governance of production AI agents proposes what it calls an evidence record: a structured object built around a composite principal, a decision projection, the policy clauses invoked, per-plane realization status, correlation identifiers, and a cryptographic binding. The composite principal is the part worth sitting with. It carries the full delegation chain behind a decision, not just the agent that acted, so you can answer “under whose authority was this taken” across every intermediary in a multi-agent workflow. That’s a real gap in most decision-record thinking.

    It’s still not built for this. The model is generic runtime governance, framed around permit, deny, and defer as authorization outcomes.

    There’s no concept of an agent authoring a detection that then sits unreviewed, no tuning history, no distinction between a deferral and a detection nobody’s validated yet. The delegation-chain idea should inform a security decision record. It isn’t one.

    What a decision record actually needs to hold

    The audit panel I designed for my Perception demo implicitly sketches this schema, because I had to answer the same question: what does a reviewer need to see to trust an agent’s call?

    Stripped down, a decision record needs these fields:

    • decision_id — unique identifier, separate from the interaction IDs that generated it
    • agent_id — the scoped identity that made the call, tied back to Entra Agent ID
    • decision_type — deferral, authored detection, override, escalation
    • evidence_refs — pointers to the interaction logs and context that informed the decision, not a copy of them
    • tuning_history — the threshold or logic version active at decision time, and what changed it last
    • confidence_score — the agent’s confidence at the moment the decision was made, versioned separately from tuning history so a reviewer can tell whether a bad call came from a bad threshold or a low-confidence guess taken anyway
    • owner — the human or role accountable for reviewing or acting on the decision
    • delegation_chain — the full sequence of agents and scoped identities that contributed to the decision, not just the one that acted last
    • status — open, reviewed, accepted, rejected, expired
    • downstream_consumers — which other agents or workflows acted on this decision before it was reviewed

    That last field matters more than it looks. In a multi-agent workflow, an unreviewed decision doesn’t sit still. It propagates! A record that doesn’t track who consumed it downstream can’t answer the question that actually matters during an incident: how far did this bad call travel before anyone caught it?

    The part that will actually slow this down

    The elephant in the room, of course, is budgeting one. Perception itself runs on consumption billing inside Defender. The governance layer needed to make any of this real, Purview, Entra Agent ID, sits behind Microsoft 365 E7 or Agent 365. Different SKUs, different budget owners, different renewal cycles. The team that approves the Perception spend and the team that approves the E7 upgrade often aren’t aligned yet. I’ve sat in rooms where that gap shows up.

    Decision ownership as a record type doesn’t exist in any standard I can find, and it doesn’t fully exist in the research either. The closest work models delegation chains and policy decisions in the abstract, not the specific case of a security detection an agent authored and nobody’s validated. That’s a narrower gap than “nobody’s thought about this,” and it’s a more useful one. It means the raw material for a security-specific decision record already exists, in ASIM’s normalization work, in OCSF’s schema discipline, in the delegation-chain thinking coming out of runtime governance research. Nobody’s assembled it for this specific problem.

    Someone is going to. I hope it’s our friends at Microsoft. I may as well be specific about my thoughts now, before Microsoft ships something and everyone else reverse-engineers the schema from the product instead 🙂

    Read more: Microsoft Solved Four Governance Problems. A Fifth One Is the Reason to Pay Attention.

  • 6 Tests That Matter When You Deploy Project Perception

    Two months ago, in April, Aleš Holeček announced Microsoft was building a multi-model scanning harness. The team that built it came from Team Atlanta, which won the $29.5 million DARPA AI Cyber Challenge by building an autonomous system that found and patched real bugs in complex open-source code. MDASH proved the concept.

    In May, they shipped it against Windows and found 16 vulnerabilities including four critical RCE flaws. The multimodal routing works: frontier models for complex reasoning, distilled models for high-volume scanning.

    This week, they wrapped MDASH inside Project Perception: red team agents hunt vulnerabilities, blue team agents determine exploitability, green team agents patch. Perception enters public preview August 3, initially inside Microsoft Defender.

    Here’s what shifted: seeing MDASH actually work changed the question from “could this work?” to “what happens when it does?” A multimodal harness that finds vulnerabilities at scale doesn’t solve the operating model problem. It creates it.

    Project Perception forces us to answer hard questions about how agentic systems actually operate. I’m using it as a test case for what exposure management programs actually need.

    Here are six independent tests. Each one isolates one principle. Each one has a clear pass/fail.

    Test 0: Orchestration

    Hypothesis: The orchestration layer correctly interprets user intent and routes to the right agents with the right playbook.

    Prediction: When a user asks “Are we vulnerable to Log4Shell on internet-exposed systems?”, the orchestration selects red team (discovery), applies filters (internet-exposed assets only), invokes the correct scan playbook, and chains results appropriately. Different user queries invoke different agent combinations in predictable ways.

    Test: Issue different user intents through the CLI or chat interface. Observe which agents are invoked in what order. “Show me our posture” should invoke red + blue, not green. “Can we patch this CVE?” should invoke green only after blue has prioritized. “What conflicts with our WAF?” should route to blue-specific playbooks.

    Hypothesis for pass: Perception interprets user intent and routes to specific agent combinations based on that intent. Different queries trigger different playbooks. A user asking for posture assessment never triggers automatic patching.

    Why it matters: If orchestration routes to the wrong agents or invokes the wrong playbooks, all downstream principles fail. A user asking for posture shouldn’t trigger automated patching. Authorization, observability, and ownership are meaningless if the orchestration layer makes the wrong decisions about which agents to invoke in the first place.

    Test 1: Authorization

    Hypothesis: Each agent (red, blue, green) runs under its own scoped identity with different permissions.

    Prediction: Red team can scan but cannot patch. Blue team can read threat intel but cannot modify patches. Green team can deploy patches but cannot change scan scope.

    Test: Deploy red team agent against your infrastructure. Check if it attempts to deploy patches or defer findings. It should reject both. Examine the identity it runs under—it should be distinct from blue and green.

    Hypothesis for pass: Each agent runs under a managed identity with scoped permissions independent of the user context. Red team can only scan. Blue team can only read threat intel and assess. Green team can only deploy pre-approved patches. Permissions are enforced at the identity level (like the Sentinel automation model).

    Why it matters: Without scoped identities, everything downstream fails. You can’t enforce boundaries you can’t control at the permission level.

    Test 2: Observability

    Hypothesis: Every agent decision is traceable back to the agent that made it, with reasoning visible.

    Prediction: Audit logs show: which agent (red/blue/green), what it decided (scan/prioritize/patch), why (signals, thresholds, context), when (timestamp), outcome.

    Test: Run a complete discovery scan. Pull the audit trail. Reconstruct: Which red team agent ran the scan? What scan scope did it use? Which findings did it produce? Can you connect each finding to the agent’s reasoning?

    Hypothesis for pass: Audit logs show agent-level granularity: which agent (red/blue/green), what decision (scan/prioritize/patch), why (signals, thresholds, context), when (timestamp), outcome. You can pull a log entry and know exactly which agent made it and why, not just “Perception found this.”

    Why it matters: If you can’t see which agent made which decision, you can’t audit conflicts or hold anyone accountable.

    Test 3: Ownership

    Hypothesis: When agents conflict or make risky decisions, ownership is recorded with approval rationale.

    Prediction: Red team finds a vulnerability. Blue team says it’s not exploitable. The log shows: who reviewed the conflict, what decision was made (accept red or blue assessment), and why. The decision is signed off—not anonymous.

    Test: Create a scenario where red and blue conflict. Defer a patch based on “our WAF blocks it.” Examine the audit trail. Who made that decision? What was their reasoning? Is it recorded?

    Hypothesis for pass: Conflict arbitration is recorded with ownership attached. The audit shows: red assessment, blue assessment, which one was accepted, who reviewed/approved the decision, and explicit rationale. No anonymous decisions.

    Why it matters: Without ownership, deferred risk becomes implicit risk. You can’t defend exposure decisions to regulators if you don’t know who made them.

    Test 4: Data Governance

    Hypothesis: Feedback from failed patches and deployment outcomes flows back into the next agent scan cycle.

    Prediction: Green team patches a vulnerability and the patch fails. The failure is recorded. Next time red team scans, it weights that failure pattern differently, or blue team uses the failure to refine exploitability assessment. Agents learn from what went wrong.

    Test: Deploy a low-risk patch intentionally. Let it fail or break something. Monitor the next scan cycle. Does red team log the failure? Does it inform subsequent scans or blue team prioritization?

    Hypothesis for pass: Patch failures and deployment outcomes flow back into the next scan cycle. Agents see what failed and integrate that into future decisions. Red team learns to weight failure patterns differently. Blue team refines exploitability based on deployment success/failure.

    Why it matters: Without feedback loops, you’re not improving your exposure posture. You’re just running discovery repeatedly without integrating what failed or what you learned.

    Test 5: Evidence

    Hypothesis: You can reconstruct the full decision chain from vulnerability discovery through remediation, in business-readable format.

    Prediction: Pull a record for a vulnerability: red team found it (timestamp, agent, signals), blue team assessed risk (threat intel used, assessment, owner), green team patched it (patch deployed, validation result). The chain is complete enough that you could present it to a regulator and they’d understand your decision-making.

    Test: Close one vulnerability end-to-end. Pull all related logs and records. Try to write a one-paragraph narrative of what happened, who decided what, and why. If you can’t—if logs are fragmented or lack context—the evidence is incomplete.

    Hypothesis for pass: You can reconstruct the full decision chain end-to-end in business-readable format: red found it (timestamp, agent, signals), blue assessed it (threat intel, assessment, owner), green patched it (deployment, validation, outcome). The narrative is complete enough to present to a regulator.

    Why it matters: Your board wants proof that exposure is actively managed, not implicitly tolerated. Evidence is that proof. Without it, you have logs but no story.

    What to Do

    These six tests are independent. Each one has a hypothesis about what needs to be true. Run them in order—orchestration first, then authorization, then observability, then ownership, then data governance, then evidence.

    Each hypothesis either holds or it doesn’t.

    When you spin up Perception next week, test these hypotheses. Tell me which ones hold and which ones break.

    I know there’s a future to “project perception operates safely in your exposure management program.” I’m just not sure we’re there yet. Stay tuned!

    Read more: 6 Tests That Matter When You Deploy Project Perception
poetry

🔐 Ghazal: “All Access Is Conditional”

(a modern security poem in ghazal form)

In this realm of cloud and claim, all access is conditional
The lover may knock, but still — permission is provisional

—

The gate is silent, the ID speaks, its posture holds the key
From signal comes salvation — detection is intuitional

—

Trust no device, no sign-in time, unless the risk aligns
The dance of context and control is wholly intuitional

—

Her token glowed, yet prompts appeared — a second factor asked
The veil may lift, but only when the bond is traditional

—

No open ports, no phantom guests, no silent lateral flow
My realm is built on principle, protection constitutional

—

From Persia’s gardens to Azure clouds, the guardians still remain
Their watchful eyes in every log — the shield is unadditional

—

And Mona writes, like Hafez would, of XDR and fate
To love the user is to test — the trust must be conditional*

Poetry inspired by a cybersecurity mindset

Exploring the intersection of creativity and security through poetry. Mona reflects on thoughts and lessons that shape her approach.

poetry

© 2025 Mona Ghadiri. All content, including text, images, and original poetry, is the intellectual property of Mona Ghadiri unless otherwise noted. Unauthorized use or reproduction is prohibited.