Governing AI Agents' Data Access: Least-Privilege for Non-Humans

Gartner said in a May 2026 press release that 40% of enterprises will demote or decommission at least one AI agent by 2027 — not because the agent underperformed on its task, but because nobody could account for what it had access to. I've spent ten-plus years on the access-control side of that exact problem: building the identity, permissioning, and classification programs that are supposed to answer "what can this thing touch, and who signed off on that" before an auditor or a security incident forces the question. AI agents are breaking almost every assumption those programs were built on, and most enterprises deployed them faster than anyone updated the model.

This isn't a theoretical gap. It's the same category of problem I've worked for years in enterprise data catalogs and cloud permissioning — just with a non-human requester that doesn't behave like the requesters the system was designed for.

Why human-centric IAM breaks for agents

Identity and access management, as most enterprises run it today, has a few load-bearing assumptions baked in. Each one breaks differently when the requester is an agent instead of a person.

• No clean session boundaries. A human logs in, does work, logs out. An agent can be invoked recursively, spin up sub-agents, or stay "warm" across a long task queue with no natural point where access should reset. Session-based revocation — the thing that makes "just log them out" a viable incident response — doesn't map cleanly onto a process that isn't really a session at all.
• Credential sprawl. One person typically holds one identity across a handful of systems. One agent often holds a credential per tool, per API, per data source it's wired into — and those credentials get provisioned quickly during a proof-of-concept and rarely get inventoried once the agent goes into production. I've seen this same pattern in ordinary cloud permissioning work: entitlements that were never cleaned up after the pilot phase. Agents just generate that sprawl faster, because adding a new tool is often a config change, not a request ticket.
• Transitive access via tools and MCP. When an agent is given a tool — a database connector, an internal API, an MCP server — it doesn't just get that tool's stated function. It gets whatever that tool's underlying credential can reach. A "read customer support tickets" tool built on a service account with broader database access quietly hands the agent everything that account can see, whether or not anyone reviewed that scope at connection time.
• Agents writing to systems humans only read. Most legacy access models assume the risky action is a human viewing sensitive data. Agents flip that: an agent with a low-privilege "read the ticketing system" mandate can also be the thing that drafts and sends the reply, updates the record, or triggers a downstream workflow. Write access that would have required a change ticket for a human process now happens inside a tool call, often without an equivalent approval gate.

A least-privilege model for non-human identities

The fix isn't a new AI-specific control framework bolted on top of existing IAM — it's applying least-privilege properly, with the recognition that "the user" is now sometimes a process instead of a person.

Agent service identities. Every agent — not every agent type, every deployed instance — gets its own service identity, distinct from any shared account and distinct from the human who built or owns it. This is the same principle I've configured directly in cloud environments: Azure, Databricks, and SQL access controls all support scoping permissions to a specific service principal rather than a shared credential, and agents should be treated the same way. If an agent misbehaves, you want to be able to revoke exactly that identity without collateral damage to five other integrations sharing the same token.

Scoped, short-lived tokens. Long-lived API keys are the wrong pattern for anything that runs autonomously. Tokens should be scoped to the narrowest set of resources the specific task requires and expire on a schedule that forces re-issuance — which also forces a re-check of whether the agent should still have that access at all.

Autonomy tiers mapped to data sensitivity tiers. This is the part most agent deployments skip entirely. Not every agent should have the same ceiling, and the ceiling should be a direct function of what data it can reach:

That table only works if the sensitivity column is accurate. This is where agent governance runs straight into catalog work that has nothing to do with AI: if your Alation or Collibra classifications are stale — new tables added since the last review, columns re-purposed, PII fields that migrated to a new schema without anyone re-tagging them — then your agent access policy is enforcing rules against a map that no longer matches the territory. I directed an enterprise Alation rollout at a Fortune-200 agriscience company specifically to keep classification current across cross-functional teams, and the lesson generalizes directly here: an access model is only as trustworthy as the classification layer underneath it. If you're evaluating catalog tooling to get that foundation in place, I go through the buy-vs-build tradeoffs in my post on data governance tool RFPs and total cost of ownership. And if your definitions and data dictionary are the thing feeding an internal AI assistant, retrieval quality depends on governance quality in exactly the same way.

The scoped-token and tier model also needs to live somewhere enforceable, not just in a policy document. On Databricks specifically, I've found that mapping autonomy tiers onto attribute-based access control at the Unity Catalog layer — rather than static role grants — is what actually lets the ceiling in that table hold up automatically as new tables get classified. I go deeper on that specific mechanics in this post on moving from Unity Catalog grants to ABAC.

What I do in my own stack

Separately from client work, I run a local multi-machine fleet — I've written about the architecture in detail — and I apply the same least-privilege logic to my own agents, just at a much smaller scale. Two things carry over directly.

First, per-agent credentials, always. Even in a personal setup with three machines and a handful of agentic pipelines, every agent that touches an external API or writes to a file system gets its own key or token, not a shared one. It's tempting to reuse a single API key across every script because it's faster to set up — I did that early on, and the first time I needed to know which agent had made a specific external call, I couldn't answer the question. Separate credentials made every subsequent audit a non-event instead of a forensics project.

Second, fail-closed defaults with a local screening step in front of anything an agent sends outbound. Before an agent's output leaves the machine — a file write, an API call, a message to an external system — it passes through a lightweight local check against a policy file: is this destination allow-listed, does this payload match a pattern that shouldn't leave the network, is this the kind of write this specific agent is actually scoped for. If the check can't confirm the action is allowed, it blocks by default rather than allowing by default. That single design choice — fail closed, not fail open — is the cheapest control I run, and it's the one I'd tell an enterprise team to implement before anything else on this list.

A five-step starting checklist

1. Inventory every agent's current access — not what you provisioned, what it can actually reach through every connected tool, including transitively.
2. Give every agent its own service identity and kill any shared credentials agents are currently using.
3. Verify your data classification is current before you write a single access rule based on it — a policy built on stale tags is a policy built on fiction.
4. Define autonomy tiers explicitly and map them to sensitivity tiers, in writing, before the next agent goes into production.
5. Default to fail-closed on any agent action that writes, sends, or reaches outside the system it was scoped for.

What would make this wrong

• If agent frameworks converge on a standardized, auditable permissions layer the way OAuth standardized human delegation, a lot of this becomes platform default rather than something each enterprise has to build — which would be a genuinely good outcome, not a reason this analysis was wrong, just a reason it becomes less necessary.
• The Gartner figure is a prediction about 2027, not a measured outcome — if agent governance tooling matures faster than adoption outpaces it, the 40% figure could land much lower.
• Autonomy tiers add friction, and there's a real failure mode where an overly rigid tier model just gets bypassed informally the same way over-strict human access reviews get rubber-stamped. A tiering model nobody actually enforces is worse than no model, because it creates false confidence.
• Small teams without a dedicated security or governance function may reasonably conclude the overhead here isn't worth it at their scale — this framework is aimed at enterprise deployments with real regulatory exposure, not a two-person startup's internal tooling.