AI Governance Series Part 3/5

• Read Part 1: AI Didn’t Solve a Problem. It Created an Opportunity.
• Read Part 2: The Case for Observing AI Data Access

The Problem With Policy at the Edge 

Most enterprises enforce data policy at the application layer. Access rules live in the application. Masking logic lives in the application. The assumption is that the application is the gatekeeper, and anything that goes through it is controlled. 

That assumption breaks the moment data moves. And in an agentic environment, data moves constantly across pipelines, between systems, and through agents operating across multiple data sources simultaneously. If your policy only lives in the application, it disappears the moment the data doesn’t. Your agent isn’t going to even have the opportunity to respect your PowerBI policies because it doesn’t even know about them. 

Pillar Two of ALTR’s agentic data governance framework establishes a different principle: bring policy to the data. Apply controls at the point of egress, the moment data leaves a system’s control, not somewhere downstream where you’ve already lost the thread. 

Three Types of Policy, One Consistent Framework 

ALTR recognizes three types of data policy that every enterprise needs in place for agentic environments. Together, they cover the full spectrum from hard stops to sophisticated data transformation. 

Access Control 

The simplest form: the agent asks for data, and the answer is no. The agent receives an empty result set or an access-denied response. This is the baseline; a hard stop for data the agent has no business seeing. 

An HR agent has no reason to query compensation data outside its defined scope. A customer service agent has no reason to pull financial account details. Access control is the firewall, and it has to be enforced at the source, not hoped for at the application. 

Data Masking 

Sometimes agents need partial data to do their job. A fraud detection agent might need to verify the last four digits of an account number without seeing the full record. A customer analytics model might need demographic signals without personally identifiable details. 

Data masking provides just enough; structured data with the sensitive elements obscured. The agent gets something usable. The sensitive information stays protected. The policy is applied dynamically, at the point of query, without requiring developers to bake logic into every downstream system. 

The classic example: a Social Security number comes back as ***-**-9696. The agent can confirm a match. It can’t expose the record. 

Protection (Format-Preserving Encryption) 

The most sophisticated tier. Here, the agent receives data that looks and feels structurally correct, for example an email address format, or a phone number pattern, but the actual values are tokenized. The data is plausible enough to be useful in statistical models or analytical workflows, but it can’t be reverse-engineered into real customer information. 

A real email like [email protected] becomes something like [email protected]. The format is preserved. The referential integrity holds for modeling purposes. But the underlying identity is protected. 

There’s a meaningful bonus consideration here: if you can surface to the agent the fact that it’s operating on protected data, that what it’s looking at is a tokenized representation, not the real thing, the agent can factor that into its reasoning and responses. That transparency is increasingly achievable through MCP (Model Context Protocol) integrations, and it’s the direction agentic governance is heading. 

Continuous Evaluation, Not One-Time Configuration 

Policy isn’t a one-time setup exercise. Data access patterns change. Business units gain access to new systems. Agents are provisioned with broader permissions than their role actually requires. New data sources come online. 

Effective governance requires that policy be evaluated continuously, not just at onboarding, but at every point where access conditions change. If a new agent is provisioned with entitlements that exceed its defined scope, policy should catch that at runtime. If a user’s role changes, their data access profile should update accordingly and automatically. 

The moment policy becomes a set-it-and-forget-it exercise, it stops being governance. It becomes a false sense of security, one that looks fine in an audit until it isn’t. 

In Part 4, we’ll look at Pillar Three: maintaining the chain of identity and why every agentic action needs to trace back to a human being, and what happens when it doesn’t.