Why the Way You're Giving AI Agents Data Access Is Probably Wrong

Data + AI Summit by Databricks is in full swing!!!! Just finished talking with Steven Touw, CTO at Immuta, on The Ravit Show, about one of the problems nobody is talking about yet but everybody will be talking about in six months. The problem: an AI agent needs access to data inside your Databricks lakehouse. What do most enterprises do right now? They plug in the agent with a user’s OAuth token. The agent inherits everything that user can access. Simple. Done. Here is what actually happens next: the agent now has a user’s full permissions. If the agent gets compromised, your data does too. If the agent runs a query you did not intend, it looks like that user ran it. If you need to revoke access, you have to revoke the whole user. The audit trail tells you a person did the work when a machine did it. Steve calls this the authentication-authorization gap for agents. Everyone is solving for “can the agent prove who it is” and ignoring “can we control what it actually does.” The alternative is what he calls “on behalf of” access. The agent can act on behalf of a user but does not inherit their full permissions. It gets a scoped token. It can only touch the specific tables and columns it needs. It can only do the operations it was designed to do. If it breaks, the damage is bounded. The audit log is honest. Revocation is surgical. This is not an Immuta problem. This is a security architecture problem that every company building production agents needs to solve right now. Watch the full conversation in the video below. This is the kind of problem that separates the companies shipping agents safely from the ones that are going to have a very bad incident next year. #data #ai #access #security #databricks #api #immuta #theravitshow