Compliance Reporting for AI Agents

Compliance reporting for AI agents is the recurring, structured record of what your autonomous agents did at runtime, who authorized them, what data they reached, and how those actions map to the controls an auditor or regulator expects. The word that carries the weight is runtime. Traditional software compliance reports on deterministic systems with predictable code paths. Agent compliance reports on probabilistic systems that make decisions in real time and change their behavior week to week. That single difference reshapes every reporting practice downstream.

A useful report answers four questions. What agents exist and who owns them? What data and tools can each agent actually reach in production? What did each agent do during the reporting period? Which actions broke policy, and how were they resolved?

Three properties make this harder than application reporting. The subject moves: one Copilot Studio agent can connect to new data sources, adopt new tools, and run under different user contexts inside a single quarter, so a point-in-time report captures a moving target. The identity is a machine, not a person: agents hold bearer tokens, inherit service account credentials, and act on behalf of users, so every action needs attribution to both the invoker who triggered it and the maker whose credentials it ran under. And the proof lives at runtime: configuration shows what an agent could do, activity logs show what it did, and auditors are asking for the second.

Why agents force the question at all

An agent is effectively a machine insider. It carries real credentials and takes real actions, but it falls outside every insider risk, IAM, and access review program built around human employees. Without a reporting record there is no accountability trail, no way to answer a regulator's direct question, and no evidence that an autonomous decision stayed inside policy. When customers, auditors, and regulators ask which agents touch regulated data, who authorized them, and what they did last quarter, the teams who cannot answer face audit findings, lost contracts, and in some markets statutory penalties.

How it differs from traditional software compliance

The subject shifts from a codebase and a deployment to an agent identity, its tools, and its effective access. The change rate shifts from release cycles to continuous. The identity model shifts from a single human or service account to a chain of maker, invoker, and tool calls. The evidence shifts from config and code review to runtime activity correlated with identity. Blast radius stops being bounded by a fixed role and starts compounding as one agent's action feeds the next. Run runtime-first reporting once you have more than a handful of agents, cross-platform integrations, or connectors configured in maker mode. Configuration-only reporting is defensible only for a static, low-risk pilot.

Most agent compliance reports today are built from theoretical configuration. A team exports the agent list from the platform, screenshots the permission scopes, and hands that to the auditor. The evidence has a structural gap: it shows intended setup, not effective access.

Effective access is what an agent can actually reach inside a connected application after every entitlement, inheritance, and delegation resolves. An agent configured with one narrow OAuth scope can, through an inherited maker credential, read records the person invoking it was never entitled to see. An agent built by an administrator can act with administrator reach no matter who triggers it. The config page will not tell you that. Only the runtime activity, correlated to the identity that actually executed inside the app, will.

This is the difference between theoretical configuration and effective access, and it is the whole reason configuration-first reports pass audits while real exposure stays invisible. A report that lists an agent's declared scope is describing a claim. A report that shows the agent authenticated as a specific service account and read a specific set of Salesforce objects, or wrote to a specific set of tables, is describing what happened. Teams that have lived on the first kind describe the work as chasing ghosts: reviewing theoretical risk with no runtime record of any actual event.

The practical failures follow a pattern:

• Configuration-only reports understate blast radius because they never show inherited or delegated access.
• Log-only reports without identity correlation cannot name the actor behind an agent-mediated action.
• Single-platform reports miss the cross-platform chain, where an agent in one tool calls a connector that reads from another.

The fix is to source the report from real agent activity and correlate each action to the effective access it used inside the third-party app: which non-human identity, which objects, which actions. That correlation is the load-bearing artifact, and it is what a config export cannot reproduce.

The efficient way to report is to build one evidence base and produce framework-specific views from it. Re-collecting the same data for every audit is how reporting programs fall behind agent deployment.

A core evidence set includes:

• Agent inventory with creator, owner, platform, and creation date
• An effective access map showing what each agent can reach inside connected apps and under which identity
• Tool and MCP server connections per agent
• Runtime activity: tool calls, data reads, downstream actions
• Ownership status: active, disabled, orphaned
• Policy exceptions and their remediation records

That single base answers different frameworks with different views. NIST AI RMF asks for governance, an inventory to map, measurement of behavior, and management of risk, and the evidence base supplies each. ISO 42001 asks for a documented AI management system with evidence behind its controls. SOC 2 Common Criteria for logical access now has to account for non-human identities, which the effective access map and activity logs cover. HIPAA audit control requirements apply to any system that touches protected health data, agents included, and the runtime logs satisfy them. The EU AI Act's logging and record-keeping obligations for high-risk systems are answered by the same activity record. Build the evidence layer once. Render the control mapping per audit.

Framing note for anyone writing the actual control language: cite the specific article, clause, or section from the current published version of each framework rather than from memory, because the numbering and scope shift between revisions. The point here is the mapping discipline, not a fixed crosswalk.

What a single agent record should contain

At the row level, an audit-ready report should carry, per agent: creator, owner, platform, creation date, and stated purpose; ownership status flagging disabled or orphaned owners; the data classification of what it accessed (personal, health, financial, intellectual property); its tool and MCP server connections; an effective access summary; an activity summary of invocations, data reached, and downstream actions; policy exceptions with severity and remediation status; the framework control mapping; and a change log against the prior report.

Manual reporting fails the moment agent counts pass what a spreadsheet can hold, and they pass it fast. Enterprises routinely find hundreds of agents nobody catalogued and thousands built before any inventory began. Hand-tracking cannot match that velocity, which is why automating compliance reporting for AI agents is the only durable approach at scale.

Automation should cover four stages:

1. Continuous discovery. Detect new agents across your supported platforms as they are created, not on a quarterly sweep.
2. Continuous correlation. Map each agent to its maker, its invoker patterns, its connected tools and MCP servers, and its effective access inside connected apps.
3. Continuous risk scoring. Apply framework-aligned risk factors (org-wide access, maker mode with sensitive scope, orphaned owner, unsanctioned connector) and flag the toxic combinations.
4. Scheduled and on-demand reporting. Produce framework-mapped exports on the cadence your audit calendar needs, plus scoped reports for incident response.

Automating the report is not the same as automating enforcement, and the reports should say so plainly. Discovery, correlation, and reporting on agent activity are available today across the major agent platforms. Runtime enforcement that blocks an agent action as it happens exists today only for a narrow set of platforms, currently Claude and Microsoft Copilot. For every other environment (Agentforce, Snowflake Cortex, ServiceNow and Now Assist, Moveworks, Bedrock, Vertex, n8n and the rest) the honest scope is discover and govern: see the agent, map its effective access, report what it did. Treat autonomous blocking on those platforms as roadmap, not a present-tense capability, and never let a compliance report imply enforcement that is not in place.

Setting the cadence

A workable baseline runs continuous discovery, risk scoring, and alerting; weekly internal review of new agents, orphaned owners, and unsanctioned connectors; monthly GRC review of exceptions and remediation; quarterly framework-mapped reports for external frameworks and executives; an annual attestation package for external audit; and on-demand reports scoped to an agent or window when an incident hits. Regulated industries with mandatory logging should assume continuous evidence collection with quarterly formal reporting at a minimum.

Every report needs an exceptions section that documents each policy violation, its business context, and its remediation status. For agents, the recurring exceptions are familiar: agents running under disabled or orphaned owners, connectors in maker mode with sensitive data scopes, agents reachable without authentication, unsanctioned MCP server connections, and confused-deputy cases where an agent's elevated access served an invoker who should never have had it.

Each exception should record the agent ID and platform, the risk factor and severity, when it was detected, who was notified, what action was taken (revoke, reassign owner, restrict scope, decommission), and the evidence of closure. Auditors care less that exceptions exist and more that a documented process caught and handled them.

The common failure is closing an exception with "acknowledged by owner" and no configuration change behind it. When the report is sourced from runtime truth, the next cycle shows the same risk factor still live, and the auditor sees an exception that was annotated rather than remediated. Evidence-based closure means the underlying effective access actually changed, and the following report proves it.

Reports have to be legible to people who are not on the security team. GRC leads, internal auditors, and external assessors generally need three deliverables: an executive summary covering agent population, risk distribution, quarter-over-quarter change, and top exceptions; framework-mapped control evidence that ties each control to the specific artifacts satisfying it; and a detailed appendix of agent-level records for spot checks.

Give reviewers a single view that traces one agent from its inventory entry to its runtime activity to its exception closure. Fragmented reporting, one export per platform, forces auditors to correlate by hand and tends to generate more findings, not fewer. For sensitive audits, role-gate or redact prompt content and regulated data samples: the report needs to prove control effectiveness, not expose the underlying data.

A note on tooling

The market splits three ways. Platform-native audit logs go deep on one platform but do not correlate a maker credential to an invoker identity or to effective access downstream. Configuration-focused governance reports on how agents are set up, which helps with policy baselining but leaves the runtime gap open. Runtime-focused governance correlates configuration, identity, and actual activity across platforms into one evidence base.

Obsidian operates in that runtime layer. It builds an identity graph across supported AI platforms and correlates each agent's activity with its effective access inside the connected app, then produces framework-mapped evidence without needing a separate connector into every downstream system. It is not an inline gateway sitting in the request path. Where runtime decisions are enforced, the model is an "Intel Inside" decision engine that supplies the verdict to the platform that owns the action, which is why enforcement tracks the platforms that expose that control (today, Claude and Microsoft Copilot) while discovery, correlation, and reporting span the wider set. For a compliance program, the value is that the evidence you report is the evidence of what agents actually did.