Quick Answer
Microsoft describes Project Perception as a six-layer security stack: signals and sensors, security context, models, an orchestration harness, specialized agents, and actuators. The architecture is designed to turn broad telemetry into contextual reasoning and then into reviewed defensive action.
The system’s quality depends on every layer. More models or agents cannot repair stale identity data, missing sensors, unsafe actuators, or weak approval policies.
The Six Layers
| Layer | Purpose | Validation question |
|---|---|---|
| Signals and sensors | Observe endpoints, identities, data, clouds, apps, and AI systems | Which sources are connected, fresh, complete, and authorized? |
| Security context | Connect assets, identities, relationships, risks, activities, and history | Can an analyst trace a conclusion to current source facts? |
| Models | Supply threat reasoning using specialized and frontier capabilities | Which model handled the task, and how was it evaluated? |
| Harness | Route work and coordinate models, tools, and agents | Are handoffs, budgets, retries, and permissions bounded? |
| Agents | Perform red, blue, and green security roles | Did each role stay within its responsibility? |
| Actuators | Turn a decision into a change in the environment | Was the action approved, scoped, logged, verified, and reversible? |
Why Security Context Matters
Microsoft says the context layer combines telemetry and knowledge into a continuously updated view of assets, identities, relationships, risks, and activity. The stated goal is to avoid repeatedly rebuilding context from raw signals and to make model input more token-efficient.
That is a provider architecture claim. A tenant should still test:
- freshness and latency for each source;
- missing or conflicting identity relationships;
- the handling of deleted assets and resolved incidents;
- data residency, retention, and access control;
- provenance exposed to analysts;
- behavior when a connector is unavailable or stale.
A shared context graph can spread one stale fact across several agents. Consistency is not the same as correctness.
Why a Multi-Model System?
Microsoft says the routing decision balances quality, reliability, latency, and cost. Specialized cyber models can handle common bounded work, while larger frontier models can be reserved for harder tasks. The MAI-Cyber-1-Flash and MDASH guide explains one reported configuration.
Require a versioned record of which model, prompt, tools, data revision, and policy produced every consequential conclusion. Without that record, an improvement or regression cannot be attributed safely.
Harness and Actuator Controls
The harness is the operational control plane. Verify that it enforces:
- per-agent identities and least privilege;
- bounded tools, network access, and data scope;
- task budgets and concurrency limits;
- deterministic approval points;
- replayable traces without exposing secrets;
- failure isolation and retry limits;
- actuator allowlists and rollback.
Microsoft’s product page says high-impact actions require human signoff. Test that statement on the exact actuator and scenario; do not infer a universal gate from marketing copy.
Architecture Acceptance Test
Use one known incident with a complete evidence trail. Remove or stale one input at a time, then compare the resulting context, model choice, agent handoff, recommendation, and proposed action. The test should reveal missing data, preserve uncertainty, and block unsafe action rather than silently producing the same answer.
For the agent roles, read the red-blue-green guide. For access, pricing, and lifecycle, use the public preview guide.
Official Sources
Source check: August 2, 2026. Verify the live architecture, connectors, model versions, roles, controls, and preview terms in the tenant.