Above Microsoft Agent 365.
Microsoft Agent 365 is publicly described as a control plane for agents — agent identifiers, authorization policy, hosted runtime, and an internal audit log. Bonis Knox is the externally-anchored AAM evidence layer above it. This brief documents the operational seam: how an Agent-365 deployment emits structured action records, how an operator-controlled emit path canonicalizes them, how Knox produces the tamper-evident chain, and how an external party verifies without contacting Microsoft, the operator, or Bonis.
Documenting the seam in advance of General Availability.
Microsoft has publicly announced General Availability of Agent 365 for 2026-05-01, with a Tech Community AMA on 2026-05-12. Technical buyers evaluating Agent 365 during this window are also evaluating the agent governance, observability, and audit layers that compose above it.
This brief documents one such layer — the AAM evidence layer — as a worked example. The same operational pattern applies to AWS Bedrock agent runtime, Google Vertex AI agent runtime, Rubrik Agent Govern, and any other control plane that emits structured action records. Sibling briefs for those control planes will follow the same shape as this one.
Naming Microsoft Agent 365 here describes the operational seam. It does not imply that Microsoft is a partner, customer, prospect, or operational counterparty of Bonis Systems. The brief is published so the operator who chooses Agent 365 can also choose an externally-anchored AAM layer with full visibility into how the two layers compose.
What each layer does — and what it does not do.
A mature deployment runs all four layers. Agent 365 publicly addresses three of them. Knox addresses the fourth — the layer that produces externally-verifiable evidence of what the agent actually did.
Entra Agent IDs (Microsoft-side)
Who is this agent, cryptographically?
Microsoft has publicly described Entra Agent IDs as the identity surface for agents in an Agent-365 deployment. Knox composes alongside any agent identity scheme — the chain-of-command stamp on each Knox event embeds the agent identifier the operator's emit path supplies.
Agent 365 control plane (Microsoft-side)
What is the agent permitted to attempt?
Publicly described as the policy layer for agents — tool allow-lists, data scopes, counter-party rules. Knox does not authorize and does not duplicate the policy layer; the AAM record describes what was attempted and what happened, not what was permitted.
Foundry Hosted Agents / Microsoft runtime (Microsoft-side)
How does the agent's call actually run?
Microsoft has publicly described Foundry Hosted Agents and the Agent-365 hosted runtime. Knox is runtime-neutral: action records emitted from any Microsoft-hosted runtime are content-addressable and anchorable on the same primitive as records from any other runtime.
Bonis Knox AAM (this layer)
What did the agent actually do, and is the record still verifiable years from now?
Content-addressed commitments, hash chain, hourly Merkle aggregation, Bitcoin anchor, post-quantum signature option. Produces tamper-evident records the layers above cannot rewrite. Verifiable by an external party without contacting Microsoft, the operator, or Bonis.
Five steps from Agent-365 action to externally-verifiable evidence.
The integration is operator-side. Microsoft's surface is not modified. Bonis does not access any Microsoft tenant. The operator owns the emit path and the canonicalization rules that produce the commitment payload Knox receives.
Agent 365 emits a structured action record
A Microsoft-side surface (the Agent-365 audit log, the Purview audit log, or an in-app event hook the operator subscribes to) produces a structured record describing an agent action — agent identifier, action correlation identifier, tool invoked, target resource, outcome, timestamp.
Operator emit path canonicalizes the record
An operator-controlled service (a function in the operator's tenant, an in-house relay, or a third-party governance product the operator subscribes to) reads the structured record, applies a canonicalization rule the operator declares once, and produces a deterministic byte sequence — the canonical commitment payload.
Operator hashes the canonical payload
The canonical payload is hashed with SHA-256 to produce a 32-byte commitment. The hash is the only data leaving the operator boundary. Microsoft-side identifiers, tenant data, and content remain inside the operator's boundary unless the operator explicitly chooses to include them in the canonical payload.
Operator submits the commitment to Knox
A POST to /api/knox/anchor with the commitment, the chosen Knox event type (e.g. agent_run_complete, agent_authority_revoked, agent_mcp_tool_call), and an operator-side signature (optionally ML-DSA-87 for post-quantum resistance). Knox returns the anchor identifier, the chain sequence number, and the predecessor chain link.
External verification, no Bonis dependency
Any party with the anchor identifier or the canonical commitment hash calls /api/knox/verify (or reconstructs the verification from the public Bitcoin chain). The verification proves the commitment existed at the recorded time. It does not require Microsoft, the operator, or Bonis Systems to be online or cooperative.
Picking the right Knox event type for an Agent-365 action.
The Knox event taxonomy includes types appropriate for agent-lifecycle, authority-lifecycle, and tool-call records. The operator picks the type that best describes the structured Agent-365 action being committed. Mapping examples below; the canonical taxonomy lives in src/lib/knox-anchor.ts.
Agent run starts on a delegated task
Agent run completes (success or partial)
Agent run fails or aborts
Agent invokes a tool through the runtime
Tool returns a structured response to the agent
Agent fetches a resource the runtime exposes
Operator revokes an agent's authority
Agent signing key rotates
Operator changes an agent's policy
Hosted runtime attests to its server identity
Operators not satisfied by an existing type can request a taxonomy extension. New event types are added under the taxonomy-lint discipline that prevents drift between the canonical type list, the agent-feed.json public surface, and this page’s claims.
Scope discipline — the part that protects the operator.
Does not authorize
Knox does not decide whether an agent action is permitted. That is the control plane’s job. Knox records what happened — including actions that should never have been permitted. The audit value comes precisely from being independent of the policy layer.
Does not authenticate
Knox does not decide who an agent is. That is the agent identity layer’s job (Entra Agent IDs in this deployment). Knox records the identifier the operator emit path supplies and the signature the operator-side key produces. Trust in the identifier flows from the identity layer; trust in the record flows from the public chain.
Does not access tenant data
Knox sees the canonical commitment and the chosen event type. Tenant data, Microsoft-side identifiers, and the content of the agent action remain inside the operator boundary unless the operator explicitly includes them. The hash is the only signal leaving.
Does not replace the Microsoft-side log
Purview, Defender, and the Agent-365 audit log serve the operator and Microsoft in real time. Knox serves the external party years later. The two layers answer different questions and run in parallel.
Common questions, answered.
What is the seam between Microsoft Agent 365 and Bonis Knox?
Microsoft Agent 365 — as publicly described — provides agent identifiers, authorization policy, hosted runtime, and an internal audit log. Bonis Knox is the externally-anchored AAM evidence layer above that. The seam is structured action records: an Agent-365 deployment emits a record of an agent action; an operator-controlled emit path canonicalizes that record, hashes it (SHA-256), and submits the commitment to Knox via the public anchor endpoint. The commitment then enters the Knox hash chain and the hourly Bitcoin Merkle anchor — externally verifiable for as long as the public chain exists.
Does Bonis access any Microsoft tenant or surface?
No. Defensive-Only doctrine binding. The operator instruments their own emit path inside the boundary they already control. Bonis receives the canonical commitment payload at the public anchor endpoint and produces the Knox event record. Bonis never reads Microsoft tenant data, never queries Microsoft APIs, never accesses Entra, Purview, Defender, or Foundry surfaces directly.
Is this brief a Microsoft partnership announcement?
No. Naming Microsoft Agent 365 here describes one operational seam in the public agent-control-plane landscape. It does not imply that Microsoft is a partner, customer, prospect, or operational counterparty of Bonis Systems. The brief documents the architectural fit; the operator decides whether to instrument it.
Why publish this before Microsoft Agent 365 General Availability?
Microsoft has publicly announced General Availability of Agent 365 for 2026-05-01 with a Tech Community AMA on 2026-05-12. Documenting the AAM seam in advance of GA gives technical buyers evaluating Agent 365 a vendor-neutral evidence-layer reference point during the same evaluation cycle. The brief is written so the same operational pattern applies to AWS Bedrock agent runtime, Google Vertex AI agent runtime, Rubrik Agent Govern, or any other control plane that emits structured action records.
Which Knox event types map to Microsoft Agent 365 actions?
The canonical Knox event taxonomy in src/lib/knox-anchor.ts includes agent-lifecycle types — agent_run_start, agent_run_complete, agent_run_failed — plus authority-lifecycle types — agent_authority_revoked, agent_key_rotation, agent_policy_revocation — plus the MCP audit family (agent_mcp_tool_call, agent_mcp_tool_response, agent_mcp_resource_fetch, agent_mcp_prompt_invocation, agent_mcp_server_attestation, agent_mcp_policy_change). An Agent-365 action record is mapped onto whichever Knox type best describes the structured event; the Knox payload preserves Microsoft's own identifiers (agent identifier, tenant identifier where the operator chooses to include it, action correlation identifier) inside the canonical commitment so the chain is reconstructible from the operator's side without contacting Bonis.
Does Knox compose alongside Microsoft Purview or Defender, or replace them?
Composes alongside. Purview and Defender are internal-to-Microsoft audit and security surfaces serving Microsoft customers. Knox is the externally-anchored chain that survives the stack — independent of Microsoft, independent of the operator, independent of Bonis. The two layers answer different questions: the Microsoft-internal layer answers what the tenant administrator and Microsoft can see in real time; the AAM layer answers what an external party (court, regulator, acquirer, dispute counterparty) can verify years later without trusting any single vendor.
Is the AAM record post-quantum-secure?
Yes — for the operator-side and Knox-side signatures. Knox Agent #11 Layer 4 ships ML-DSA-44 / 65 / 87 (NIST FIPS 204) and SLH-DSA-128s / 192s / 256s (NIST FIPS 205) post-quantum signatures, deployed live on terravault-00360-gkv on 2026-04-24. ML-DSA-87 is the same primitive specified in academic agent-trust protocols including AITH (arXiv:2604.07695). Operators who require post-quantum resistance on the AAM signature can opt into ML-DSA-87 via the standard signing parameters — independent of which classical signature scheme Microsoft uses internally.
How does an external party verify a Knox-anchored Agent-365 record?
By calling the public Knox verify endpoint with the anchor identifier or the canonical commitment hash. The endpoint returns the chain link, the hourly Merkle aggregation, and the Bitcoin block embedding the Merkle root. Verification does not require Microsoft, the operator, or Bonis Systems to be online or cooperative — only the public Bitcoin chain via OpenTimestamps. This is the property that makes the AAM record useful to a third party years after the action.
Does this brief cite Microsoft documentation directly?
References to Microsoft Agent 365 features (Entra Agent IDs, Purview audit logging, Foundry Hosted Agents, Microsoft Defender) describe publicly-announced product surfaces. Operators evaluating the integration should consult Microsoft's own published product documentation for authoritative feature definitions, pricing, and roadmap. This brief documents only the AAM seam from the Bonis side — the canonical commitment shape, the event-type mapping options, the verify path. The Microsoft side of the seam is the operator's to instrument under whichever Microsoft license terms apply.
References here describe the operational seam, not relationships.
Naming Microsoft Agent 365 on this page describes a publicly announced control-plane product and the architectural seam where Bonis Knox composes above it. It does not imply that Microsoft is a partner, customer, prospect, or operational counterparty of Bonis Systems. Operators evaluating the integration should consult Microsoft’s own published product documentation for authoritative feature definitions, pricing, license terms, and roadmap. The Bonis side of the seam is documented above; the Microsoft side is the operator’s to instrument under whichever Microsoft license terms apply.