Azure AI Foundry Agents: The Audit-Log Question Healthcare CIOs Need to Answer Before Production

What Foundry agents add to the BAA chain Healthcare CIOs running on Azure tend to take Foundry's HIPAA eligibility as a settled question. It is, at the platform layer. Microsoft's BAA covers Azure AI Foundry, including the Agents capability that sits on top of the model and tool surface. The chain we look for in an audit (cloud BAA → AI service BAA → application controls) is intact at the contract level. The contract level is where most procurement reviews stop. It is not where an OCR investigator or SOC 2 auditor stops. The Agents layer adds three things to the BAA chain that model-only deployments did not have: an orchestration runtime that decides which steps run in which order, a tool-call surface that reaches into systems holding PHI (FHIR endpoints, document stores, internal APIs, search indices), and a multi-step trajectory the agent navigates without a clinician in the loop on every step. All three sit inside the BAA. All three produce events your audit log has to capture. For an org already running Azure OpenAI under the Microsoft BAA, moving to Foundry agents is not a contract conversation; it is an architecture and configuration one. The questions that mattered for a single-shot deployment ("what did the model see, what did it return, who asked it") expand to "what tools did the agent call, what did each return, how did the agent compose those returns into the final completion." The BAA does not answer those questions. The agent-layer telemetry configuration does. The agent layer's audit-log surface Foundry agents emit telemetry across three surfaces, and the surfaces capture different things. Deployments that treat them as interchangeable, or assume "Azure Monitor is on" is the same as "the audit log is HIPAA-defensible", are the ones we most often have to remediate. The three surfaces: Foundry traces capture the agent's internal trajectory: which tool it chose, the inputs it composed, the outputs the tool returned, and the reasoning steps used to compose the final response. Traces are the highest-fidelity record of what actually happened inside the agent. Retention defaults are short and content capture is configurable in ways that matter for HIPAA. Trace export to a long-term store is not on by default in most deployments. Azure Monitor captures the platform-level events: agent invocation, user identity, request and response sizes, latency, success or failure. Monitor is reliable and integrates with the rest of your Azure observability. It does not, by default, capture prompt content, tool-call inputs, tool-call outputs, or completion content. A deployment whose entire audit story is "we have Azure Monitor on" has the metadata layer and none of the content layer. AI Studio logs sit between the two. Useful for development, evaluation, and incident review. Not the primary HIPAA retention surface. For an agent-layer deployment to be HIPAA-defensible, four pieces of telemetry have to be retained at HIPAA retention (six years from last access under the federal floor; longer in several states): 1. Prompt content: the clinician's input, including any PHI carried through to the agent 2. Tool-call inputs: the parameters the agent composed for each tool call, including any PHI pulled forward 3. Tool-call outputs: what each tool returned, including PHI from a FHIR endpoint or document store 4. Completion content: the final response surfaced to the clinician Three of those four are not retained at HIPAA-grade by default. The configuration that retains them, Foundry trace export, content logging, retention policy, and a downstream store with appropriate immutability and access controls, is the configuration most procurement reviews have not examined. Tool calls and minimum-necessary The HIPAA Privacy Rule's minimum-necessary standard is an old rule applied to a new shape of system. In a single-shot prompt-and-completion deployment, minimum-necessary is the prompt-construction question: did the application send only the PHI the model needed? In an agent deployment, the question moves down the stack. When an agent decides to call a tool that touches PHI, a FHIR query for medication history, a search over the clinical notes index, a lookup against the encounter database, the tool call is itself a PHI access event. The agent decided, autonomously, to access PHI. The audit log has to record that decision: which tool was called, with what parameters, against which patient record, returning what payload, in service of which clinician's original request. This is where most deployments break, and it breaks the same way. The team built the agent thinking of the tool surface as "internal plumbing" and instrumented the user-facing inputs and outputs without instrumenting the inter-step tool calls. The result is an audit log that can answer "what did the clinician ask" and "what did the agent respond" but cannot answer "which patient records did the agent access on the way." That third question is the one the OCR investigator asks in the breach scenario. Every tool registered to a Foundry agent that can return PHI has to carry the same audit-log discipline as a direct user-to-database access path: tool name, caller identity, parameters, response, timestamp, retention. Identity propagation through the agent chain The most common implementation mistake we audit at the Foundry agent layer is identity collapse. The clinician authenticates at the front end. The application calls the agent. The agent runs as a service principal. The service principal calls the tools. The tools log the service principal as the accessing identity. The audit log records that "the agent service account" accessed the patient record, not which clinician's request originated the access. For HIPAA, that is the wrong identity to log. For SOC 2, it breaks the access-review story. For a behavioral-health workflow with stricter state-law overlays (42 CFR Part 2 scenarios, the various state mental-health confidentiality regimes), it can be disqualifying. The fix is end-to-end identity propagation. Microsoft Entra is the identity layer the rest of the stack expects. The clinician's identity, captured at the front end, has to be carried as a token through the agent invocation, into each tool call, and recorded against the audit-log entry the tool emits. Foundry's agent runtime supports passing the caller's Entra identity through to Entra-aware tools; the configuration is documented but is not the default for every tool template. The pattern we recommend: SSO at the front end into Entra, on-behalf-of token flow into the agent, on-behalf-of token flow from the agent into each Entra-aware tool, and tools that reject service-principal-only calls when accessing PHI. The audit log then records the clinician's identity at every step. Access review becomes a query, not an investigation. Where the Diagnostic Fits, and three actions this week The Adopt-AI-Safely Diagnostic is the engagement we run for healthcare orgs deploying Foundry agents into production. Two to three weeks, fixed-scope, fixed-price written report. We document the agent topology, agents, tools, data sources, identity flow, evaluate it against the seven HIPAA controls AI tools must satisfy, score the BAA chain (intact at contract, scored on configuration), and produce a sequenced fix plan with cost ranges. The report stands on its own. For a Foundry agent deployment, the diagnostic centers on the four-piece audit-log telemetry above, the tool-call minimum-necessary question, and the identity-propagation review. The deliverable includes a configuration matrix for each agent and tool in scope. Three actions a healthcare CIO can take in five business days, regardless of whether they engage us: 1. Inventory the agent-tool topology. For every Foundry agent in development or production, list the tools registered to it and which tools can return PHI. Anything you cannot list, you cannot audit. 2. Run the four-piece audit-log check. For each agent, confirm whether prompt content, tool-call inputs, tool-call outputs, and completion content are retained at HIPAA retention in an immutable store. Three of the four are not on by default; the configuration is documented. 3. Verify identity propagation end-to-end. Pull a sample of tool-call audit entries and confirm the logged identity is the clinician's Entra identity, not the agent's service principal. If it is the service principal, the agent is not yet defensible. The Foundry Agents Audit-Log Configuration Worksheet walks each of the three. The HIPAA AI Architecture Field Guide is at . The diagnostic is at ; the productized retainer that follows it is . Healthcare context is at ; the regulated-SaaS framing, for HealthTech vendors deploying Foundry agents inside customer Azure tenants, is at . The vendor briefing index is at . Update: 2026-06-26 Editor's note: the product names above have drifted since this briefing first ran. Effective 2026-01-01, Azure AI Foundry was renamed "Microsoft Foundry," so any "Azure AI Foundry" references here are now stale. We also flagged that on 2026-05-31 Managed VNet reached general availability and project-level cost attribution shipped. Treat the original naming as historical; the capabilities and the new name are current.