Data-Level Controls And Decision Evidence Take AI Agent Governance Beyond Audit Logs

AI agents can now change enterprise data on their own. They update records, route cases and start workflows. That makes the database the most important place to govern them.

Telling an agent which records to leave alone isn’t enough, and neither is a policy document. Permissions, access rules and approval steps need to be enforced in the data itself, so they apply no matter how an agent reaches it. Organizations also need a clear record of why each action was allowed.

Gopichand Mannava is Chief Data Architect for the State of Connecticut and an independent researcher. He helps lead architecture and modernization for STARS, the state’s enterprise analytics platform supporting finance, workforce and operational decisions, and he serves on the advisory boards of the National AI Consortium and the American Council for Ethical AI. Connecticut has roughly 150 AI pilots underway across chatbots, agents and vendor tools, and that work keeps Mannava focused on what changes once agents move from answering questions to taking action.

“For consequential AI actions, the enterprise needs more than observability. It needs evidence,” Mannava says. A log can confirm that a transaction went through. Proving the agent was allowed to make it takes controls that start well below the application.

Controls start in data

Connecticut adopted its AI Responsible Use Framework in February 2024 and put governance and policy first in its AI program. Policies only protect data when the systems holding it enforce them. Many organizations secure AI at the application, such as a dashboard or front end. As agencies connect chatbots and their own language models to enterprise data, that leaves gaps. “You can give security at the application level, on a front end or a dashboard, but the same underlying data can be used in many places, accessible to many end users through multiple data sets or API keys. If security measures aren’t there at the data level, it’s a complete risk,” Mannava says.

Role-based and row-level security close those gaps by attaching rules to the tables and rows themselves. They can be set by department, by job function or by the person the agent is working for. A procurement officer can see and approve only procurement records, and an agent working in procurement gets the same limits. Mannava recommends that data leaders test each data set from several directions, including through a direct API call, to confirm the same rules apply every time.

Hard stops for high stakes

Some decisions carry too much weight to hand to an agent. In the public sector, actions that touch benefits and payments still have hard stops that require a person to decide. “For critical approvals where the impact on citizens is huge, like Medicaid, Medicare or EBT, those actions are still supposed to be human. A human should make the decision and a human should review it,” Mannava says.

Those limits can live in the same access rules. An agent’s role can include permission to flag an issue, pull together the supporting data and propose a change, while final approval belongs to a person whose role allows it. That keeps the decision with someone accountable and gives auditors a clear point to check.

Keeping a person on the final call also changes that person’s job. Philip Samuelraj, Founder and CEO of Techjays, a firm that builds custom AI systems for mid-sized companies, sees that shift in the workflows his team redesigns. “Once an agent prepares the case, the reviewer is really supervising the agent’s work, and that’s a different skill. They need to know what the agent checked and what it left out. Without that, people end up approving whatever the agent hands them,” Samuelraj says.

Modeling comes first

Many leaders want to skip the modeling work that makes these controls possible. They see how fast a conversational tool can answer a question and want to point it at their database before the data is organized or secured. “Executives ask me, ‘I have a database. I just want the insights. I don’t want to spend time on data modeling. I want to connect directly to my database and get an income statement for a city or a town.’ That’s a simple question, but we have billions of records in the backend tables. You need to define the keys and the joins between the fact tables and the dimensions, build a proper data model and implement security in that model. That’s where everything starts,” Mannava says.

A well-built warehouse, with metadata and lineage, tells an agent what the data means and where it came from. Security built into the data model also limits what an agent can reach in the first place, before any approval step. With that foundation, agents can work directly with production data and stay inside the rules. This doesn’t remove every risk, and Connecticut still treats its agent work as a learning phase. Testing and early deployments show teams how agents behave under these controls and where the controls need work. Organizations that rush to a working demo without this groundwork often have to go back and rebuild, losing the time they hoped to save.

This work can end up with IT alone, even though it captures how the business runs, such as how a customer is defined or which team owns an approval. “Those decisions belong with the executives who run each part of the business. When they help make them, every agent built afterward works by their rules,” Samuelraj says.

Evidence beyond logs

Data-level controls also produce the proof that an action was allowed. Mannava calls this a decision-evidence architecture, a connected record for every high-impact agent action. It shows which agent acted, what authority it held, and which data it used and where that data came from. It also shows which policies were checked, which tools the agent called, who approved or overrode the action and how the change can be reversed.

In most organizations, those details sit in separate systems for identity, policy, lineage and approvals. Tying each piece to the same action ID, and keeping it with the data the agent touched, turns those fragments into evidence. “If an organization has to assemble these facts from five different systems after an incident, it does not have a decision-evidence architecture. It has fragmented telemetry,” Mannava says.

Take an agent that flags likely duplicate vendor records and proposes merging them. Before the merge goes through, the organization should be able to show:

• which agent proposed it, and whether it was allowed to see vendor data

• which sources it used, and what matching rules and confidence levels applied

• whether segregation-of-duties checks ran

• who signed off on the change, and how to roll it back

The same standard applies to agents that process claims, update customer records or change workforce data. Leaders can read the same records with a different question in mind. “Every action an agent logs is also a data point on how the work is going. You can see where people keep having to step in and what each workflow is saving. That tells a CEO where to put the next dollar,” Samuelraj says.

Most enterprise AI programs track adoption, task volume and cost savings. Those numbers measure how much work agents are doing. They don’t show whether an organization can govern its agents. The measure that matters here is whether a team can explain any single action after the fact, using records the data layer already keeps. That bar rises as agents move into production, and it’s easier to meet when security and lineage are designed into the data model from the start. “The critical question is no longer only, ‘Can this agent complete the task?’ It is, ‘Can the enterprise prove why the agent was allowed to complete it?’” Mannava says.