AI agents cross the system boundaries that data governance tools stop at. This guide explains what Purview, Collibra, BigID, Unity Catalog, and cloud IAM each cover, where their enforcement ends, and why unified governance for data and AI requests has to live at the infrastructure layer.
By
Billy Allocca
Table of Contents
One Governance Model for Data and AI: Why the Boundary Has to Be One Layer
Unified data and AI governance is a single identity and policy model, enforced at the infrastructure layer, that covers every human user, AI agent, query engine, and storage system in a data estate, so an AI request carries the same identity, the same permissions, and the same audit trail as a human one across every system it touches.
Your governance team approved your data platform. They reviewed the warehouse permissions, signed off on the catalog rollout, and documented retention schedules through three committee cycles. Nobody approved your AI agents, because agents never arrived as a program with a review gate. They arrived as a Copilot license here, a CRM assistant there, and a prototype an application team shipped in a two-week sprint. By spring 2026, two thirds of enterprises in one industry survey had already experienced an AI agent security incident [11], and a separate 2026 analysis found agentic systems involved in roughly one of every eight enterprise breaches [12].
This guide explains why that gap is architectural rather than procedural. It walks through what each major governance tool covers and where its enforcement stops, why an agent crossing from one system to another exits every governance envelope you own, and what it takes to put data access and AI access under one policy model. It builds on our earlier work on AI governance and agent risk in the NexusOne resource library, which covers the control-plane product and the rogue-agent problem in more depth; this piece makes the underlying architectural argument.
How Do Enterprises Enforce Data Access Boundaries for AI Agents Today?
The honest answer is per-tool settings and trust, and the incident record from the past year shows how that ends. An AI agent is a piece of software that uses a language model to plan and execute multi-step tasks, calling tools, querying data systems, and taking actions without a human approving each step. The moment software of that kind holds credentials, it becomes a governance subject, and almost no enterprise treats it like one: Gartner projects that agentic AI will be embedded in 33 percent of enterprise applications by 2028, up from under 1 percent in 2024, and named adapting identity and access management to AI agents its top cybersecurity trend for 2026 [33].
Two disclosures from 2025 made the failure mode concrete. In June 2025, Aim Labs disclosed EchoLeak, a vulnerability in Microsoft 365 Copilot rated CVSS 9.3 on a 10-point scale, in which a single crafted email caused the assistant to read internal files and send their contents to an attacker's server with no user click at any point [2][3]. The payload hid in ordinary-looking email content, invisible to the recipient but parsed by the model, and everything within Copilot's reach was in scope: OneDrive files, SharePoint content, Teams messages [4]. Three months later, Noma Security disclosed ForcedLeak, a CVSS 9.4 chain in Salesforce Agentforce in which instructions embedded in a Web-to-Lead form submission executed when an employee later asked the agent a routine question, exfiltrating CRM records through an expired domain that still sat on Salesforce's content security allowlist [5][6]. Noma reported the chain on July 28, 2025, and Salesforce shipped the fix six weeks later [6][7].
Neither attack broke authentication, and that is the detail worth sitting with. In both cases the agent used permissions it legitimately held, on behalf of a legitimate user, to do something no policy intended. This is indirect prompt injection, an attack where instructions planted in data the agent reads (an email, a form field, a document) hijack what the agent does next. The OWASP GenAI Security Project catalogs the underlying condition as excessive agency: an agent holding tools it does not need, permissions those tools do not need, or autonomy the action does not warrant [8][9]. The standard mitigations, least privilege and scoped credentials per agent, are identity controls, which is why the security industry increasingly files agents under non-human identity, machine identities that need the same lifecycle management as human accounts [10][34].
The surveys say enterprises know all this and cannot yet act on it. Salesforce's 2026 Connectivity Benchmark of 1,050 IT leaders found half of deployed agents operating in silos with no unified governance, and 27 percent of the APIs connecting them carrying no audit trail or access controls at all [13]. One 2026 survey of security professionals found 91 percent of organizations discovering what an agent did only after the action had executed [14], and unsanctioned AI use is now reported by nearly every organization asked [15].
Across the incident write-ups and surveys, agent data exposure keeps reducing to three patterns:
Purpose drift. The agent reads data outside its intended purpose because purpose was never enforced at the data layer, only described in a prompt [1][35].
Credential compromise. The agent's token or API key leaks, and whoever holds it inherits everything the agent could reach [34].
Manipulated authority. Prompt injection turns the agent's legitimate permissions against you, as in EchoLeak and ForcedLeak [1][2][5].
All three are access control failures before they are AI failures, so the natural instinct is to reach for the governance stack you already own. That instinct deserves a careful look.
What Current Governance Tools Cover, and What They Miss When AI Enters the Picture
Each tool in the standard governance stack is good at the job it was designed for, and none of those jobs was governing a request that crosses systems. Data governance, in the operational sense that matters here, has two halves: knowing your data (discovery, classification, cataloging, lineage) and controlling access to it at the moment of the request. The mainstream tools concentrate heavily on the first half, and where they do enforce, they enforce inside a perimeter.
Tool | What it covers well | Where enforcement happens | What it misses when an AI agent crosses systems |
|---|---|---|---|
Microsoft Purview | Discovery, classification, cataloging, and compliance across Microsoft 365 and Azure; catalogs non-Microsoft sources as metadata [16][17] | Data loss prevention (DLP), the automated blocking of sensitive data leaving approved channels, enforced primarily within Microsoft services; catalog roles grant metadata access, never data access [17][18] | No runtime policy on a Trino query, an on-prem Oracle read, or an agent call outside the Microsoft perimeter; third-party platforms are cataloged, not controlled [18] |
Collibra | Business glossary, stewardship workflows, policy lifecycle, design-time lineage; the system of record for what your policies say [19][20] | Policy definitions and approval workflows; enforcement is delegated to integrations in each target system [20] | It never sits in the request path, so an agent's query does not pass through Collibra and cannot be stopped by it |
BigID | ML-driven discovery and classification of sensitive data across cloud, on-prem, and SaaS; data security posture management (DSPM), the continuous mapping of where sensitive data is exposed; privacy operations [21] | Findings drive remediation workflows and feed downstream controls [21] | It knows where the regulated data lives and does not intercept the request that reads it; posture, not enforcement |
Databricks Unity Catalog | Fine-grained permissions, lineage, and audit for data and AI assets inside Databricks, done well [22] | The Databricks runtime | Governance is anchored to the runtime rather than the data, so external engines, dashboards, and agents operating outside the Databricks perimeter fall outside it [23][24] |
Cloud IAM (AWS IAM, Azure RBAC, GCP IAM) | Identities, roles, and resource-level permissions for one cloud's services | The cloud provider's control plane, at the resource level: buckets, prefixes, instances [25] | No native row or column semantics (AWS Lake Formation adds them, for AWS analytics engines only [25][26]); no reach into other clouds or on-prem; no concept of what an AI request intends to do with the data |
Read the table as a fairness exercise and the tools come out fine. Purview is a strong catalog and compliance suite for a Microsoft-centered estate. Collibra gives large organizations a defensible record of policy intent, which auditors value. BigID answers a question almost nothing else answers well, namely where your sensitive data has spread. Unity Catalog gives Databricks customers real fine-grained control inside Databricks. Cloud IAM is the bedrock of cloud security. Each earns its budget line.
Read the table as an architecture review and one property repeats down the right-hand column. Every tool governs inside a boundary: a vendor ecosystem, a metadata plane, a runtime, a single cloud. Governance built for human beings could live with that, because a human analyst who wants data from four systems logs into four systems, and each perimeter checks them on the way in. An agent does not work that way, and the difference is the whole problem.
Why the Boundary Between Data Governance and AI Governance Has to Be One Layer
Follow one useful agent through one ordinary task and count the envelopes it exits. A supply-chain agent at an insurer gets a request to summarize exposure to a struggling supplier. It reads contract data from Databricks, where Unity Catalog checks its service principal. It pulls payment history from an on-prem Oracle instance, authenticating with a stored credential Unity Catalog has never heard of. It cross-references documents in an S3 bucket under an IAM role a third team configured last year. Then it sends a synthesis prompt, carrying fragments of all three, to a hosted language model that no data-governance tool saw at all.
Four hops, four identity models, four partial logs, and three boundary crossings where no policy was evaluated by anything that understood what the agent was carrying. Your Purview catalog documents three of the four systems beautifully, and your Collibra workflows would have required approval for this data combination had a human requested it. Nothing was positioned to ask. The governance gap that breaks enterprise AI sits exactly at those crossings, and every Gen 2 governance tool, by design, stops before it reaches them.
The building-security version of this: an office tower where each floor hired its own guard firm, every firm competent, every floor secure, and the elevator answers to nobody. Agents are the elevator.
You cannot patch this by adding a fifth perimeter, because a perimeter is the wrong shape for the problem. The requests that matter are the ones that cross, so the policy has to live in the thing they cross through: the connective layer between systems. That is a structural claim about where enforcement can physically happen, and it has a corollary worth stating. If the layer that connects your systems is also the layer that enforces identity and policy, then there is no ungoverned path for an agent to take, because the governed path and the path are the same thing. Academic work on agent authorization is converging on the same conclusion, arguing that agent permissions must be bound to identity and enforced outside the agent's own process, where the agent cannot talk its way around them [36].
What Unified Identity and Governance for Both Data and AI Requests Looks Like in Practice
NexusOne was built as that connective layer, and its governance model follows from the position it occupies. NexusOne is a composable data architecture built on open standards (Apache Iceberg, Apache Ranger, Trino, Apache Spark, Kubernetes) that deploys into your own Kubernetes environment, on-prem, in any cloud, or air-gapped, and connects the systems you already run. Because every cross-system request moves through it, it is the one place where a single policy decision can cover data access and AI access together. Five mechanisms do the work.
One identity, federated from what you have. NexusOne aggregates identity from Active Directory, Okta, LDAP, SAML, and OAuth providers through Keycloak into a single model with users, groups, and roles. That identity flows to every engine, catalog, notebook, orchestrator, and API in the estate, and to federated targets beyond it, so a person or agent authenticated once does not need separate accounts in Teradata, Databricks, or S3. As the engineering team puts it, you only have to exist once.
One policy, every enforcement point. A policy defined once in Apache Ranger applies simultaneously to Trino, Spark, the serving layer built on Apache Kyuubi, and S3 object storage on a per-object basis across providers. Role-based access control (RBAC), the model that grants permissions to roles rather than individuals, stops being something you configure five times and reconcile forever, because the same rule fires whether the access comes through a SQL query, a Spark job, a notebook, or an agent calling an API.
Policies that maintain themselves. Through tag-based policy generation, you tag a dataset in DataHub, map roles to tags once, and access policies generate automatically at the bucket, schema, and table level, then regenerate when the schema evolves. Governance teams drowning in thousands of hand-maintained policies tend to find this the most immediately practical piece, because the catalog, the policy engine, and the compute engines stay in sync without a human replaying changes across them.
Agents governed as first-class identities. An agent in the NexusOne estate inherits the RBAC permissions of the user who invoked it, enforced by the same policy engine at every hop, so it can never exceed its invoking user's rights on any system it touches. Agents also carry their own scoped identity for system tasks, which means you can bound what a given agent may do independently of who launched it. This is the control the OWASP excessive-agency guidance asks for [8][10], applied estate-wide rather than per tool. The founding team's shorthand for why this matters is blunt: without scoped identity, governed data, and predefined pathways, agents are toddlers with knives.
Policy checks before the model, and before the data. The NexusOne AI & Data Control Plane extends the same envelope to model traffic. Every AI request is authenticated and policy-checked at the boundary, before it reaches a model or a data system, and requests showing jailbreak patterns or carrying sensitive data toward an egress point are blocked there, with the block and its reason logged. Early deployments are underway, including at a top-ten US bank, and you can read how the product works on the AI & Data Control Plane page.
One honest limit belongs in a sentence here: the envelope governs what is connected to it, so a SaaS agent operating entirely outside your estate stays outside until you connect it, and NexusOne governs model inputs and outputs at the boundary rather than inspecting a model's internal weights.
How Do You Get Full Lineage and Governance Over AI Queries Across a Hybrid Data Estate?
Lineage for AI means being able to answer one compound question for any request, months later: which model ran, on behalf of which user or agent, touching which data, under which policy, at what time, with what result. Data lineage traditionally traces how data moved between systems; AI-query lineage extends the same discipline to inference. Fragmented estates cannot produce this record because no single log contains it, and reconstructing it across four systems' audit formats is exactly the correlation work that fails during a real investigation.
When every request already flows through one identity and policy layer, that record is a byproduct rather than a project. Each AI request in a NexusOne estate lands in the audit trail with its invoking identity, the model or engine that served it, the data products it touched, the policy scope it was evaluated under, and the outcome, including blocks. The same trail covers the rest of the AI lifecycle, from ingestion through serving to agent actions, because the same layer carries all of it.
Regulators have stopped treating this as optional. The table below maps the four regimes that come up most in our conversations with governance teams at banks, insurers, and healthcare systems.
Regime | What it demands of AI activity records | What a single envelope produces |
|---|---|---|
EU AI Act, Article 12 | High-risk AI systems must automatically record events over their lifetime, with logs sufficient to trace operation; in full application for high-risk systems as of August 2, 2026 [27][28][29] | Automatic per-request logs with identity, policy, and outcome, generated by the system itself rather than assembled manually |
SOC 2 | 2026 audits increasingly ask for model lineage, inference logs, and evidence that AI actions tie to authenticated users [31][32] | One trail connecting each AI action to a person or scoped agent identity |
HIPAA | Access limited to the minimum necessary, with audit records showing retrieval scope was technically bounded, retained six years [30][31] | Policy evaluated per request at the data layer, so the bound is demonstrable, not aspirational |
FedRAMP and financial regulators | Continuous monitoring and full attribution of system activity, producible on examiner demand [30] | The audit log doubles as the evidence record, exportable per system, per user, or per agent |
NexusOne runs its own operations against the same standards it sells, with SOC 2 Type II and HITRUST certification, annual third-party penetration testing, and a public trust center. The pattern holds up under regulator pressure at customer scale too: one financial-services customer clears 166 audits a year on the platform, and another clears more than 500, because pulling the evidence for any one of them is a query rather than a quarter's work.
How Do You Prevent AI Agents From Accessing Data They Should Not Reach in a Multi-Cloud Environment?
Prevention has to be structural, because detection after the fact is what 91 percent of organizations report doing today [14]. The four available architectures differ on where they can stop an agent, and the differences compound in a multi-cloud estate where the agent's task spans providers by default.
Dimension | Per-platform controls (Unity Catalog, warehouse RBAC, cloud IAM) | Governance overlay (Purview, Collibra, BigID) | AI gateway or proxy | Infrastructure-layer envelope (NexusOne) |
|---|---|---|---|---|
Identity for agents | Each platform's own model, configured separately | Reads identities from source systems; holds none at runtime | API keys at the proxy | One federated identity model covering humans and agents everywhere |
Enforcement point | Inside each platform | Policy documents and workflows; enforcement delegated | The prompt boundary | Every engine, storage interface, catalog, API, and model boundary |
Cross-system reach | Ends at the platform edge | Metadata reach, no request-path presence | Sees prompts, never data systems | Enforcement lives in the layer the request crosses through |
Lineage of an AI request | Fragments, one per system | Design-time lineage only | Model-call logs without data context | One record: model, identity, data, policy, result |
Bypass risk | Structural, since agent tasks span platforms | Structural, since the overlay never sees the request | High, since nothing forces traffic through a proxy | Low, since the governed path is the connective path |
Whichever architecture you run today, you can test it against the boundary problem with eight questions:
Does a human analyst and the agent acting on their behalf carry the same identity, on every system both can touch?
Can you define a row-level or column-level policy once and see it enforced on every engine and storage interface, including object storage?
Is an agent technically unable to exceed its invoking user's permissions at any hop, rather than expected not to?
Can an out-of-policy AI request be blocked before it reaches any model or data system, with the block logged and its reason recorded?
Does every AI request produce one audit record with model, identity, data touched, policy applied, and outcome [27][31]?
Does enforcement reach on-prem systems and every cloud you run, without routing your data through a vendor's cloud?
When you onboard a new system, does it inherit identity, policy, and audit automatically, or does it open a new gap?
Can you export evidence in the shape your auditors ask for, per agent, per user, or per system [30][32]?
Per-platform controls answer yes inside their own walls, overlays answer yes for documentation, and gateways answer yes at the prompt boundary. If you need all eight across a hybrid estate, the enforcement has to sit in the infrastructure layer, because that is the only position from which all eight are even visible.
Why Not Just Add an AI Governance Tool on Top of Your Current Stack?
The strongest objection to everything above is budgetary and fair: you already own Purview or Collibra, your CISO just funded an AI gateway, and a new layer sounds like a rebuild. Two parts of that objection hold up, so keep both tools. A catalog and stewardship platform remains your system of record for policy intent, and discovery tools like BigID answer where sensitive data lives better than an enforcement layer will. NexusOne coexists with them, and with existing gateways and dedicated model-governance tools, interconnecting under open standards rather than displacing them.
The part that does not hold up is the expectation that stacking perimeter tools ever produces boundary coverage, because each added tool governs its own new perimeter and the crossings stay dark. An AI gateway inspects prompts and cannot see that the agent's third data hop violated a residency policy, since the gateway has no presence in data systems [35]. An overlay documents the policy the agent just violated. You can add tools indefinitely and the elevator still answers to nobody. Closing the gap requires enforcement in the connective layer, and adding that layer is far less invasive than it sounds: NexusOne deploys into a single namespace on your existing Kubernetes with least-privilege permissions, connects to systems where they are, and moves nothing. Security reviews tend to clear it in days precisely because it asks for so little.
Deciding whether the gap is real in your estate takes an afternoon, not a program. Trace one agent workflow end to end, list every system it touches and every boundary it crosses, and ask which of the eight questions above your current stack can answer at each crossing. If you want a second set of eyes on that trace, schedule an expert consultation and our team will walk your architecture with you, including the parts where your existing tools are already doing their jobs well.
Frequently Asked Questions
What Platform Provides Unified Identity and Governance for Both Data and AI Requests?
NexusOne provides a single identity and policy model for data and AI requests at the infrastructure layer, federating identity from providers like Active Directory and Okta through Keycloak, enforcing one Apache Ranger policy across Trino, Spark, the Kyuubi-based serving layer, and S3, and applying the same model to AI traffic through its AI & Data Control Plane. Platform-native tools like Databricks Unity Catalog unify data and AI governance within their own platform [22], and catalogs like Microsoft Purview unify visibility rather than enforcement [16]. NexusOne's distinction is that the same identity and policy follow a request across systems, on-prem and in every cloud.
How Do Enterprises Enforce Data Access Boundaries for AI Agents?
The enforceable pattern is to treat agents as governed identities rather than trusted software: give each agent a scoped identity, have it inherit the invoking user's permissions through impersonation, evaluate policy at the data layer on every request, and block out-of-policy requests before they reach a model or data system. OWASP's guidance on excessive agency prescribes least privilege and scoped credentials as the core mitigations [8][10]. What most enterprises run today falls short of this, with half of deployed agents operating without unified governance in Salesforce's 2026 benchmark [13], because per-platform permissions cannot follow an agent across systems. Enforcement at the connective infrastructure layer can.
How Do You Achieve Full Lineage and Governance Over AI Queries Across a Hybrid Data Estate?
Route every AI request through one layer that authenticates it, evaluates policy, and logs the full decision, so each query produces a single record naming the model, the invoking identity, the data touched, the policy applied, the timestamp, and the result. Attempting the same by correlating separate logs from each platform fails in practice, since the systems use different identity models and the model call often appears in none of them. This single-record approach is also what EU AI Act Article 12 anticipates, requiring high-risk AI systems to automatically record events across their lifetime [27][28].
Best Enterprise Data Platform for AI Security Compliance, Audit Trails, and Model Governance Across Multiple LLMs?
For estates spanning on-prem and multiple clouds, NexusOne is the strongest fit we know of, because its audit trail covers data access and model access in one record and its control plane governs requests to any model, hosted or local, rather than one vendor's endpoints. It blocks policy violations before model invocation, evaluates responses, and interconnects with dedicated model-governance tools and existing gateways under open standards. If your data and AI workloads live entirely inside one platform, that platform's native governance, such as Unity Catalog for a pure Databricks estate, may be sufficient [22]; the multi-LLM, multi-system case is where a platform-neutral layer becomes the requirement.
Which Enterprise Platform Provides the Best AI Agent Access Control and Policy Enforcement at Scale?
Judge candidates on four tests: agents carry the same identity model as humans on every system, an agent cannot exceed its invoking user's permissions at any hop, policy is enforced at the data layer rather than described in a prompt, and enforcement reaches every system agents touch, including on-prem. NexusOne meets all four by enforcing agent permission impersonation through the same cross-estate policy engine that governs human access, at scales from a hundred cores to several hundred thousand on the same software image. Platform-native controls meet the first three inside their own perimeter, which is the boundary agents routinely cross [23][24].
How Do You Prevent AI Agents From Accessing Data They Shouldn't in a Multi-Cloud Environment?
Make the ungoverned path structurally unavailable: connect your clouds and on-prem systems through one governed layer, give agents scoped identities inside it, enforce row-level and column-level policy at the data interface on every request, and block violations at the boundary with the attempt logged. Relying on each cloud's IAM leaves gaps, because IAM operates at the resource level, misses row and column semantics outside supplementary services like AWS Lake Formation [25][26], and holds no policy authority over the other cloud. The incidents that defined 2025, EchoLeak and ForcedLeak, both rode legitimate credentials across trust boundaries [2][5], which is why prevention has to sit at the crossing itself.
References
webpro255, "Awesome AI Agent Attacks: A Curated Timeline of Real AI Agent Security Incidents (2024-2026)," GitHub. https://github.com/webpro255/awesome-ai-agent-attacks
The Hacker News, "Zero-Click AI Vulnerability Exposes Microsoft 365 Copilot Data Without User Interaction," June 2025. https://thehackernews.com/2025/06/zero-click-ai-vulnerability-exposes.html
SOC Prime, "CVE-2025-32711 Vulnerability: 'EchoLeak' Flaw in Microsoft 365 Copilot Could Enable a Zero-Click Attack on an AI Agent." https://socprime.com/blog/cve-2025-32711-zero-click-ai-vulnerability/
Sentra, "EchoLeak (CVE-2025-32711): What the Microsoft Copilot Prompt Injection Vulnerability Means for Your Data." https://sentra.io/blog/copilot-echoleak-prompt-injection
Noma Security, "ForcedLeak: AI Agent Risks Exposed in Salesforce Agentforce." https://noma.security/blog/forcedleak-agent-risks-exposed-in-salesforce-agentforce/
The Hacker News, "Salesforce Patches Critical ForcedLeak Bug Exposing CRM Data via AI Prompt Injection," September 2025. https://thehackernews.com/2025/09/salesforce-patches-critical-forcedleak.html
Varonis, "ForcedLeak and the Future of AI Agent Security." https://www.varonis.com/blog/forcedleak
OWASP GenAI Security Project, "LLM08: Excessive Agency." https://genai.owasp.org/llmrisk2023-24/llm08-excessive-agency/
Aembit, "OWASP Top 10 for LLM Applications (2025): Risks Explained." https://aembit.io/blog/owasp-top-10-llm-risks-explained/
Auth0, "Mitigate Excessive Agency in AI Agents with Zero Trust Security." https://auth0.com/blog/mitigate-excessive-agency-ai-agents/
Kiteworks, "AI Agent Security Incidents Hit 65% of Firms in 2026." https://www.kiteworks.com/cybersecurity-risk-management/ai-agent-security-incidents-2026/
Digital Applied, "AI Agent Security: 1 in 8 Breaches From Agentic Systems." https://www.digitalapplied.com/blog/ai-agent-security-2026-1-in-8-breaches-agentic-systems
iEnable, "AI Agent Sprawl: 50% of Enterprise Agents Run Ungoverned." https://ienable.ai/blog/agent-sprawl-enterprise-ai-governance-crisis.html
Associates AI, "91% of Companies Don't Know What Their AI Agents Did Until It's Already Done." https://associatesai.team/blog/shadow-ai-agents-the-governance-crisis-hiding-in-your-business
Vectra AI, "Shadow AI Explained: Risks, Costs, and Enterprise Governance." https://www.vectra.ai/topics/shadow-ai
Microsoft Learn, "Learn About Data Governance with Microsoft Purview." https://learn.microsoft.com/en-us/purview/data-governance-overview
The Data Governor, "What Is Microsoft Purview? A Practitioner's Guide." https://thedatagovernor.com/what-is-microsoft-purview/
EPC Group, "Microsoft Purview: Enterprise Data Governance and Compliance Guide." https://epcgroup.net/blog/microsoft-purview-data-governance-guide
ER/Studio, "Collibra Data Governance: Features, Reviews, and Use Cases." https://erstudio.com/blog/collibra-data-governance/
Atlan, "13 Best Data Governance Software in 2026, Compared." https://atlan.com/data-governance-software/
Kiteworks, "Top 9 AI-Powered Data Governance Tools for 2026." https://www.kiteworks.com/cybersecurity-risk-management/ai-data-governance-tools-2026/
Databricks Documentation, "What Is Unity Catalog?" https://docs.databricks.com/aws/en/data-governance/unity-catalog/
Atlan, "5 Unity Catalog Limitations to Overcome in 2026." https://atlan.com/know/databricks-unity-catalog-limitations/
TrustLogix, "Databricks Unity Catalog Security: Closing the Access Control Gaps." https://www.trustlogix.ai/blog/beyond-databricks-runtime-enterprise-data-access-control-governance-trustlogix-unity-catalog
AWS Big Data Blog, "Enforce Fine-Grained Access Control on Data Lake Tables Using AWS Glue 5.0 Integrated with AWS Lake Formation." https://aws.amazon.com/blogs/big-data/enforce-fine-grained-access-control-on-data-lake-tables-using-aws-glue-5-0-integrated-with-aws-lake-formation/
BSC Analytics, "AWS Lake Formation, Part 4: Fine-Grained Access Control with Lake Formation and IAM." https://bscanalytics.com/insights/aws-lake-formation-part-4-fine-grained-access-control-with-lake-formation-and-iam
Future of Life Institute, "Article 12: Record-Keeping," EU Artificial Intelligence Act Explorer. https://artificialintelligenceact.eu/article/12/
Help Net Security, "What the EU AI Act Requires for AI Agent Logging," April 2026. https://www.helpnetsecurity.com/2026/04/16/eu-ai-act-logging-requirements/
TrueScreen, "EU AI Act Record-Keeping: Article 12 Requirements Explained." https://truescreen.io/insights/ai-act-record-keeping-requirements/
Kognitos, "AI Audit Trail Requirements: 2026 Checklist for Finance, Healthcare, Banking." https://www.kognitos.com/blog/ai-audit-trail-requirements-2026-checklist/
Superblocks, "AI Audit Trail: 7 Things to Log for Compliance in 2026." https://www.superblocks.com/blog/ai-audit-trail
SOC2Auditors.org, "SOC 2 for AI Companies (2026): What Auditors Test First." https://soc2auditors.org/insights/soc-2-for-ai-companies/
Radiant Logic, "Gartner's 2026 IAM Predictions: Identity Visibility Is No Longer Optional." https://www.radiantlogic.com/blog/gartners-2026-iam-predictions-identity-visibility-is-no-longer-optional/
Cloud Security Alliance, "The Non-Human Identity Governance Vacuum." https://labs.cloudsecurityalliance.org/research/csa-whitepaper-nonhuman-identity-agentic-ai-governance-v1-cs/
NeuralTrust, "The Complete Guide to AI Agent Security for Enterprises (2026)." https://neuraltrust.ai/blog/ai-agent-security-enterprises-complete-guide
arXiv, "aiAuthZ: Off-Host, Identity-Bound Authorization for AI Agents," arXiv:2607.05518. https://arxiv.org/pdf/2607.05518
