Strix vs Microsoft Agent Governance Toolkit: breadth-of-surface vs depth-of-binding.

Concrete bypass scenario. Microsoft's stack ships three independent middleware modules: GovernancePolicyMiddleware (policy decision), CapabilityGuardMiddleware (capability enforcement), and AuditTrailMiddleware (audit log emission). If a future bug in CapabilityGuardMiddleware lets a call through that the policy decision should have denied, the AuditTrailMiddleware still records that the execution happened. The audit trail logs the bypass-as-if-legitimate; a regulator reading the log cannot distinguish the bypassed call from a properly-authorized one. Strix's signer (K-BIND-3) inverts this: the evidence write refuses to happen unless eight preconditions all hold simultaneously — the decision is actually in APPROVED state in the audit trail, the execution token was atomically redeemed (UPDATE ... WHERE status=ACTIVE), the parameter hash on the redeemed token matches the actual call parameters, the timestamps are strict-RFC3339 and ordered, the receipt ID is globally unique, and the (decision, token, evidence) tuple is unique. A bypass either leaves the audit trail missing the record (the signer refused) or requires multiple independent guards to fail in lock-step. Microsoft's stack is reviewable after the fact; Strix's stack makes the bypass-as-legitimate case unrepresentable in the first place. See solo-builder-core/src/execution-receipt-v1.ts for the precondition list.

The honest answer: if breadth-of-surface and free are your only criteria, you don't. Microsoft's toolkit is purpose-built for broad adoption across the Microsoft agent ecosystem and beyond. Strix is purpose-built for the buyer who needs depth-of-binding — cryptographic, parameter-hash-bound, atomically-redeemed, verifiable by an auditor offline. Those buyers exist (federal, finance, healthcare, EU-AI-Act-regulated providers) and they are the buyer Strix is for. If you're not that buyer, Microsoft is the more practical choice.

No. That attack class — Strix calls it AA-2 — is explicitly out of scope. Strix's actor-attestation primitive (AA-1) distinguishes a human-originated action from an AI-agent-originated action at the SDK call site; it does not detect an AI driving a human's already-authenticated browser session. Microsoft's Entra-based Authorization Fabric has identity-binding primitives (Continuous Access Evaluation, session-binding via Conditional Access) that close substantial parts of AA-2 for the Microsoft-platform buyer — we recommend evaluating those features if AA-2 is in your threat model. Strix publishes a dedicated AA-2 disclosure at docs/security/AA-2-OUT-OF-SCOPE.md naming exactly what we cover (AA-1, at the SDK call site), exactly what we don't cover (AA-2, at the IdP layer), and the three identity-stack-specific mitigation paths (Entra CAE, Okta Adaptive MFA, AWS Verified Access). The honest framing is the artifact: if you need AA-2 coverage, layer Strix's action-binding kernel on top of an IdP that enforces session-binding to hardware-attested credentials; if you need action-level signed evidence, Strix produces it regardless of how the authentication act played out.

Yes, by design. The natural pattern: Microsoft's Authorization Fabric returns the runtime policy decision; the decision becomes part of the context that Strix's signer binds into the signed evidence record. The two layers stack cleanly because they optimize for different things — Microsoft for decision breadth, Strix for binding depth. We'll publish a reference integration recipe once the Microsoft Agent Framework adapter ships in @strixgov/middleware-microsoft-agent-framework (on roadmap).

Different mechanism, equivalent expressiveness. Microsoft's MASK is a kernel-level decision state — the toolkit decides centrally to redact. Strix achieves the same outcome at the middleware layer: register read-and-write as separate capabilities, evaluate them separately, redact in the framework adapter before the response returns. The user-facing behavior is the same; the layer differs. A MASK-equivalent state in the Strix kernel is on the gap-closure roadmap if customer signal warrants it (see docs/strategy/competitive-capability-gap-analysis-v1.md).

Strix's policy engine is in-process TypeScript with deterministic content-addressable evaluation — typically low single-digit milliseconds end-to-end. Microsoft's sub-millisecond claim is for the out-of-process Agent OS package. For most production workloads (where the LLM call itself is hundreds to thousands of milliseconds) the difference is not the bottleneck. For high-throughput non-LLM agent loops, Microsoft's published number is the better fit and we acknowledge that.

Python and Go SDKs are on the roadmap. Rust and .NET are signal-dependent — we'll add them when customer pull justifies the byte-parity engineering cost. Every language SDK Strix ships must produce byte-identical signed records for the same canonical input as the Node SDK; that parity discipline is what protects the audit story and it scales sub-linearly with language count.

NemoClaw is a kernel-level sandbox (network namespaces, Landlock, seccomp, privilege separation) — OS-process isolation, not application-layer governance. It's complementary to Strix, not competing. The right stack for high-risk agent deployments: NemoClaw at the OS sandbox layer, Microsoft toolkit at the policy-decision layer, Strix at the cryptographic-binding layer.

Microsoft's toolkit is positioned around the OWASP Agentic Top 10 and operational runtime security. Specific EU AI Act article mapping with cryptographically-derived compliance flags is not part of Microsoft's published positioning today. The two compliance vectors complement each other; if you need OWASP-Top-10-explicit AND EU-AI-Act-article-explicit, running both layers is the cleanest answer.