Notifications
Clear all
Topic starter
22/08/2026 12:01 pm
TL;DR: Databricks' summit updates show how agentic AI is pushing identity, access, and audit controls into runtime decisions, with context-based ingress, automatic identity sync, and agent visibility framed as the path to safer scale across clouds, according to Trust3. The real shift is that governance now has to follow agent behaviour session by session, because static policy assumes access is requested by a human, not initiated by an agent.
NHIMG editorial — based on content published by Trust3: Securing the Agentic Era: Inside Databricks Summit 2026
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do AI agents create more risk than traditional automation?
A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously.
Q: What breaks when agentic AI is governed like a normal application account?
A: Security controls break down because agentic systems do not behave like fixed-function applications.
Practitioner guidance
- Map every AI agent to a governed identity Require each production agent to have a cryptographically managed identity, an owner, a lifecycle record, and a defined purpose before it can reach data or tools.
- Tie ingress policy to declared use case Allow access decisions to evaluate device posture, session context, and task purpose so that open-ended queries do not inherit the same permissions as routine dashboard access.
- Log prompts, retrievals, tool calls, and data access Retain decision-level telemetry long enough to reconstruct the agent path, support investigations, and demonstrate purpose alignment for regulated data.
What's in the full article
Trust3's full article covers the operational detail this post intentionally leaves for the source:
- A closer walkthrough of the platform controls behind Automatic Identity Management and how they affect human and service principal onboarding.
- The specific context-based ingress policy examples used to separate benign dashboard access from higher-risk AI query paths.
- Operational details on agent discovery, audit logging, and purpose-based access context across multi-cloud deployments.
- The control-plane model for tracking token usage, prompt loops, and agent behaviour in real time.
👉 Read Trust3's analysis of Databricks Summit 2026 and agentic AI governance →
Agentic AI data access controls: are your governance models keeping up?
Explore further
22/08/2026 12:02 pm
Agentic AI creates an identity governance problem before it creates an AI governance problem. The moment an AI system can choose actions at runtime, the security question shifts from provisioning access to governing behaviour. That means IAM, IGA, and PAM programmes must stop treating agent access as a static entitlement model and start treating it as a runtime identity problem.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: Who is accountable when an AI agent exceeds its intended scope?
A: Accountability should follow the delegation chain, not stop at the agent label. The human requester, the policy owner, and the team that granted underlying access all matter, because the agent acts within a permission model someone designed. If the chain is unclear, the governance model is already too weak.
👉 Read our full editorial: Agentic data access controls are changing how cloud AI is governed
