Divan-e-Cyber
As with cybersecurity, interpretation and attribution count.
-
These are the highlights of my talk at CDC Germany 2026 in Hanau on October 1: “Deploying an AI Security Risk Framework + Continuous Monitoring.”
Read more: These are the highlights of my talk at CDC Germany 2026 in Hanau on October 1: “Deploying an AI Security Risk Framework + Continuous Monitoring.”Most of what the industry calls agentic security risk is exposure management, identity hygiene, and telemetry you already know how to run. What’s missing is not theory. It’s blueprints that someone can build from. I’ve been writing them, and more of us should.
The board and the SOC are describing the same risk in different languages
CISOs talk about risk in GRC terms because that’s what the board hears. SOC teams work from attacker behavior. Neither side can act on the other’s vocabulary.
So I put both on one grid. Eight board-level risk scenarios, from data leakage to model theft, sit on one side. On the other, I placed observed activity: six cases from Anthropic’s September 10 threat report, plus one from Microsoft’s reporting on device-code phishing. AI-orchestrated intrusion, malware rebuilt when detections fired, credential and token theft, mailbox exfiltration at scale. The placement is illustrative, not a risk score. The point is that the board’s top concerns, data leakage, unsafe decisions, and autonomous actions, are already showing up in real operations. None of it needs a new discipline.
That mapping is how you move a CISO. Start in the board’s language, then show where the categories overlap with problems they already fund. “This is as bad as that” changes minds faster than any framework.
Microsoft draws a big circle. It doesn’t cover the page.
Microsoft does some capabilities well. It gives partial signal on others. For policy design, workflow management, cataloging, specialist testing, and service management, it doesn’t get there.
Those gaps aren’t tool problems. They’re integration, workflow, and organization problems, the same ones SIEM teams have complained about for a decade. Microsoft still has no CMDB, and I don’t know why.
Your job is to decide what fills the gaps. If you anchor your career there, you’ll have work forever. Expect to bring in a third-party service management or ticketing tool. The moment vendors try to overlap several capabilities in one product, suddenly people think they’re delivering the whole workflow when they are delivering a tool.
What a blueprint looks like: agent identity and registry
Here is the pattern, kept deliberately short:
- One credential per agent blueprint: a federated identity credential with managed identity or a certificate. No client secrets in production.
- Child agents get tokens through the blueprint, by impersonation only.
- Conditional access and agent risk gate every issuance. This is the big change, and it’s what builds trust.
- Define consent geometry up front. Decide what the admin actually reviews when approving, and what inherits to future child agents.
- Pick one registry. Don’t run one per hypervisor, hyperscaler, or business group. Converge where most of your data already lives.
- Don’t hard delete. Disable, retain, and keep watching. If you assume an agent is gone, you’ve made a dangerous assumption. The Anthropic report describes malware that was rebuilt when detections fired.
- Log the task actor, meaning the orchestration layer behind the workflow: your SOAR, Logic Apps, or Power Automate. Treat its tasks like any other detection source.
This design gives you a threat model, a repeatable build, and the ability to reconstruct what an agent decided and why. Store it as code in the same repo as your AI infrastructure and anyone can test it later.
Design for failure, not for the demo
Four things I missed in my first round of blueprints:
- Which judgment is being delegated. Stopping at a red light is five judgments: see the light, lift off the gas, press the brake, hold the wheel, check the road. If you can’t say which one the agent owns, the delegation is too vague.
- What the system can do without approval. “Everything already granted” is the wrong default for enterprise security. Allow-list thinking is painful, as anyone who ran Carbon Black Protect remembers, but it points the right way.
- What must be recorded and attributable. Walk a multi-agent investigation as a tabletop and write down what you wish you had logged.
- What happens when telemetry or confidence disappears. Attackers look for where your telemetry isn’t reporting. If a compensating control is the reason you didn’t catch something, you also need to know when that control goes dark.
Every autonomous loop needs the same things: a start condition, triggers, and stop conditions. An agent that keeps cycling on missing fields and bad data is the failure mode people get angry about.
Measure what changes a decision
You don’t have to invent KPIs. Track the share of agents with a named owner, consequential actions behind approval gates, telemetry coverage, responses you can reconstruct, incident pathways you’ve tested, and how fast exception requests get an answer. Slow exceptions push people to route around you. If a metric doesn’t change a decision, a control, or a priority, stop collecting it.
What to do now
The worst move in this transition is keeping patterns to ourselves. Pick a use case nobody has written up, such as misuse, policy bypass, or data sovereignty, and write the blueprint. Make it buildable and testable, and small enough that people actually adopt it. Want to co-create? Reach out.
-
Two findings from Anthropic’s multiagent research are solvable. One needs our help.
Read more: 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.
-
Microsoft Solved Four Governance Problems. A Fifth One Is the Reason to Pay Attention.
Read more: 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 🙂
🔐 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.
© 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.
