When AI Agents Can Change Your Data, Who Decides What They’re Allowed To Do?

Imagine an employee asks an AI agent to clean up duplicate customer records. The agent checks the database, finds what looks like the same person listed three times and merges the records. From the user's perspective, that sounds like exactly the sort of tedious work an agent should be able to handle. But what if one of those records belonged to someone else? 

The interesting governance question isn't whether the agent was allowed to access the customer database. Presumably it was. Otherwise, it couldn't have done the job at all. The more important question is what authority it had once it got there:

• Could it only read records?
• Could it update them?
• Merge them?
• Delete one completely?

This is where AI data governance starts becoming more complicated than the access controls enterprises already know how to manage. For years, data governance has become increasingly sophisticated about deciding who can see sensitive information, which parts they can see and under what circumstances. 

Agentic AI adds another layer because some AI systems aren't simply consuming enterprise data anymore. They're increasingly capable of changing it. Informatica's 2026 CDO Insights research, based on a survey of 600 data leaders, found that 47 per cent of organisations had already adopted agentic AI, with another 31 per cent planning to do so within 12 months. 

Yet 76 per cent said AI visibility and governance hadn't kept pace with employee AI use. Almost half were extending their existing data governance tools to incorporate AI. That last finding is particularly interesting because it suggests this doesn't necessarily need an entirely new governance discipline. 

Instead, organisations may need to rethink what their existing controls are actually designed to govern. Access is still part of that conversation. But once machines become legitimate writers to enterprise data, simply knowing who or what can see something isn't enough.

Data Governance Has A New Write Problem

Most enterprise data controls are very good at answering questions about access:

• Which employee can view the payroll table?
• Should this contractor see customer addresses?
• Can someone in marketing query the entire customer dataset, or only the columns relevant to their work?

Modern platforms can get incredibly precise about the answers. What changes with agents is that data access can become the beginning of an action rather than the end of a request. An agent might read an inventory table because it needs to update stock levels. It may query a customer record before changing an account status or append information to a case file before triggering another workflow. 

Those are very different interactions from running a report. Futurum Research highlighted this change in its August 2026 Data Intelligence Platforms assessment. The firm evaluated 15 enterprise vendors across 10 capability areas and argued that the market is moving from read-only AI towards systems that can support governed transactional execution by autonomous agents. 

The wording is technical, but the underlying change is simple. A data platform may increasingly need to support machines that don't just ask what the current state of something is. They may also change that state. 

That raises a governance question organisations haven't traditionally needed to ask at this scale: If an AI agent is allowed to change enterprise data, exactly what kind of change is it authorised to make?

Read Access And Write Authority Aren’t The Same Thing

Reading and writing data can look like two sides of the same permissions problem. Operationally, they're quite different. A read operation retrieves information that already exists. Unless something else happens afterwards, the data itself remains exactly where it was and exactly as it was. A write operation leaves something behind. 

It changes a value, adds a record, removes information or alters the structure containing it. That persistence changes the consequence of getting something wrong. An agent that misreads an inventory record may give someone a bad answer. An agent that incorrectly updates the inventory itself can leave every system querying that record with the same wrong information. 

If that data then feeds fulfilment, procurement or forecasting systems, the original mistake can continue moving through normal business processes. This is why machine write authority deserves to be treated as a governance decision in its own right. Giving an agent access to customer data doesn't automatically mean it needs permission to change every customer field. 

Allowing it to add a note doesn't mean it should be able to rewrite the original record. And permission to update records certainly doesn't imply authority to change the rules governing them. Once you separate access from authority, another distinction becomes clear. There isn't really one thing called "write access". There are several different kinds of power hiding inside it.

Not All Write Access Gives An Agent The Same Authority

Database administrators have always distinguished between different operations. What's changing is the importance of applying that thinking to machine actors operating with greater independence. A useful way to think about AI agent permissions is as an authority hierarchy:

Read → Append → Update → Delete → Change schema → Change policy

The further you move along that sequence, the more fundamentally the system is allowed to alter the data environment. But it shouldn't be treated as a universal risk score. Deleting an expired temporary record may be far less consequential than updating the wrong value in a financial ledger. The point is that these actions aren't interchangeable. 

Databricks offered a particularly timely example on 23 August 2026 when it updated Unity Catalog with separate INSERT, UPDATE and DELETE privileges. The Beta feature gives organisations finer alternatives to the broader MODIFY privilege, allowing a principal to change table data without automatically receiving authority over the table's schema or other metadata. 

It's an important distinction because "can modify this table" hides several different decisions. One agent may only need to append new transactions. Another may need to correct an existing field. A third might need deletion rights for a narrowly defined cleanup process. 

Giving all three the same broad modification privilege is easier to configure, but it also gives each one authority it doesn't need. That principle isn't new. It's basic least privilege: give an identity only the permissions required to perform its job. What's changing is the identity doing the work. 

As more AI agents become connected to operational data, least privilege access increasingly needs to account for what type of change a machine can perform, not only which dataset it can reach. And even that isn't quite enough.

Machine Authority Needs Context, Not Just Granularity

Suppose two agents both have permission to update records. On paper, their database permissions look identical. One can update the delivery status field on orders assigned to a particular warehouse. The other can update any field across every customer record in a regional database. Technically, both have UPDATE authority. 

From a governance perspective, they're not remotely equivalent. This is where scope starts doing as much work as the permission itself. The useful question isn't simply, "Can this agent update data?" It's closer to:

• "Which data can it update?"
• "Which fields can it change?"
• "For what purpose?"
• "Under what conditions?"
• "For how long?"

Databricks' new privileges illustrate the problem from another direction. Because Unity Catalog privileges can inherit through its hierarchy, granting INSERT, UPDATE or DELETE at catalogue or schema level can automatically extend that permission to current and future tables beneath it. So a granular operation granted at a very broad level may still create broad authority. 

The same principle applies beyond databases. Snowflake's August 2026 governance updates for CoCo include tool-level policy controls that can distinguish between different actions offered by the same external service. Snowflake gives the example of allowing a Salesforce read tool while disabling a delete tool. 

This points towards a more contextual model of data governance controls. The operation matters. So does the object being changed, the scope of the permission and the business consequence if something goes wrong. A governance model that considers only one of those dimensions can look precise while still giving machines far more authority than intended. 

Once those boundaries exist, though, organisations face another question. Permissions tell you what an agent was allowed to do. They don't necessarily tell you what it actually did.

Every Machine Write Needs A Chain Of Accountability

Traditional data governance already cares deeply about audit trails. If a sensitive record changes, organisations often need to know when it changed, who changed it and sometimes why. Machine writers don't remove that requirement. If anything, they make the history around the change more useful. 

Snowflake has argued that agents need distinct, auditable identities because machine actions can otherwise disappear into human logs. Its current governance approach focuses on attributing actions to the agent that performed them, including the permissions held when an action was requested. 

For Data teams, though, identity is only one piece of the record. Knowing that Agent 27 updated a customer table at 14:03 tells you who changed it. It doesn't necessarily tell you what changed, what the previous value was, why the agent decided to modify it or which person, process or policy ultimately gave it the authority to do so. 

That starts to bring machine actions into the territory of data lineage.

Data lineage needs to account for actions

Lineage traditionally helps organisations understand where data came from and how it moved or changed across systems. A value may begin in a transactional database, pass through a transformation pipeline and eventually appear in an analytics table or dashboard. 

When agents become writers, there may be another question worth preserving alongside that history: why did this data change? An accountable machine write needs a connection between the agent, the authority it was operating under, the data object it touched and the change it made. 

Without that chain, teams may know where a value came from without understanding why it suddenly looks different. That creates a slightly different kind of provenance. Instead of only tracing data through systems, organisations may increasingly need to trace decisions into data changes.

Auditability needs the before and after

There's also a practical difference between logging an action and preserving enough information to investigate its consequences. "Agent updated row 8432" may satisfy a basic activity log. If the update becomes the reason a payment failed three days later, Data and governance teams will probably want something more useful. 

They need to know what the record looked like before the change and what it looked like afterwards. The richer chain starts looking something like this: machine identity, delegated authority, target data object, operation, previous state, new state, relevant context and final outcome. Not every write will justify keeping every possible detail forever. 

Storage, privacy and regulatory requirements still apply. But auditability needs to be designed around the questions people will genuinely have to answer when a machine-generated change produces an unexpected result. And one of those questions will inevitably be whether the change can be undone.

Governed Write Access Needs A Way Back

Giving an agent permission to change something is one decision. Deciding what happens if it changes the wrong thing is another. This is where rollback and recovery start becoming part of the governance conversation. 

Snowflake's agentic security framework explicitly argues that agent actions should be recoverable, while Futurum's current assessment of read-write data platforms also identifies mechanisms for safely handling and reversing machine-generated state changes as part of the emerging architecture. 

That doesn't mean every AI action needs a dramatic emergency restore process. Often, the safest design is much simpler. A system may keep version history. A transaction may be reversible. A high-impact write might go through a staging area before committing to a system of record. 

Certain operations may require an approval step, while others can execute automatically because their effects are easy to contain. The governance principle is more useful than any single implementation: 

The more consequential the authority, the stronger the organisation's ability to identify and reverse an incorrect change should become. 

That puts data resilience much closer to access design. It also helps avoid the unrealistic answer of putting a human approval gate in front of every machine action. IBM's 2026 Tech Leader Study argues that this won't scale as agent deployment grows, particularly when systems may make thousands of decisions per day. 

IBM found that organisations engineering governance directly into AI systems were already deploying substantially more agents than those relying on manual oversight. The better answer is to decide ahead of time where machines can act independently, where the action needs additional controls and where automated authority should stop altogether. 

Which leads to another old governance principle that may need a machine-shaped update.

Some Machine Rights Shouldn’t Travel Together

Separation of duties exists because giving one person complete control over a sensitive process creates unnecessary risk. The employee who submits a large payment, for example, may not also be the person authorised to approve it. There's no reason to abandon that logic simply because the actor is software. 

An agent that identifies records it believes should be deleted doesn't necessarily need permission to perform the deletion itself. A system that recommends changing financial data may be able to prepare the change while a different authority approves the final transaction. The separation becomes even more important as you move further along the authority hierarchy. 

An agent capable of modifying enterprise data probably shouldn't automatically be able to change the schema governing that data. And an agent operating under a particular policy shouldn't normally be able to rewrite the same policy that constrains its behaviour. Otherwise, you're no longer just giving a machine permission to perform a task. 

You're giving it some control over the rules defining its own authority. Snowflake is already exploring a version of this principle through Multi-Party Approval for higher-risk operations, while Databricks' separation between fine-grained DML privileges and broader schema-changing permissions creates a technical boundary between changing data and changing the structure around it. 

For Data leaders, this creates a useful way to rethink separation of duties. The question isn't only which humans need independent approval roles anymore. It may increasingly include which machine capabilities should never live inside the same authority path.

Data Governance Needs To Govern Writers, Not Just Readers

None of this requires organisations to throw away the data governance models they've spent years building. In fact, Informatica's finding that 48 per cent of surveyed data leaders are extending existing governance tools to incorporate AI suggests many enterprises are already moving in the opposite direction. 

They're bringing AI into their existing governance environments rather than treating it as something completely separate. That approach makes sense because the underlying questions are familiar:

• Who or what has authority?
• What is that authority supposed to cover?
• How do we know when it was used?
• What evidence do we retain?
• What happens when something goes wrong?

The difference is that agentic AI data governance increasingly needs to answer those questions for legitimate machine writers as well as human users. For organisations reviewing their existing data governance architecture, a useful diagnostic is:

• Can we distinguish read access from different forms of write authority?
• Can we restrict machine writes by operation, dataset, field, task or context?
• Can we identify which agent changed a record and under whose authority?
• Can we reconstruct the state before and after a consequential machine write?
• Can incorrect changes be contained or reversed without rebuilding the affected dataset?
• Are high-impact rights separated so one machine can't both decide, execute and redefine the rules governing the same action?

None of those questions assumes agents are dangerous by default. They're simply the questions that follow once machines become capable of changing the same enterprise data organisations already govern carefully when humans interact with it. And that may be the real shift ahead for data governance.

Final Thoughts: Data Governance Has To Decide What Machines Can Change

For a long time, one of the hardest questions in enterprise data management was who should be allowed to see what. That question isn't going away. Sensitive data still needs protection, access still needs limits and organisations still need confidence that people and systems only reach the information they're supposed to use. 

But machines that can write create a second question beside it. An AI agent may have every legitimate reason to access a dataset and still need very narrow authority over what it can leave behind. Reading, appending, updating, deleting and changing the rules around data aren't simply different technical commands. 

They're different levels and types of organisational power. As agentic systems move closer to systems of record, enterprise data governance will increasingly need to account for that power directly. Permissions need scope. Changes need provenance. High-impact actions need stronger boundaries, while consequential writes need a practical route back when the result isn't what anyone intended. 

The goal isn't to make autonomous work impossible by wrapping every action in another approval process. It's to give machines enough authority to do useful work without quietly inheriting more control than the task actually requires. That's where the next stage of data governance may be heading. 

Not away from the policies, controls and architecture organisations already use, but towards applying them more deliberately to a new kind of writer. As data platforms continue adapting to machine-driven work, EM360Tech will keep following how those controls evolve and what the shift means for the Data leaders responsible for keeping enterprise information useful, trustworthy and under control.