Databricks Summit 2026 shows agentic AI needs governance

At a glance

What this is: Databricks Data + AI Summit 2026 frames agentic AI as a production infrastructure problem, while Trust3 argues the unresolved gap is governance over agent scope, access, and behaviour.

Why it matters: IAM, NHI, and AI security teams need to treat AI agents as governed runtime actors, because infrastructure for sharing and execution does not by itself control what those agents can access or do.

Context

Agentic AI changes the control problem because software systems can now request data, invoke tools, and write state during execution. That is different from traditional analytics, where the main concern was where data lived and who could query it. The governance gap is therefore not just platform federation, but policy enforcement around runtime behaviour, access scope, and traceability.

Databricks Data + AI Summit 2026 is using infrastructure announcements to signal production maturity, but the underlying risk is familiar: capability can outpace control. When agent workloads span multiple clouds, catalogs, and transactional systems, identity, privilege, and auditability become the practical boundary between safe scale and unmanaged automation.

Key questions

Q: What breaks when agentic AI is governed only as a data platform problem?

A: The control model breaks because data governance does not answer who or what is acting on the data at runtime. Once agents can invoke tools, write records, or trigger workflows, teams need identity, privilege, and traceability controls that follow the action, not just the dataset.

Q: Why do AI agents need distinct machine identities in production?

A: Distinct machine identities let teams bind every agent action to a known runtime actor with a defined scope. Without that separation, shared service accounts blur accountability, make revocation difficult, and hide whether an action came from the intended agent or from another automated workflow.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: Should organisations separate analytics access from agent write permissions?

A: Yes. Read-heavy analytics and write-capable agent workflows create different risk profiles, so they should not share the same standing permissions. When the same role can both analyse and act, an error or compromise in the agent layer can turn into an operational change.

Technical breakdown

OpenSharing and cross-cloud AI asset exchange

OpenSharing extends the idea of data sharing to AI assets such as models, agent skills, and unstructured data. The technical shift matters because the exchange boundary is no longer just rows and files. A sharing protocol for AI assets needs to preserve trust, provenance, and policy compatibility across organisations and clouds, otherwise the receiving system inherits data without the context needed to govern its use. Open standards reduce friction, but they also widen the governance surface: every shared artifact becomes something that must be inventoried, classified, and controlled as it moves between trust domains.

Practical implication: Treat shared AI assets as governed objects, not just portable files.

Federated Catalog and centralized policy enforcement

Federated catalog architecture lets a governance layer query and control data that remains in external systems such as cloud catalogs or partner-managed stores. The key mechanism is policy convergence without physical data consolidation. That helps avoid unnecessary copying, but it also means governance now depends on consistent identity, authorization, lineage, and audit semantics across distributed sources. If those controls are uneven, federation can create a false sense of centralized oversight while leaving enforcement fragmented underneath.

Practical implication: Validate that access controls and lineage behave consistently across every federated source.

Lakebase and transactional agent workloads

Agentic applications differ from analytical systems because they do not only read data. They write records, trigger workflows, and maintain short-lived state while making decisions. A transactional layer for agents therefore needs low-latency writes, concurrency handling, and scaling behaviour that aligns with machine-driven actions rather than human-paced queries. The security question is not simply database performance. It is whether the operational layer can be bound to identity, permission, and logging controls tightly enough that agent actions remain attributable and reversible.

Practical implication: Bind agent write paths to explicit identities and auditable permissions.

NHI Mgmt Group analysis

Agentic AI governance debt is becoming the real integration tax: platforms can now move models, data, and agent skills across clouds, but most organisations still govern those objects as if they were static analytics artifacts. That mismatch creates blind spots around who can invoke an agent, what data it can touch, and how its actions are attributed. The control problem shifts from storage location to runtime authority, which means identity governance must move earlier in the design cycle.

Open standards reduce lock-in, but they also raise the bar for policy portability: a protocol like OpenSharing only becomes useful at enterprise scale if policy semantics travel with the asset. Otherwise, every external exchange becomes a local exception process, and every exception process becomes an audit burden. The practical lesson is that interoperability without enforceable governance simply relocates risk across organisational boundaries.

Agent runtime governance is now a named discipline, not an optional overlay: the article’s central insight is that visibility into data movement is no longer enough once AI systems can act. Enterprises need to know which agent initiated the action, which permissions were in force, and whether the operation stayed within intended scope. That is the difference between managing AI as infrastructure and governing AI as an active decision-making system.

Federation changes the identity assumption behind access control: central governance only works when the downstream systems reliably honour the same trust decisions. In multi-cloud AI environments, access control, lineage, and auditing become distributed enforcement problems, not just catalog features. Practitioners should treat federation as a control-design exercise, not a data-integration shortcut.

Transactional AI exposes NHI and agent identity issues that analytics platforms could ignore: once an agent can write to production systems, its credentials, privileges, and session boundaries matter as much as its model output. That intersection makes NHI governance relevant to agentic AI architecture, especially where service accounts or workload identities are used to execute actions. If the agent identity layer is weak, the infrastructure layer becomes an accelerant rather than a safeguard.

What this signals

Agent runtime governance is where enterprise AI programmes will increasingly be judged. The capability to share models and run transactional agents across clouds is useful only if the organisation can prove who the agent was, what it touched, and whether the action stayed within scope.

Infrastructure projects often win budget first, but the control gap shows up later. Security leaders should expect agent identity, policy enforcement, and audit traceability to become part of the implementation baseline, not a separate hardening phase.

For practitioners

• Define agent identity before production rollout Assign each agent a distinct machine identity, scope its permissions to the minimum required actions, and document the systems it may invoke. This prevents shared credentials from hiding which agent performed a write or tool action.
• Classify shared AI assets for governance Inventory models, agent skills, prompts, and unstructured inputs as governed assets with owners, retention rules, and permitted sharing boundaries. Apply the same discipline to externally exchanged artifacts that you already expect for internal data.
• Verify policy consistency across federated catalogs Test whether access decisions, lineage, and audit records remain stable when the same data is queried through multiple catalogs or clouds. Inconsistency here creates a governance gap even when the underlying data remains unchanged.
• Separate transactional agent writes from analytics access Use distinct controls for read-heavy analytics and write-capable agent workflows so that operational actions are logged, reviewed, and revoked independently. This reduces the chance that a broad data role quietly becomes an execution role.
• Instrument runtime tracing for agent decisions Capture every data access, tool invocation, and state change made by agents so that security, data, and platform teams can reconstruct behaviour after an incident or policy violation. Tracing should sit at the same level of urgency as access logging.

Key takeaways

• Databricks Summit 2026 shows that agentic AI is now a production architecture issue, but governance remains the limiting factor.
• The central risk is not just where AI assets move, but whether runtime actors can be identified, scoped, and traced across systems.
• Security and IAM teams should align agent identity, privilege boundaries, and audit evidence before scaling write-capable workflows.

Key terms

• Agent Runtime: The agent runtime is the execution environment where an AI agent reads data, calls tools, and carries out actions. It matters because the runtime is where identity, policy, and filesystem boundaries either hold or fail. If those boundaries are weak, the agent becomes a high-privilege path into the environment.
• Federated Catalog Governance: A control model in which metadata, policy, lineage, and auditing are enforced across catalogs that remain in separate systems. It reduces data movement, but it only works when identity mapping and entitlement enforcement stay consistent across every participating platform.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and agentic AI identity. It helps security practitioners connect runtime access decisions to the controls their programmes need.