When AI Agents Access Enterprise Data, Governance Has to Run in the Execution Path

Quick Answer

• AI data governance: Governs the data, definitions, permissions, and evidence AI systems depend on.

• AI data readiness: Ensures enterprise data is accessible, consistent, governed, and fit for its intended AI use.

• Enterprise AI governance: Extends controls and accountability across AI systems, data access, and execution.

You cannot govern machine-speed data access with a PDF policy and a quarterly audit. Once agents can discover models, generate queries, and chain actions together, governance has to sit in the execution path.

Here is one failure mode I worry about. A regional sales manager asks an AI agent which accounts are at risk. The metric is correct. The SQL is valid. But the AI connection runs through a broad service identity instead of preserving the manager's entitlement, so the result includes customers from every region.

Nothing failed at the database layer. The query succeeded. The governance failed.

That distinction matters because a technically successful AI query can still be a security, compliance, or business-risk event.

Financial institutions are already running into this problem. In American Banker research sponsored by Strategy, based on 101 banking and financial-services executives and decision-makers, governance and compliance emerged as the most frequently cited barrier to scaling AI, named by 55% of respondents. In a separate CIO Dive study of large-enterprise technology leaders, 87% said they want greater visibility into how AI systems use and interpret their data.

Enterprise AI governance is moving from policy to architecture.

Governed context answers what the agent should know. Continuous assurance answers what the agent may access, what it actually did, and whether you can prove it afterward.

Continuous assurance means applying governance while AI operates, not reconstructing control after the fact.

The control loop has four parts:

Prevent → Detect → Prove → Improve

The first job is to prevent bad access or bad interpretation before the query runs.

Security answers one question: Is this user allowed to access the data?

It does not answer another: Does the AI understand what the data means?

An agent may be authorized to query a customer table and still use the wrong definition of active customer. It may have access to revenue data and still choose the wrong metric, join path, or time logic.

That is an AI data governance problem, not just a model-quality problem. In the American Banker and Strategy study, 75% of respondents said inconsistent metric definitions limit their ability to scale AI.

A governed semantic layer puts business meaning into the execution path. It gives humans, analytics tools, and AI systems a shared business vocabulary rather than letting each interpret enterprise data independently. Metrics, dimensions, relationships, hierarchies, and policy-aware context are defined once and reused across BI tools, applications, and AI systems.

Request → Governed business context → Security policy → Query execution → Result

The model still handles language and reasoning. It does not get to invent the company's definition of revenue.

The same principle applies to security. Enterprises already have row-level security, object permissions, identity rules, and access policies. Connecting an AI agent should not create a second version of that security model.

The interface changed. The authorization did not.
The governance perimeter has to follow the agent.

MCP should narrow the path, not widen it

Model Context Protocol (MCP) makes it easier for AI clients to reach enterprise capabilities. Useful, yes. Governed by default, no.

The engineering questions are straightforward:

• What can the agent discover and query?

• Whose identity and permissions apply?

• Is execution read-only, or can the agent change state?

• What activity and context are logged?

For analytical use cases, the safest pattern is narrow by default: expose approved semantic models, preserve user permissions, certify what the agent can discover, and keep query access read-only unless there is a deliberate reason to allow more.

Putting controls in the execution path is not free. Identity checks, semantic resolution, policy enforcement, and telemetry all consume resources. The goal is not zero overhead; it is bounded overhead in exchange for fewer ungoverned decisions, fewer retries, and evidence you can trust afterward.

Authorization is necessary, but permitted behavior can still be risky. An agent may be authorized to access a sensitive object and still access far more of it than usual, at an unusual time, or through an unexpected workflow.

The useful signal is not simply that a query ran. It is the business context around the query:

Which governed object was accessed? By whom? Through which interface? Was the behavior expected?

That is a more useful unit of observation than a raw database event because the semantic layer knows the business meaning of what was touched.

Agents can generate activity at a scale where humans will never review every query individually. Continuous assurance therefore needs both policy enforcement and behavioral visibility.

Authorization establishes whether access is allowed; behavioral monitoring tells you whether the resulting pattern is expected.

Agentic AI makes identity more complicated.

A log entry that says service account X queried database Y is not enough when an agent is acting for a human across multiple steps.

The evidence chain increasingly needs to look like this:

The human principal establishes accountability. The agent principal identifies the non-human actor. Delegated authority defines what the agent can do on someone's behalf. The governed object identifies the business data involved. The evidence shows what actually happened.

In practice, that authority has to be represented in credentials the receiving service can validate, with scopes and audience matched to the resource being accessed. Delegation should narrow authority, not turn a user request into a blanket machine credential, and authorization should be re-evaluated when the action is executed rather than assumed for the life of a long-running agent session.

This gets harder when agent workflows become asynchronous or span multiple tools and agents. The initiating user's session is not a durable authorization model; enterprises need explicit delegation boundaries and a way to re-evaluate or revoke authority rather than assuming it can be propagated indefinitely.

This does not mean every enterprise needs autonomous agents today. It means the governance model should be ready for delegated machine access before agents become more capable.

Auditability also has to extend beyond access logs. If a metric definition changes, teams may need to know not only what data an agent accessed, but which governed definition was in effect when it accessed it.

For business-critical decisions, the semantic state can be part of the audit record, not just the query and identity.

That is the difference between having logs and having evidence.

Continuous assurance should not end with an audit trail.

Usage tells you which governed models and business objects are actually being consumed. Risk signals show where behavior is drifting. Cost signals reveal where machine-generated activity is creating inefficient or unexpected consumption.

Those signals should feed back into policy, model design, certification, and operating practices.

The useful feedback is not only cost. Repeated metric retries, authorization denials, misunderstood semantic objects, or recurring human escalations can expose where the model, policy, or agent workflow itself needs attention.

Suppose an agent repeatedly issues the same expensive multi-stage query against a governed model. Each request may be authorized, but the pattern still tells you something: the model may need to be redesigned, cached differently, served through a different execution path, or governed with tighter usage controls.

Prevent → Detect → Prove → Improve
That creates a feedback loop instead of leaving governance as a periodic review exercise.

The principles above are product-agnostic. Strategy Mosaic and Mosaic Sentinel provide one reference implementation of this architecture.

^{Mosaic Sentinel Risk Management: Continuous visibility into sensitive-data access and anomalous behavior.}

The point is not that every AI security problem belongs in the semantic layer. It does not.

One product does not replace the security stack.

Mosaic and Sentinel govern a specific layer: the business meaning, policy, and enterprise data path that AI depends on. Organizations still need separate protections for prompt injection, malicious inputs and outputs, application security, model security, endpoint security, and broader AI runtime threats.

That boundary matters. Credible AI governance starts with knowing exactly which layer you control.

Before moving an agent into production, I would ask:

If the answer to those questions is no, the organization may have AI access.

It does not yet have AI governance.

Enterprise AI governance started with policies, model risk, privacy, and approval processes. Those controls still matter.

Agentic AI adds a harder requirement: governance has to operate in the same path, and at the same speed, as the agent.

That means authoritative business context, inherited permissions, execution boundaries, behavioral visibility, and evidence have to travel with each request.

The semantic layer therefore becomes more than the place where companies standardize Revenue for dashboards. It can become the control point where business meaning, access policy, and machine access meet.

Continuous assurance closes that gap by making governance part of execution, not a review after the fact.