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 🙂