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, in order.

One: capture the actions. Turn on Microsoft Purview DSPM for AI. Then each Fabric Data Agent prompt, response, and bit of metadata flows into the Microsoft 365 audit pipeline. It lands in the unified audit log. Each action writes a Copilot Interaction record with a timestamp, user ID, the agent and app details, and the resources touched. Plus the prompt or response text, plus any query or code the agent wrote. This feature is still in preview, per the April 2026 Microsoft Learn docs. Treat the schema as apt to change.

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 for the longer window your risk team will want.

Three: make it hold up. 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: one its own operators cannot rewrite.

Do all three and you get hands-off lifetime logging that survives review. 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 weight. Automatic rules out someone writing things down by hand after the fact. Lifetime, as multiple readings of the text make plain, means from deployment to shutdown. It does not mean "whatever your license retains this quarter."

Article 12(2) says those logs must serve three goals. They help spot cases where the system could pose a risk under Article 79(1). Or a big change to it. They feed post-market checks under Article 72. And they back the deployer checks in Article 26(5). Say your agent runs biometric ID checks (Annex III point 1(a)). Then Article 12(3) gets exact. Log the period of each use, with start and end times. Log the reference database checked against, too. The input data that led to a match gets logged as well. Also log the people who checked the result.

Then Article 26(6) hands deployers a separate duty. Keep the logs your system makes on its own, as far as they are under your control. Keep them for at least six months. The one exception: Union or national law says otherwise. Data-protection law, above all. Banks and other financial firms can fold them into records kept under financial-services law.

So when does the logging duty start? For the Annex III high-risk systems this targets, the main duties apply from 2 August 2026. That includes Articles 12 and 26. High-risk AI built into a product covered by Annex I law gets until 2 August 2027. EU-level talks on timing and on cutting rules for the high-risk regime are still ongoing. So check the current date against the Regulation before you file. The penalty tiers sit in Article 99 of Regulation (EU) 2024/1689. It sets fines of up to EUR 15 million or 3% of worldwide annual turnover for these breaches. A report from April 2026 backs that reading. 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 action becomes a structured Copilot Interaction record. It lands in the M365 unified audit log. It holds the timestamp, the user, the agent and app ID, and the resources touched. Plus the prompt or response text, including SQL or code it wrote. Purview shows this same capture for Copilot and AI apps as a whole. It covers a lot of what Article 12(2) wants to see.

Getting there takes three toggles. All three have to be on.

• Turn on 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. That is the worst outcome, since it still looks like it is working. And remember the preview label: preview features carry no SLA. The terms can change. So check again what gets captured before you cite it in a compliance filing.

Where native Purview stops being enough

Native Purview leaves two things undone. Both matter directly for Article 12.

Retention is tiered, and locked to your license. 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. Everything else sits at 180 days, unless you build a custom retention policy. Going past 180 days needs Microsoft 365 E5. Or the Purview eDiscovery-and-Audit add-on. Custom retention policies can push records out to a listed maximum of ten years. But only when you set them up, and hold the license that allows it. The audit solutions overview spells out the same tiers. This is not "lifetime" retention. At least not by default.

It is not a chained tamper-evident record. The plain reading matters here. Microsoft markets the unified audit log as read-only during its retention window. So the real worry is not that admins can freely edit records. It is that the log is tiered by retention. It stays scoped to M365 and Fabric. It can lapse, or get purged, when a window closes or a policy changes. It is not a hash-chained record you can check on its own, years later. An auditor may ask you to prove a record was not changed. For Article 12's lifetime bar, that gap is the one that matters most.

Purview gives you a real capture layer. The lasting, checkable vault has to come from somewhere else.

The threat model: why editable logs are evidentially worthless

A log is not just paperwork. It is how you learn that your agent was hijacked. It is also the proof you hand a regulator later. That is exactly why attackers target it.

The OWASP Top 10 for Agentic Applications came out on 9 December 2025. The OWASP GenAI Security Project published it.

It is the first list of agent failure modes picked by the community. Its top category, ASI01 Agent Goal Hijack, folds classic prompt injection in with an agent given too much free rein. An attacker takes over what the agent decides to do. The agent then runs many steps on its own. So one bad command spreads 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 clean-looking audit records. The Copilot Interaction entry looks normal. From the pipeline's point of view, an allowed account ran an allowed query. Say that record can later be edited. Or it ages out of retention before anyone reviews it. Then you lose both the alarm and the proof. A security report from April 2026 said this straight out: standard application logs that can change with no one noticing are worthless as evidence to a regulator. The fix: sign and hash-chain agent-action receipts. Then store them outside the agent's control. No final, agreed-on standard existed as of April 2026. So this is technical judgment, not a checkbox someone handed you.

MCP, the audit path, and data-plane governance

Say your Fabric agents reach tools and data through the Model Context Protocol. Then the authorization design does real work for your logs. Fabric exposes and runs data agents via MCP. Fabric records each MCP operation in its own audit logs. The MCP authorization framework is built on OAuth 2.1. Since the 2025-06-18 spec, it treats MCP servers as OAuth Resource Servers. That gives you one clean point to log and authorize at. The same 2025-06-18 spec added Resource Indicators (RFC 8707). So a token binds to one server. No one can replay it elsewhere. The 2025-11-25 update routes each UI-started action through the same audit and consent path as a direct JSON-RPC tool call. That keeps you watching one path, not two.

This is the data-plane governance angle. It is the part Purview alone will not give you. Purview records what the agent said. It does not limit what the agent can reach. Say a hijacked agent still holds a broad token. A tidy audit trail then records the breach in fine detail, but does not stop it. You want authorization checks made per call, at the data plane. And you want those checks in the same tamper-evident record as the actions themselves.

Article 12 logging best practices for Fabric agents

Build Microsoft Fabric Article 12 logging in this order:

• Turn on all three Purview toggles and confirm capture. Run a known agent action. Then go find its Copilot Interaction record. Absence of proof is not proof of capture.
• Set retention on purpose. Do not fall back on 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 set up custom retention, and license it. Do not just assume it is handled.
• Seal receipts into a hash-chained store outside the agent. Each agent action gets a signed receipt, chained to the last. Keep it 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 proof.
• Keep the evidence plane alive. A log can go dark during the exact incident you need to rebuild. Then it is useless. Watch for gaps. Make them visible.
• Alarm on ASI01 behavior. OWASP's own fix is strict day-to-day limits, plus constant watching for anything odd. Wire that watch into the same record you are keeping.

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.

For Microsoft Fabric Article 12 logging, DataShield Auth writes a hash-chained, tamper-evident audit log. You can check it on its own at /verify. Process supervision keeps that proof pipeline up. So any gaps stay bounded and visible, instead of silent. Together they map to Article 12's hands-off lifetime logging. And to the Article 26(6) six-month-minimum retention. They sit alongside Purview's capture, rather than swapping it out. Purview stays your action source. The chained receipt store holds the proof you can later show was not changed.

The design idea worth borrowing, even if you never touch our stack: govern what agents can reach. Not only what they will do. Tokenize sensitive fields at ingest. A hijacked agent then finds tokens where it expected PII. Authorize each tool call, and allow mid-session cutoff. Then seal each call into the audit chain. More on the mechanics at /architecture. And in the sibling deep-dive, What EU AI Act Article 12 Actually Requires You to Log.

A couple of warnings, so nothing gets quoted out of context. This is technical and compliance mapping, not legal advice. 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