← Back to Blogs
August 17, 2026By Cosmoneural Insights

Permissions Are the New Data Quality: Governing the Retrieval Path Before You Scale AI

Data GovernanceAI ArchitectureEnterprise Security
Permissions Are the New Data Quality: Governing the Retrieval Path Before You Scale AI

Photo by Shubham Dhage on Unsplash

Ask a room of enterprise architects what blocks AI delivery and you will hear the same answer: data quality. It is a comfortable answer, because it justifies another eighteen-month cleanup programme. But in the projects we see stall at the pilot-to-production boundary, the blocking issue is rarely a null column. It is that nobody can state, with evidence, which data the AI system is entitled to see, on whose behalf, and why. Gartner's widely cited prediction that organisations will abandon 60% of AI projects unsupported by AI-ready data is usually read as a quality warning. Read it again as a governance warning and it lands closer to the truth.

The failure mode nobody budgets for

A retrieval-augmented assistant does not inherit your org chart. It inherits whatever the indexing job could reach. Every enterprise has a decade of SharePoint sites, shared drives, ticket exports and legacy schemas with permissions that were "temporary" in 2017. Human users never stumbled across most of it because search was bad. AI makes search good — and that is precisely the problem. Microsoft's own guidance on mitigating oversharing before scaling Copilot and agents is, in effect, an admission that the control gap is real and structural, not a configuration afterthought.

The second-order version is worse. Agentic systems act under service identities that aggregate permissions across systems. A Cloud Security Alliance survey reported by security analysts found most organisations cannot reliably distinguish AI agent activity from human activity in their logs. If you cannot attribute an action, you cannot govern it, and you certainly cannot explain it to an auditor.

What an entitlement-aware data foundation actually looks like

The fix is architectural, not procedural. Governance has to move from a documentation exercise sitting beside the platform to a runtime property of the retrieval path itself.

  • Identity per agent, not per application. Every copilot, agent and automation gets its own non-human identity with a named business owner, a declared purpose and a risk tier — never a shared technical account.
  • Permission propagation at query time. Retrieval filters on the requesting user's entitlements, evaluated at the moment of the call. Pre-filtered indexes and "trusted" service accounts are how confidential data leaks into a summary.
  • Sensitivity labels that travel. Classification must survive extraction, chunking and embedding. An unlabelled vector is an ungoverned vector.
  • Scope before scale. Onboard a defined, remediated corpus for each use case rather than pointing the indexer at the tenant and hoping. Narrow, clean scope also improves answer quality — a rare case where control and performance align.
  • Evidence by default. Log which sources were retrieved, under which identity, for which prompt. Regulators under the EU AI Act, and internal risk committees long before them, will ask for exactly this.

Why this belongs in data strategy, not security backlog

Treating the above as a security ticket guarantees it arrives late and gets waived under delivery pressure. It belongs in the data operating model: the same forum that owns domains, ownership and interface contracts should own entitlement models and retrieval scope. In practice that means each AI-facing data product ships with three artefacts — a schema contract, an access policy and a lineage record — and none of the three is optional. Our advisory and architecture work almost always starts here, because retrofitting entitlements into a live agent estate costs several times what designing them in does.

The SAP and enterprise-application wrinkle

Core business systems complicate this further. Authorisation logic in SAP and similar platforms is deep, field-level and business-meaningful; naïvely exposing tables to an AI layer flattens years of segregation-of-duties design into a single privileged read. The credible pattern is to expose governed, purpose-built services that preserve the original authorisation semantics rather than bypass them — a discipline we apply across our SAP Commerce and CX engagements.

The organisations pulling ahead in 2026 are not the ones with the largest model budgets. They are the ones who can answer, in a single sentence and with a log to back it, what their AI is allowed to know. Build that answer first; the use cases get dramatically easier afterwards.

Frequently Asked Questions

Do we need to fix all our data quality issues before starting AI projects?

No — enterprise-wide cleanup programmes rarely finish and delay value indefinitely. Scope quality and entitlement remediation to the specific corpus each use case depends on, then expand as new use cases are approved.

How do we govern AI agents that act autonomously across multiple systems?

Give each agent its own identity with a named owner, declared purpose and risk tier, rather than letting it run under a shared service account. Then enforce least-privilege access per system and log every retrieval and action so behaviour can be attributed and reviewed.

Where should responsibility for AI data governance sit organisationally?

It works best as a joint accountability between the data office and security, governed through the same forum that owns data domains and contracts. Leaving it solely with security tends to push controls to the end of delivery, where they are most expensive to add.

Comments (0)

Leave a Comment

No comments yet. Be the first to comment!