Databricks agent governance exposes the limits of IAM visibility

At a glance

What this is: This is SailPoint’s announcement of a Databricks connector for AI agent governance, framed around the broader problem that autonomous agents are already acting beyond intended scope.

Why it matters: For IAM and NHI teams, it shows why agent governance must extend into data and AI platforms where identity, access, and accountability can drift faster than reviews.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• Companies using AI governance put over 12x more AI projects into production.

👉 Read SailPoint's blog on Databricks agent governance and AI identity control

Context

AI agent governance is becoming an identity problem because autonomous software now signs in, queries data, and performs actions with delegated authority. That creates a gap between traditional IAM controls, which were built around human users and stable service accounts, and the more fluid access patterns of AI agents.

SailPoint’s Databricks connector is best read as a signal that agent governance is moving into the places where agents are built and executed, not just where they are catalogued. That is typical of the broader market: organisations are discovering that visibility without ownership and permission context is not enough for non-human identity control.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Treat each agent as a non-human identity with an owner, a defined purpose, and a bounded permission set. Then connect discovery, access review, and certification so the agent’s actual runtime behaviour is reviewed, not just its registration. That approach reduces hidden privilege and makes incidents easier to investigate.

Q: When does AI agent access become too risky to leave standing?

A: Standing access becomes too risky when the agent can read sensitive data, trigger downstream actions, or operate across multiple systems without a tight task boundary. At that point, least privilege should be task-scoped, time-bounded, and re-approved whenever the agent’s purpose changes.

Q: What is the difference between human IAM and AI agent governance?

A: Human IAM assumes relatively stable roles and predictable behavior. AI agent governance must handle autonomous execution, changing tool use, and delegated authority that can expand quickly across systems. That means ownership, purpose, and runtime visibility matter more than static account labels.

Q: How can organisations reduce the blast radius of AI agents?

A: Limit each agent to the minimum data, tools, and actions required for a specific task. Pair that with continuous review of effective permissions and revoke access when the task ends or the workflow changes. The goal is to keep autonomy narrow enough that misuse does not spread across adjacent systems.

How it works in practice

How Databricks agent identity creates governance gaps

Databricks agents operate inside a data and AI platform where identity signals, permission scopes, and workload behaviour can change quickly. The governance problem is not simply whether an agent exists, but whether the organisation can identify the agent, bind it to an owner, and see what it can touch in Unity Catalog and related systems. Once an agent can retrieve data or invoke actions on behalf of a user, it starts to resemble a high-trust NHI rather than a simple application component. That is why discovery, ownership, and entitlement review have to work together.

Practical implication: Practitioners should inventory every agent, map it to a human owner, and review its effective permissions before expanding deployment.

Why unified identity governance matters for AI agents

AI agents break the assumption that identity governance can be handled in separate silos for humans, workloads, and applications. A unified model is needed because the same agent may have data access, tool access, and delegated execution rights, all of which can create distinct blast radii. Connector-based governance helps surface who owns the agent, what resources it can reach, and whether its access still matches purpose and sensitivity. Without that linkage, certification processes become stale as soon as the agent’s behaviour changes.

Practical implication: Security teams should connect agent discovery to access certification so review workflows reflect real runtime privileges, not static registrations.

What purpose-based access control changes for agentic AI

Purpose-based access control goes beyond role assignment by asking why the agent needs access and whether the current task justifies it. For agentic systems, this matters because broad standing access increases the chance that an agent will overreach when prompted or misrouted. Tying access to purpose, sensitivity, and usage gives security teams a practical way to narrow agent privilege without blocking every workflow. The control goal is not to make agents harmless, but to make their authority legible, bounded, and reviewable.

Practical implication: Use purpose, sensitivity, and usage criteria to prune standing access and force re-approval when the agent’s task changes.

NHI Mgmt Group analysis

AI agent governance is becoming an NHI control problem, not a niche AI feature. Once agents can authenticate, query data, and act independently, they inherit the same governance burdens as service accounts and privileged workloads, but with less predictability. That makes discovery, ownership, and entitlement review core controls rather than optional hygiene. Practitioners should treat agents as a formal NHI class and govern them accordingly.

There is an emerging identity blast radius problem in agentic platforms. An agent rarely needs broad access to be useful, yet broad access is often what it receives by default when integrations are rushed into production. The practical risk is not just excess permission, but the speed at which excess permission becomes data exposure or unauthorized action. Teams should design for minimal effective authority and measure the blast radius of each agent before expansion.

Purpose-based controls are more useful than static role models for agents. Roles describe job function, but agents behave like task executors whose authority should change with context. That is why access bound to purpose, sensitivity, and real usage is a stronger fit than role-only governance. The discipline should move from “who is this account?” to “why does this agent need this access right now?” Practitioners should align policy to task scope, not identity labels alone.

Connector coverage is becoming a governance requirement, not an integration convenience. As AI agents move into more platforms, governance fails when identity tooling cannot reach the systems where those agents actually operate. The market is moving toward control at the source system, because off-platform inventories age too quickly to support reliable certification or investigation. Security teams should prioritise connector reach wherever agentic workloads are created, executed, or granted data access.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• This is why the OWASP NHI Top 10 and agentic AI controls should be used together when teams design governance for autonomous software.

What this signals

Agentic AI is pushing NHI governance into the control plane of the data platform. When AI agents execute inside systems like Databricks, identity tools have to reach the runtime, not just the directory. That shifts the programme from periodic inventory to continuous entitlement control, and it makes connector coverage a governance dependency rather than a nice-to-have. Teams should expect more scrutiny of where agents are created, not only where they are approved.

With 96% of technology professionals identifying AI agents as a growing security threat, the governance backlog is now structural rather than temporary, according to AI Agents: The New Attack Surface report. The practical response is to fold agents into access certification, ownership workflows, and incident triage before their permissions become untraceable. Governance that arrives after deployment will be too slow to matter.

The right planning model is no longer a human-first IAM workflow with agents added later. It is an identity programme that treats autonomous systems as first-class workloads, tracks privilege drift continuously, and uses policy to constrain purpose before scale multiplies risk.

For practitioners

• Inventory every AI agent as an NHI asset Create a living register that includes agent name, system of record, human owner, purpose, and the data domains it can access. Use that register as the basis for certification, audit, and incident response.
• Tie agent access to explicit purpose and task scope Remove standing access wherever possible and require re-approval when an agent changes function, data scope, or deployment environment. Purpose-based controls reduce the chance that a reused agent inherits excessive privilege.
• Review Unity Catalog and adjacent permissions together Do not assess Databricks access in isolation. Trace what the agent can query, what it can trigger, and where those permissions are inherited from so the effective blast radius is visible.
• Build certification workflows around agent behaviour Use access review processes that consider observed usage, ownership, and business purpose, not just the presence of a connector or a registered account. Agent behaviour can drift faster than manual review cycles.

Key takeaways

• AI agents now create NHI governance risk because they authenticate, access data, and act independently inside enterprise systems.
• The evidence points to a control gap, with most organisations recognising the threat but far fewer applying formal governance policies.
• Practitioners should anchor agent governance in ownership, purpose, and runtime visibility before expanding platform deployments.

Key terms

• AI Agent: An AI agent is autonomous software that can take actions, call tools, and use credentials to complete tasks with some degree of execution authority. In security governance, it should be treated as a non-human identity because it can create access risk even when no human is directly operating it.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if its credentials, permissions, or delegation are abused. For AI agents and other NHIs, the blast radius depends on what systems they can reach, what data they can read, and what actions they can trigger.
• Purpose-Based Access Control: Purpose-based access control grants or denies access according to the task an identity is meant to perform, not just its role or account type. For agents, this helps security teams limit standing privilege and force re-approval when the workflow, data set, or environment changes.
• Agent Certification: Agent certification is the review process used to confirm that an AI agent’s access still matches its intended function and owner. It combines entitlement review, usage context, and business justification so that autonomous systems do not keep privileges simply because they were once approved.

What's in the full announcement

SailPoint's full blog covers the operational detail this post intentionally leaves for the source:

• Connector-specific discovery and governance flow for Databricks Unity Catalog and Agent Bricks
• The broader SailPoint ecosystem of supported agent platforms and how the integrations are organised
• How the Web Services SaaS universal connector is positioned for custom or niche AI agents
• The webinar series referenced at the end of the post and how SailPoint frames the adoption path

👉 The full SailPoint post outlines the Databricks connector, supported agent platforms, and the governance model behind them.

Deepen your knowledge

AI agent governance and identity blast radius are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous systems in a similar environment, it is worth exploring.