Proving AI Agent Control to Your Board

AI agent board reporting fails the moment it confuses activity with control. An auditor and a board ask the same question in different languages. The auditor asks whether a control exists, is documented, and was tested. The board asks whether the business is safe and whether the CISO can prove it. Both answers have to come from runtime truth, not from a vendor's configuration page.

For a board, control has to mean four things at once. You know every agent that exists, including the shadow agents no one sanctioned and the orphaned ones whose owners already left. You know what each agent can actually do, which is its effective access, not its theoretical configuration. You are governing or blocking policy violations at runtime, or you are accepting the risk with explicit sign-off. And you hold evidence you could hand to a regulator: timestamped, correlated, reproducible. Miss any one of the four and you are reporting activity dressed up as control.

The gap between those two things is specific. A configuration says what an agent should be able to do. Runtime evidence shows what it did, which service account it borrowed, and which records that account touched. Security teams have a name for the failure mode when only the first exists: ghost chasing, reviewing theoretical risks with no runtime evidence of what actually occurred. Boards can smell it.

Why boards own this risk personally

Directors carry liability when material risk goes unmanaged, and agent risk has crossed into material. The 2025 Salesloft Drift campaign, tracked as UNC6395, reached roughly 700 organizations by abusing stolen tokens rather than any traditional breach indicator. Agents authenticate with those same non-human identities, so every over-permissioned agent is a supply chain exposure sitting inside a trusted integration.

Scale is the other reason. Agents move roughly 16x more data than human users, and around 90% are over-permissioned in the apps they touch. The operational exposure is now larger than the human insider program the board already funds, and it lives in a place the board has never been shown.

What an agent actually is, in board terms

An AI agent is software that uses a language model to take multi-step actions on behalf of a user through tools, APIs, and app integrations. Unlike a chatbot, it executes. It reads mail, updates records, runs queries, moves files. It does this using a non-human identity, usually an OAuth token or a service account credential.

The board-relevant twist is delegation. When an agent is built in maker mode, it runs with its creator's credentials no matter who invokes it. A user with no Salesforce access can call an agent built by a Salesforce admin and pull records they were never provisioned to see. The agent broke no rule. Your identity controls were simply bypassed, and only runtime capture shows it happened.

Boards do not care about protocol specifications. They care about business exposure, and they tend to ask about it in the same order every time.

How many agents operate here, and who owns them? This is the inventory question. If you cannot give a number and an ownership breakdown, everything after it loses credibility. Some enterprises discover hundreds of Copilot agents in a single assessment. Others find thousands built before security was ever consulted. A count without owners is not an inventory; an agent with no named owner cannot be remediated.

What is the worst thing one of these agents could do today? This is the blast radius question, and it requires effective access mapping rather than a scope review. An agent labeled read-only can still exfiltrate a database by chaining actions across connected tools. The honest answer names the specific reach: which service account, which objects, which tables.

Are we blocking bad actions, or just watching them? This is the enforcement question. Detection without prevention is expensive logging. Boards learned to ask it directly after supply chain incidents showed how fast a compromised integration moves.

If a regulator asked tomorrow, could we prove it? This is the evidence question. Dashboard screenshots do not survive an audit. Correlated runtime logs do.

The risks behind the questions

Four failure modes drive most real incidents, and each maps to one of the questions above.

• Privilege escalation through maker mode, where an invoker inherits the creator's admin credentials and bypasses identity controls.
• Orphaned agents, where the creator's account is disabled but the agent keeps running on inherited credentials.
• Shadow tool sprawl, where agents connect to unsanctioned MCP servers no security team has inventoried, sometimes doubling in count quarter over quarter.
• Action chaining, where one agent hands off to another and each hop compounds blast radius across apps.

Board-relevant measurement has nothing to do with model accuracy or task completion. It measures coverage and risk reduction. Three metric families carry the report.

Coverage. Percentage of agent platforms under runtime observation. Percentage of agents with an identified owner. Percentage of tool servers inventoried, sanctioned versus unsanctioned.

Effective access. Number of agents with reach beyond what their workflow needs. Number of maker mode connectors that touch sensitive data. Number of orphaned agents. This is the family where the real work lives, because it correlates an agent's runtime activity to the exact service account it used and the specific objects or tables that account can reach inside the connected app. That correlation, not a config export, is what turns a vague risk into a named one.

Governed and blocked actions. Runtime actions governed or blocked, broken down by platform. Toxic combinations remediated. Time to remediate by severity. This family carries a labeling obligation, covered below, because the ability to block is not the same on every platform.

The table maps each metric to what it proves and to the platform reality you must report accurately.

What existing tools cannot give you

GRC platforms can hold the policies and track remediation. SIEM tools can ingest agent events if they are formatted for it. Neither can reconstruct an agent's tool calls, correlate a maker mode credential with the identity that invoked it, or map effective access across app entitlements. Those require runtime capture into an identity graph, which is not a native capability of any tool built for human users. If your metrics come only from those systems, your report has a hole in it that an auditor will find.

A detect-and-alert posture creates the feeling of control without the substance. The alert fires after the agent has already moved the file or triggered the workflow. Agents act in seconds. Alerts get triaged in hours. For non-deterministic software operating on live credentials, that gap is the whole risk.

Runtime enforcement works differently, and it is worth being precise about the model. Obsidian is not an inline proxy sitting between the agent and the app. It is a decision engine the platform consults at runtime through native APIs, returning an allow, govern, or block verdict before the action completes. Think of it as an "Intel Inside" layer the platform calls, not a chokepoint every request has to route through.

Here is the labeling discipline your board deserves. Autonomous blocking at runtime is live today for Microsoft Copilot and Claude only. For Salesforce Agentforce, Snowflake Cortex, ServiceNow Now Assist, Moveworks, Amazon Bedrock, Google Vertex, and n8n, the capability today is discover and govern: full inventory, effective access mapping, policy definition, and alerting. Runtime enforcement on those platforms is on the roadmap and should be reported as future work, never as a control you already hold. A board that later learns you overstated coverage will discount every number you present after that.

Configuration says should; runtime says did

Policy compliance evidence needs three artifacts: the versioned policy, the runtime observation that the policy was applied to a specific action, and the outcome of allowed, governed, or blocked. A configuration snapshot is not evidence. It states intent. Runtime capture states fact, and only fact survives an incident review.

Why agent monitoring is not a traditional audit

A traditional audit samples static configuration at a point in time and asks whether the system is set up correctly today. Agent oversight has to run continuously, because the same agent with the same configuration takes different actions in different contexts. Traditional audit logs capture human actions. Agent oversight has to capture tool calls, cross-platform handoffs, and delegated action chains, none of which appear in a log built for human identity events.

The board sees one page. Everything else is appendix. Four short sections carry it.

Coverage. X platforms under runtime observation. Y agents inventoried. Z percent with resolved ownership.

Top toxic combinations. Named risks with severity. For example: fourteen agents holding maker mode credentials with org-wide accessibility, six remediated this quarter, eight open with a remediation date. Each one tied to the service account and the data it can reach, so the risk is concrete rather than abstract.

Governed and blocked actions. Runtime actions governed or blocked, by platform, with the enforcement-live platforms clearly separated from the discover-and-govern ones. Do not blur the line.

Unresolved risk. What you know about and have not yet fixed, with an owner and a timeline. Boards trust a CISO who names unresolved risk more than one who presents a spotless dashboard.

Who reads which layer

The full board reads the one page. The audit committee chair, accountable for controls testing, and the risk committee chair, accountable for exposure and remediation posture, read the underlying evidence. A technology committee, where one exists, weighs build-versus-buy decisions on agent platforms. Match the artifact to the reader and you avoid drowning the board in agent-level detail it does not want.

The mistakes that undermine the page

Boards go wrong in predictable ways. They treat agents as a footnote to model risk, when the operational exposure lives at the agent layer. They accept inventory counts with no ownership data. They approve "we monitor it" as if monitoring were enforcement. And they skip the shadow question, which leaves the inventory incomplete by definition. Naming these in your own reporting shows the board you already closed the gaps they might otherwise probe.

Quarterly cadence fits steady state. Shorter fatigues the board; longer misses material change. The point of the rhythm is that the evidence generates itself between meetings so the report is a byproduct, not a fire drill.

Between meetings, feed the identity graph continuously through native platform APIs and endpoint telemetry, correlating each agent's configuration with its runtime behavior and scoring findings against OWASP low-code and no-code risk categories and your internal policy. Two weeks out, pull the coverage numbers, resolve ownership gaps, and pick the top three toxic combinations to surface. During the meeting, present the one page and answer the four questions directly. After it, capture the board's questions as inputs to the next cycle, because good AI agent board reporting matures alongside the board asking for it.

Framing cost and ROI without theater

When budget comes up, frame it as cost per agent under control rather than total platform spend, and set it against the recovery cost of a single supply chain incident of the kind that reached roughly 700 organizations. On value, give the board both sides in their own terms: productivity gain measured in workflow hours, and risk reduction measured in blast radius contained. A specific incident-avoided line lands hardest. For example: this quarter we found three maker mode connectors reaching customer PII and remediated all three before any external exposure.

When an agent gets it wrong

Escalate outside the quarterly rhythm for material events: an orphaned agent discovery, a maker mode privilege escalation, or a shadow tool server compromise. When something does go wrong, runtime capture is what lets you assign root cause, distinguishing a hallucinated action from delegation abuse from a confused deputy whose elevated permissions were steered by a lower-privileged user. A postmortem without tool call reconstruction cannot tell those apart, and a board will not accept a root cause you cannot show.