/

Data Governance

Data Governance for AI Agents: Policies, Lineage, and Semantic Enforcement

Intergalactic Data Labs

โ€”

โ€”

14 min read

Table of contents

Summarize

Updated October 2026

Data governance for AI agents is the set of controls over what an agent can read, which tools it calls, what data means, and how each step is logged. It works only when rules are enforced outside the model, in the identity provider, the MCP server, the warehouse, the semantic layer, and the retrieval index. Prompt instructions alone do not count as governance.

Layer

What it governs

Where it is enforced

Example control

Identity

Who the agent acts for

Identity provider

Per agent identity, delegated user tokens

Tools

What the agent can do

MCP server or gateway

Scoped OAuth tokens, tool allowlists

Data plane

Which rows and columns it sees

Warehouse or lakehouse

Row access policies, column masks

Meaning

How data is interpreted

Semantic layer or ontology

Versioned metric definitions

Context

What enters the prompt

Retrieval index

Permission filter at retrieval time

Evidence

What happened and why

Logs and lineage

Trace IDs across every layer

This guide covers each layer with policy templates and an audit checklist. For how agents receive context in the first place, read our enterprise context management architecture.

What is data governance for AI agents?

Data governance for AI agents extends classic data governance from people reading data to software acting on it. A dashboard reads data and renders a chart. An agent reads data, reasons over it, calls tools, and can write to other systems in one turn. Each of those steps needs its own control and its own record.

Classic governance covers ownership, access, quality, and lineage. Agent governance keeps all four and adds agent identity, tool authorization, retrieval rules, semantic consistency, and approval gates. Our comparison of data catalog vs data governance vs data lineage explains the classic pieces this builds on.

Why do prompt rules fail as agent governance?

Prompt rules fail because they ask the model to police itself, and the model can be talked out of them. OWASP ranks prompt injection as the top LLM risk, including indirect injection hidden in files and web pages. An agent that reads untrusted content can receive new instructions from it.

OWASP's guidance on excessive agency names three root causes. They are excessive functionality, excessive permissions, and excessive autonomy. Its main fix is complete mediation, which means authorization is enforced in downstream systems rather than in the LLM. The 2026 edition, announced by the OWASP GenAI Security Project in September 2026, moved excessive agency up to third place.

Agents raise the stakes further. OWASP released a separate Top 10 for Agentic Applications in December 2025. It names risks such as tool misuse and identity and privilege abuse, which do not exist for a chatbot without tools.

Which frameworks should agent governance map to?

Map controls to the NIST AI Risk Management Framework, then use OWASP for threat detail. The NIST AI RMF was released in January 2023 with four functions named Govern, Map, Measure, and Manage. NIST added a Generative AI Profile, NIST AI 600-1, in July 2024, and says the framework is now being revised.

NIST function

Agent governance focus

Example controls

Govern

Ownership and policy

Named owner per agent, policy as code, change review

Map

Risk inventory

List of data sources, tools, and sensitive joins per agent

Measure

Testing and monitoring

Injection tests, denied access rates, metric consistency checks

Manage

Response and fixes

Token revocation, alerting, rollback of agent configs

Identity standards for agents are still forming. In February 2026 the NIST NCCoE published a concept paper on software and AI agent identity and authorization. It asked for input on identification, authorization, auditing, and non repudiation of agents.

Regulation is moving too. Under the EU AI Act Omnibus, published July 24, 2026, most Annex III high risk obligations now apply from December 2, 2027, according to the Future of Privacy Forum.

How should AI agents get identity and permissions?

Every agent action should trace back to a named identity, never a shared key. Use two patterns. A service identity covers background agents that act for the company. Delegated access covers agents acting for a user, so the agent sees only what that user could see.

Delegated access is the safer default for assistants and copilots. OWASP recommends executing extensions in the user's context with minimal scope. A shared service account with broad rights does the opposite, because one injected prompt can reach everything that account can reach.

Separate read and write duties as well. An agent that reads customer records and also sends external email should hold those rights under different scopes. If the write credential leaks, the attacker should not gain read access to sensitive data.

How do you enforce agent policy at the MCP layer?

Enforce it with scoped OAuth tokens on every MCP server, plus a tool allowlist for each agent role. The MCP authorization specification bases HTTP authorization on OAuth 2.1. Clients must name the target server with a resource indicator, and servers must reject tokens issued for other audiences.

The spec also bans token passthrough. Its security best practices explain that forwarding a client token downstream breaks audit trails and lets a stolen token reach other services. The same page recommends a small starting scope set, with step up challenges when an agent first attempts a privileged operation.

The tools specification adds three useful rules. A server may return only the tools a caller's scopes permit. Clients must treat tool annotations as untrusted unless the server is trusted. Clients should log tool usage for audit and confirm sensitive operations with the user.

Managed MCP servers from data platforms already follow this pattern. Snowflake's managed MCP server requires a grant for each tool, recommends OAuth, and checks privileges on the underlying objects. Databricks says its managed MCP servers, still in Public Preview, rely on Unity Catalog to enforce permissions for agents and users.

Tool policy template

A tool policy should list the allowed tools, their parameter limits, and the token scopes for one agent role.

policy: agent-tool-use
agent_role: sales_analyst_agent
identity: delegated_user
mcp_servers:
  - server: https://mcp.warehouse.example.com
    scopes: [semantic:query]
    tools:
      - name: query_metric
        allowed_metrics: [pipeline_value, win_rate, quota_attainment]
        max_rows: 10000
  - server: https://mcp.crm.example.com
    scopes: [crm:read]
    tools:
      - name: get_account
denied_tools: [run_raw_sql, export_table, send_external_email]
network_egress: denied
policy: agent-tool-use
agent_role: sales_analyst_agent
identity: delegated_user
mcp_servers:
  - server: https://mcp.warehouse.example.com
    scopes: [semantic:query]
    tools:
      - name: query_metric
        allowed_metrics: [pipeline_value, win_rate, quota_attainment]
        max_rows: 10000
  - server: https://mcp.crm.example.com
    scopes: [crm:read]
    tools:
      - name: get_account
denied_tools: [run_raw_sql, export_table, send_external_email]
network_egress: denied
policy: agent-tool-use
agent_role: sales_analyst_agent
identity: delegated_user
mcp_servers:
  - server: https://mcp.warehouse.example.com
    scopes: [semantic:query]
    tools:
      - name: query_metric
        allowed_metrics: [pipeline_value, win_rate, quota_attainment]
        max_rows: 10000
  - server: https://mcp.crm.example.com
    scopes: [crm:read]
    tools:
      - name: get_account
denied_tools: [run_raw_sql, export_table, send_external_email]
network_egress: denied

This role reads governed metrics and CRM accounts only. It cannot run raw SQL or send email, and any new tool needs a policy change.

Where should row and column security for agents live?

Row and column security should live in the warehouse or lakehouse, where the model cannot override it. When the agent queries with the user's identity or a scoped role, the platform applies the same rules it applies to a human analyst.

Snowflake row access policies are evaluated at query time and return only rows where the policy is true. They run under the policy owner's role and can use mapping tables for complex rules. One documented limit is that they do not block inserts, so pair them with write privileges that agents do not hold.

Databricks offers attribute based access control in Unity Catalog. Row filter and column mask policies match governed tags, so one policy covers every table carrying a tag such as PII. That scales better than writing a policy per table as agents reach more data.

How does semantic enforcement keep agents consistent?

Semantic enforcement makes every agent use the same definition of a business concept. Access control answers whether an agent can see the data. It does not stop two agents from computing revenue with different filters, date ranges, or currency rules on the same tables.

A governed semantic layer or ontology fixes that by storing one versioned definition per metric and entity. An April 2026 study found explicit business semantics added 17 to 23 points of accuracy across three frontier models. A dbt benchmark reported 98 to 100 percent accuracy through its semantic layer on 11 questions, though it is a vendor test.

Expose those definitions to agents as MCP tools, such as a query metric tool, rather than letting agents write free SQL. Our guide to how ontologies make AI smarter and more trustworthy covers ontology based constraints in more depth.

These definitions are institutional knowledge, so they should live in open formats on infrastructure the company controls. Galaxy is an applied lab that builds this semantic foundation with teams on the stack they already run. It builds in the open with Filament and plans to open source more of its tooling.

How do you govern RAG and GraphRAG context?

Govern retrieval by checking the user's permissions on every chunk or graph node before it enters the prompt. A vector index ranks by similarity, not sensitivity. Without a permission filter, a routine sales question can pull a confidential board memo into context.

Graphs add a second risk. Even when each node is protected, a traversal can reveal that two entities are related through a shared supplier or person. Apply access rules to edges as well as nodes, and limit traversal depth for each agent role.

Treat retrieved content as untrusted input. OWASP recommends keeping external content separate from user prompts and clearly labeled. Record the source of every retrieved item so a wrong answer can be traced to the document or record behind it.

What lineage and audit trail does an AI agent need?

An agent needs a trace that rebuilds one answer from request to source data. That trace spans three layers, the model provider, the agent runtime, and the data platform. A shared trace ID links them so investigators can follow one request across all three.

Layer

What to log

Example source

Model provider

Keys, projects, org changes

Provider admin audit logs

Agent runtime

Prompts, tool calls, retrieved items, approvals

MCP client and gateway logs

Data platform

Queries, policy decisions, denied access

Warehouse query and access history

Lineage

Which datasets fed which outputs

OpenLineage events, catalog lineage

OpenLineage is an open standard for this, built on datasets, jobs, and runs with extensible facets. It is a graduate project of the LF AI and Data Foundation. Platform lineage helps too. Unity Catalog lineage is captured automatically for Databricks queries, and its lineage system tables keep a rolling one year window.

For runtime tracing, OpenTelemetry maintains GenAI semantic conventions covering GenAI clients and MCP. Using them keeps agent traces portable across observability tools. Our article on provenance, lineage, and auditability goes deeper on provenance models.

Minimum audit checklist
  • Every log record carries the user, the agent identity, and one trace ID.

  • Tool calls are logged with arguments and results, redacting sensitive values.

  • Retrieved chunks and graph nodes are logged with their source IDs.

  • Policy decisions, including denials, are logged by the data platform.

  • Logs are immutable and kept for the period your compliance rules require.

Which agent actions should require human approval?

Require approval for any action that is hard to undo or leaves the company. That includes writes to systems of record, external messages, payments, large exports, and permission changes. The MCP tools specification says a human should be able to deny tool invocations.

policy: agent-approval-gates
agent_role: sales_analyst_agent
require_approval:
  - action: write_to_crm
    approver_role: sales_ops_manager
  - action: export_rows
    condition: row_count > 500 or sensitivity in [confidential, restricted]
    approver_role: data_steward
  - action: send_external_email
    approver_role: agent_owner
on_timeout: deny
notify: [agent_owner, security_team]
policy: agent-approval-gates
agent_role: sales_analyst_agent
require_approval:
  - action: write_to_crm
    approver_role: sales_ops_manager
  - action: export_rows
    condition: row_count > 500 or sensitivity in [confidential, restricted]
    approver_role: data_steward
  - action: send_external_email
    approver_role: agent_owner
on_timeout: deny
notify: [agent_owner, security_team]
policy: agent-approval-gates
agent_role: sales_analyst_agent
require_approval:
  - action: write_to_crm
    approver_role: sales_ops_manager
  - action: export_rows
    condition: row_count > 500 or sensitivity in [confidential, restricted]
    approver_role: data_steward
  - action: send_external_email
    approver_role: agent_owner
on_timeout: deny
notify: [agent_owner, security_team]

Denial on timeout matters. An approval gate that passes when nobody answers is not a gate. Log the approver and the decision with the same trace ID as the action.

How do you test agent governance before production?

Test governance by attacking it before users do. Run each scenario against the real identity, tools, and data policies the agent will use in production. Repeat the suite whenever a tool, policy, or model changes.

  • Injection resistance. Plant instructions in a document and check that the agent cannot call denied tools.

  • Over broad retrieval. Ask for content outside the user's scope and confirm the retrieval filter blocks it.

  • Unsafe tool arguments. Send destructive or exfiltration style parameters and confirm the server rejects them.

  • Semantic consistency. Ask the same metric question five ways and confirm one definition and one number.

  • Gate bypass. Try to trigger a write or export without approval and confirm the gate fires.

After launch, alert on repeated denied access from one agent, new data sources appearing in retrieval logs, and metric values that drift from the semantic layer baseline.

What are the most common agent governance failures?

The most common failure is relying on prompt rules instead of enforced controls. Gartner predicts over 40 percent of agentic AI projects will be canceled by the end of 2027, citing costs, unclear value, and inadequate risk controls. Four patterns account for most governance gaps.

Prompt only guardrails. Access rules written into a system prompt can be overridden by injection. Move every rule to the warehouse, the MCP server, or the retrieval filter.

Shared service accounts. One account for every agent removes attribution and makes revocation all or nothing. Give each agent its own identity and use delegated user tokens where possible.

Ungoverned retrieval corpora. Teams often load documents into a vector store without sensitivity labels or permissions. A retrieval index is a data source and needs the same classification and access rules as a table.

Metric drift across agents. Two agents with different churn logic erode trust in both. Centralize definitions in a semantic layer, as covered in RAG vs knowledge graph vs semantic layer.

Frequently asked questions

What is data governance for AI agents?

It is the set of controls that decide what data an agent can read, which tools it can call, what the data means, and how every step is recorded. It extends classic data governance with agent identity, tool authorization, retrieval rules, and approval gates. The goal is that an agent never sees or does more than the person it serves could.

Is a system prompt enough to govern an AI agent?

No. A system prompt is an instruction to the model, and prompt injection can override it. OWASP lists prompt injection as the top LLM risk and recommends enforcing authorization in downstream systems instead of the model. Put access rules in the warehouse, the MCP server, and the retrieval layer, where the model cannot change them.

How does MCP handle authorization for agents?

For HTTP servers, the MCP specification bases authorization on OAuth 2.1. Clients must name the target server with a resource indicator, and servers must reject tokens issued for anyone else. Servers may also return only the tools a caller's scopes permit. That lets each agent connection carry scoped, user level access instead of one shared key.

What is token passthrough and why is it banned in MCP?

Token passthrough is when an MCP server accepts a token meant for another service and forwards it downstream unchanged. The MCP specification forbids it because it bypasses audience checks, breaks audit trails, and lets a stolen token reach many systems. Each server should only accept tokens issued for itself and get its own tokens for downstream calls.

Where should row level security for agents be enforced?

Enforce it in the data platform that stores the data. Snowflake row access policies, for example, are evaluated at query time and return only rows where the policy is true. When the agent queries with the user's identity or a scoped service role, the same rules apply as for a human analyst, regardless of what the prompt says.

Why do AI agents need a semantic layer for governance?

Access control decides what an agent may see, but not what the data means. Without shared definitions, two agents can compute revenue or churn differently from the same tables. A governed semantic layer or ontology gives every agent one versioned definition. Research in April 2026 found explicit business semantics raised model accuracy by 17 to 23 points.

What should an agent audit trail include?

Log the requesting user, the agent identity, the prompt or a redacted version, each tool call with its arguments, the retrieved context, the queries run, and which policies allowed or denied access. Link every record with one trace ID across the model, runtime, and data layers so a single answer can be rebuilt during a review or incident.

Which frameworks apply to AI agent governance?

Most teams map controls to the NIST AI Risk Management Framework and its Generative AI Profile, NIST AI 600-1. OWASP publishes a Top 10 for LLM applications and a Top 10 for agentic applications. In the EU, the AI Omnibus moved most Annex III high risk obligations to December 2, 2027, which gives teams time to build logging.

Which agent actions should require human approval?

Require approval for actions that write to systems of record, send messages outside the company, move money, export large or sensitive datasets, or change permissions. The MCP tools specification says a human should be able to deny tool invocations. Set a timeout that denies by default, and log who approved what so the decision is auditable.

Where should a team start with agent data governance?

Start with identity and data plane enforcement. Give each agent its own identity, pass the user's identity on delegated calls, and apply row and column rules in the warehouse. Then add scoped MCP authorization, shared semantic definitions, retrieval filtering, and trace logging. Gartner predicts over 40 percent of agentic AI projects will be canceled by 2027, partly over weak risk controls.

More articles

Stay up to date with what weโ€™re building

Stay up to date with what weโ€™re building

Stay up to date with what weโ€™re building

Questions

Answered

FAQ

What does Galaxy do?

What is Filament?

What is enterprise context management?

What does working with Galaxy look like?

How do you handle security and compliance?

Why does Galaxy build in the open?

Own your knowledge stack

Own your knowledge stack

Copyright ยฉ 2026 Galaxy. All rights reserved.