A Foundry agent trace is not an authorization record

Separate execution authority from observability

A trace can show that a model call, retrieval, tool selection, or downstream request occurred. It does not by itself establish that the requesting identity was entitled to act, the tool scope matched policy, required approval was obtained, or the resulting business transaction was accepted by the authoritative system. The architecture record should identify the human, agent, service principal, model, session, tool, credential, policy decision, approval, target object, outcome, and rollback reference as distinct fields linked by stable identifiers.

Define what end to end actually covers

Map the trace boundary across the user interface, orchestration service, model route, retrieval layer, guardrail, custom code, MCP or other tool connection, API gateway, business application, queue, and human-review step. Test whether retries, fallbacks, asynchronous work, cached context, delegated identities, browser actions, and failed writes remain connected to the original request. A platform trace may be useful while still omitting the system-of-record event, identity-provider decision, external provider log, or manual approval that determines accountability.

Govern telemetry as production evidence

Specify required fields, clock synchronization, correlation IDs, redaction, encryption, access, integrity protection, retention, export, legal hold, regional location, monitoring ownership, and incident escalation. Preserve enough input and configuration context to reproduce a decision without copying secrets, personal data, privileged material, or full prompts into a broadly accessible log. Validate sampling and truncation under load. Built-in evaluators can flag output qualities, but their scores need versions, thresholds, false-positive review, and a route to the underlying event evidence.

Run a four-event reconstruction test

Before production, reconstruct one permitted read, one denied action, one approved high-consequence write, and one partial failure followed by recovery. An independent operator should be able to identify who initiated the work, which permissions and policy applied, what data and tool versions were used, what the model proposed, what was approved, what changed, and how the system returned to a known state. Microsoft supplies provider positioning and architecture components; the buyer's configured service, tests, logs, and operating ownership determine whether the evidence is usable.

Turn this source into a reviewable decision

For AI for CIOs, use this briefing as a dated decision record rather than a substitute for the source. Preserve Microsoft, the exact URL, the August 13, 2026 review date, the supported facts above, the editorial interpretation, the limitations, and any buyer-specific evidence. Link that record to the decisions most directly affected: Identity and agent access; Service management and employee support; Operations and incident intelligence; Enterprise AI platform architecture. State whether the source changes the scope, evidence requirement, control, sequence, or only the language used to describe the decision.

Before action, name the accountable owner, affected population and workflow, exact offering or configuration, source data and rights, human decision point, exception and appeal path, complete cost, expected benefit, failure and stop conditions, retained evidence, and next review date. Keep official facts, provider statements, buyer observations, representative tests, measured outcomes, editorial inferences, and unknowns visibly separate. Reopen the record when the source, offer, model, integration, data, policy, population, responsible person, or measured result changes.

Limitations and unknowns

Microsoft is the provider source. Its current Foundry page describes models, routing, agents, tools, grounding, control-plane integrations, tracing, evaluators, and security positioning but does not independently establish a buyer's configured identity boundary, trace completeness, log integrity, authorization, control effectiveness, reliability, security, compliance, or recovery. Current architecture, documentation, contracts, configurations, test evidence, operating telemetry, and qualified architecture, security, privacy, procurement, compliance, and legal review control.