Traditional Data Governance Wasn't Built for AI Agents

Role-based access, column-level classification, quarterly access audits, and the rest of the traditional data governance toolkit were designed around a human consumer. AI agents are a different kind of consumer entirely, and the controls made for one don't carry over to the other.

The dangerous part is that everything still appears to be working. Logs still populate. Permissions still get applied. But the assumptions baked into traditional governance no longer hold, even though nothing on the surface looks broken.

The cleanest way to understand where those assumptions fail is to walk through each one. Below are five specific places where traditional governance made sense for the consumer it was designed for, and why that logic no longer applies.

What changes when the consumer is an agent

AI agents introduce a second identity

Every traditional governance model assumes the same starting point: every action traces back to a known identity or role. When something breaks, you can point to who broke it. AI agents don't have a single responsible party in that sense. An agent authenticates using a service account, and when it queries on a user's behalf, the database only sees that service account, not the person behind the request.

That means a transaction now involves two identities: the agent executing the query and the user whose intent triggered it. Traditional governance assumed one actor making one deliberate decision. Acting on someone else's behalf wasn't part of the original design.

Adding an intermediary breaks the model. Row-level security tied to the actual user never gets triggered. Instead, whatever broad permissions the service account holds are the ones that apply. This is part of why EU AI Act Article 12 now requires that AI system logs trace each interaction back to a responsible party.

AI agents are non-deterministic

Traditional governance assumes deterministic systems: same input, same output, every time, which is what makes the behavior predictable enough to govern. AI agents don't work that way. Run the same prompt twice and you can get two different queries out of it. There's no fixed version of what an agent "does" for a given request; its behavior gets decided at runtime based on the model and whatever context it picks up along the way.

That breaks the governance model at its core. Every traditional control depends on being able to define acceptable behavior ahead of time. Policies get written against known, expected actions, and audits check what happened against what should have happened. Non-determinism removes that reference point entirely. If behavior can't be predicted in advance, a policy can't govern what it never defined.

AI agents create sensitive data at query time

Data classification was built to tag sensitivity at the field level: a social security number column gets marked PII, a compensation schema gets restricted. The underlying assumption is that sensitivity lives in the data itself and can be known before a query ever runs.

AI agents rarely stick to one source. They pull from every connected system and stitch the pieces into a single answer. The sensitivity of that combined answer doesn't exist until the query actually runs.

This is where classification breaks down. A field marked external in Salesforce and a field marked internal in Workday can each clear their own individual check. What no classification system checks is what happens when those two fields are combined. Deal ownership joined with payment history for a specific person can be far more sensitive than either source was on its own, and that sensitivity only shows up because of the join.

AI agents read and write in the same execution

Under the old model, reads and writes were governed separately because they happened separately. Analysts ran queries. Applications modified data through defined workflows. Different systems handled each, so different controls could apply to each.

That separation doesn't exist for AI agents. In a single run, an agent might pull data from a CRM, reason over it, update a field, kick off a downstream workflow, and send a result back to whoever made the request. And this scales fast: agents aren't doing one write per session the way a person might. They run continuously, cycling through dozens of reads and writes per task.

Traditional governance has nothing built for that pace or that level of autonomy. Write controls were calibrated for human-speed, deliberate changes, and the risk profile of agent writes looks nothing like that anymore.

AI agents outlive their permissions

Human access was self-correcting by nature. Change roles, and permissions change with you. Leave the company, and access ends. Traditional governance was built assuming that access would get revisited on some kind of regular cycle.

Service accounts have none of that built in. Nothing changes roles or offboards them. They get spun up whenever a project needs one, granted whatever access seemed reasonable at the time, and then left running indefinitely. Permissions pile up gradually, one small addition at a time.

That's a real problem the moment revocation is needed during an incident. If a service account is shared across three other agents and a couple of automated pipelines, pulling it kills everything downstream. Scoping it down to just the one workload that needs fixing means rebuilding the whole permission structure from the ground up.

None of these five failures is surprising taken alone. What matters is that they all trace back to the same root cause.

Closing thoughts

The common thread across all five is timing. Roles, queries, columns, and permissions in traditional governance are all set up at design time. AI agents operate entirely at runtime, carrying the user's intent, the conversation history, the task at hand, and everything else with them. That's the context they use to decide, in real time, what to query and which sources to pull together.

Governance built to be configured before execution has no way to reason about context that only exists during execution. That gap calls for a different layer, one that runs alongside the agent at runtime, evaluating every query in the context it was generated, under the identity that generated it, across every connected source at once. That's what tools like Peaka were built to do. It sits on top of the infrastructure you already have without replacing any of it.