Article 12 Logging for Microsoft Fabric Agents

How do you meet EU AI Act Article 12 logging for AI agents on Microsoft Fabric?

You need to do three things, and the order matters.

One: capture the interactions. Turn on Microsoft Purview DSPM for AI so every Fabric Data Agent prompt, response, and piece of interaction metadata flows through the Microsoft 365 audit pipeline into the unified audit log. Each interaction produces a Copilot Interaction record with a timestamp, user identity, the agent and application details, associated resources, and the prompt or response (including any query or code the agent generated). Note that this feature is in preview as of the April 2026 Microsoft Learn docs, so treat the schema as movable.

Two: fix retention. Native Purview retention is tiered, not lifetime. Standard keeps records up to 180 days. You need a plan for the six-month floor in Article 26(6) and, realistically, for the multi-year window your risk team will actually ask for.

Three: make it defensible. Article 12 never says the word "tamper-proof." But a log an admin can quietly edit is worth nothing to an auditor, so you seal agent-action receipts into a hash-chained store the agent and its operators cannot rewrite.

Do all three and you have automatic lifetime logging that survives scrutiny. Skip the third and you have a preview feature with a retention timer.

What Article 12 actually requires

Article 12(1) of Regulation (EU) 2024/1689 says high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Two words carry the load. Automatic rules out someone writing things down by hand after the fact. Lifetime, as multiple readings of the text make plain, means deployment to decommissioning, not "whatever your license retains this quarter."

Article 12(2) says those logs have to serve three purposes: spotting situations where the system could present a risk under Article 79(1) or a substantial modification, feeding post-market monitoring under Article 72, and supporting the deployer monitoring in Article 26(5). If your agent runs biometric identification (Annex III point 1(a)), Article 12(3) gets specific: log the period of each use with start and end times, the reference database checked against, the input data that produced a match, and the people who verified the result.

Then Article 26(6) hands deployers a separate duty. Keep the automatically generated logs, to the extent they are under your control, for at least six months, unless Union or national law (data-protection law especially) says otherwise. Financial institutions can fold them into documentation kept under financial-services law.

So when does the logging duty bite? For the Annex III high-risk systems this targets, the substantive obligations including Articles 12 and 26 apply from 2 August 2026. High-risk AI embedded in a product covered by Annex I legislation gets until 2 August 2027. Timing and simplification of the high-risk regime have been under active discussion at EU level, so confirm the current applicable date against the Regulation before you file. The penalty tiers sit in Article 99 of Regulation (EU) 2024/1689, which sets fines of up to EUR 15 million or 3% of worldwide annual turnover for the relevant infringements, a reading echoed in analysis published in April 2026. Whatever the date lands at, it does not change what the log has to be.

What Fabric plus Purview gives you today

Microsoft built a real capture path. With auditing on, a Fabric Data Agent interaction becomes a structured Copilot Interaction record in the M365 unified audit log, holding the timestamp, the user, the agent and app identity, the resources touched, and the prompt or response text including generated SQL or code. Purview documents this same capture for Copilot and AI apps generally. It covers a lot of what Article 12(2) wants to see.

Getting there takes three toggles, and all three have to be on:

• Activate Microsoft Purview Audit for the tenant.
• Enable the DSPM-for-AI one-click policy "Capture interactions for Copilot experiences."
• Flip the Fabric Admin Portal tenant setting "Allow Microsoft Purview to secure AI interactions."

Miss one and you get partial capture or none, which is the worst outcome because it looks like it is working. And remember the preview label. Preview features carry no SLA and the terms can change, so re-verify what is actually captured before you cite it in a compliance filing.

Where native Purview stops being enough

Native Purview leaves two things unfinished, and both bear directly on Article 12.

Retention is tiered and license-gated. Per the Purview audit retention docs, Audit (Standard) holds logs up to 180 days. Audit (Premium) keeps Exchange, SharePoint, OneDrive, and Entra records for one year by default, with everything else at 180 days unless you build a custom retention policy. Stretching past 180 days needs Microsoft 365 E5 or the Purview eDiscovery-and-Audit add-on, and custom retention policies can extend records to a documented maximum of ten years, but only when you configure them and hold the licensing that allows it. The audit solutions overview spells out the same tiering. This is not "lifetime" retention, at least not by default.

It is not a chained tamper-evident record. The fair reading matters here. Microsoft markets the unified audit log as read-only during its retention window, so the accurate concern is not that admins freely edit records. It is that the log is retention-tiered, scoped to M365 and Fabric, and can lapse or get purged when a window closes or a policy changes. It is not a cryptographically chained record you can independently verify years later. For Article 12's lifetime bar, and for an auditor asking you to prove a record was not altered, that limitation is decisive.

Purview gives you a genuine capture layer, but the durable, verifiable vault has to come from somewhere else.

The threat model: why editable logs are evidentially worthless

A log is not just a filing obligation. It is how you learn that your agent was hijacked, and it is the evidence you hand a regulator afterward, which is exactly why attackers target it.

The OWASP Top 10 for Agentic Applications was published on 9 December 2025 by the OWASP GenAI Security Project, the first community-curated list of agentic failure modes. Its top category, ASI01 Agent Goal Hijack, folds classic prompt injection together with excessive autonomy. An attacker seizes the agent's decision-making, and because the agent executes multiple autonomous steps, one bad instruction cascades well past a single wrong answer. Related categories in the list cover tool misuse, identity and privilege abuse, memory and context poisoning, and rogue agents.

A hijacked Fabric agent holding valid credentials produces perfectly clean audit records. The Copilot Interaction entry looks normal because, from the pipeline's point of view, an authorized identity ran an authorized query. If that same record can later be edited or aged out of retention before anyone reviews it, you lose both the alarm and the evidence. Security analysis published in April 2026 made this argument directly: standard application logs that can be changed without detection are evidentially worthless to a regulator, so the fix is to cryptographically sign and hash-chain agent-action receipts and store them outside the agent's control. No finalized harmonized standard existed as of April 2026, so this is engineering judgment rather than a checkbox someone handed you.

MCP, the audit path, and data-plane governance

If your Fabric agents reach tools and data through the Model Context Protocol, the authorization design does real work for your logs. Fabric exposes and orchestrates data agents via MCP, and every MCP operation gets recorded in Fabric audit logs. The MCP authorization framework is built on OAuth 2.1 and, since the 2025-06-18 spec, treats MCP servers as OAuth Resource Servers. That gives you a clean chokepoint to log and authorize at. The same 2025-06-18 spec added Resource Indicators (RFC 8707) so a token binds to one specific server and cannot be replayed elsewhere, and the 2025-11-25 revision routes every UI-initiated action through the same audit and consent path as a direct JSON-RPC tool call, which keeps you watching one path rather than two.

This is the data-plane governance angle, and it is the part Purview alone will not give you. Purview records what the agent said, but it does not constrain what the agent can reach. If a hijacked agent still holds a broad token, a tidy audit trail records the breach in fine detail without preventing it. You want authorization decisions happening per tool call, at the data plane, and you want those decisions in the same tamper-evident record as the actions themselves.

Article 12 logging best practices for Fabric agents

How to build a log that holds up, in a practical order:

• Turn on all three Purview toggles and confirm capture. Run a known agent interaction, then find its Copilot Interaction record. Absence of evidence is not evidence of capture.
• Set retention deliberately. Do not inherit the 180-day default by accident. Map your window to Article 26(6)'s six-month floor and to whatever your sector law demands, then configure custom retention (and license it) instead of assuming it is handled.
• Seal receipts into a hash-chained store outside the agent. Each agent action gets a signed receipt, chained to the last, kept where the agent and its operators cannot rewrite history. That is what turns "we have logs" into "we can prove these logs were not altered."
• Log the authorization decision, not just the prompt. Which token, which tool, which rows, allowed or denied. That is your Article 12(2) risk-situation evidence.
• Keep the evidence plane alive. A log that goes dark during the incident you most need to reconstruct is useless. Monitor for gaps and make them visible.
• Alarm on ASI01 behavior. OWASP's own mitigation is rigid operational constraints plus continuous monitoring for anomalies. Wire that monitoring to the same record you are retaining.

The runway to 2 August 2026 is exactly the window to get this built before it is graded. Treat these as the logging foundation your broader security program builds on.

Where DataShield fits (and where it doesn't)

To be direct about it: DataShield is a complement to Purview, not a replacement, and it is not a prompt proxy.

DataShield Auth writes a hash-chained, tamper-evident audit log you can independently check at /verify, and Guardian keeps that evidence pipeline available so any gaps stay bounded and visible instead of silent. Together they map to Article 12's automatic lifetime logging and the Article 26(6) six-month-minimum retention, sitting alongside Purview's capture rather than swapping it out. Purview remains your interaction source, and the chained receipt store holds the evidence you can later prove was not altered.

The design idea worth borrowing, even if you never touch our stack, is to govern what agents can reach and not only what they will do. Tokenize sensitive fields at ingest so a hijacked agent finds tokens where it expected PII, authorize each tool call with mid-session revocation, and seal every call into the audit chain. More on the mechanics at /architecture and the sibling deep-dive, What EU AI Act Article 12 Actually Requires You to Log.

A couple of caveats so nothing gets quoted out of context. This is engineering and compliance mapping, not legal advice, and whether any native tooling "satisfies" Article 12 on its own is a lawyer's call. And DataShield has no SOC 2 attestation yet.

Watch: related explainers

Fabric governance with Purview, plus the injection threat your Article 12 log has to capture.

▶

Fabric governance and security with Purview (Microsoft Reactor)

▶

MCP prompt injection basics (TestMu AI)

▶

What is a prompt injection attack? (IBM Technology)

Frequently asked questions