Permissions Must Live Where the Data Lives: Agent Governance in HR and Finance

Ask a finance leader what is keeping agents out of their close process, and the answer will not be the model. It will be a question they cannot answer cleanly: when this agent touches the general ledger, whose permissions is it using, and where does the proof of that live? In a regulated function, “we think it stayed in scope” is not a sentence anyone signs their name to. The blocker is not intelligence. It is authority.

That is the argument running through a recent VentureBeat report on enterprise agent adoption. The bottleneck stalling agents in HR and finance is not model performance. It is permissioning. And the teams getting unblocked are the ones who stopped treating permissions as a layer they bolt on after the agent works, and started treating the system of record itself as the place where authority and audit already live.

We have made the agent-identity argument before, in the engineering context, where it is about service accounts and least-privilege roles. This is the same problem walking into a different building. Payroll and the books do not tolerate the failure modes that a staging database does.

Almost Right Is a Different Word in Payroll

Most discussion of agent reliability uses a forgiving vocabulary. The model is “mostly accurate.” The output is “good enough to review.” That language collapses the moment you move into a function where the unit of error is a person’s paycheck.

Workday, quoted in the VentureBeat report, puts it plainly: “Almost right is not acceptable. Think about paying people correctly, closing the books.” A summarization agent that is 95% accurate is a useful assistant. A payroll agent that is 95% accurate has paid one in twenty people the wrong amount, and you will hear about all of them. The asymmetry is the point. In HR and finance, the cost of a wrong action is not a bad draft you discard. It is a regulatory event, a grievance, a restatement.

This is why permissioning, not accuracy, is the real wall. You cannot make a payroll agent trustworthy by making the model smarter. You make it trustworthy by guaranteeing it can never act outside the authority of the human who invoked it, and by being able to prove, after the fact, exactly what it did and on whose behalf. Smarter models do not give you that guarantee. Architecture does.

The Failure Mode: Permissions Bolted On

Here is the pattern that breaks. A team builds an agent, gives it broad API access so it can be useful, and then tries to constrain that access afterward with a separate policy layer, a wrapper, a list of rules maintained somewhere outside the application that actually owns the data. The agent now has two sources of truth about what it is allowed to do: the real permissions inside the system of record, and the shadow permissions in the wrapper. The two drift. They always drift.

Dan Obendorfer of Würk names the consequence directly in the report: “If your permissions are defined somewhere outside of where the data actually lives, you’ve already lost.” The loss is not hypothetical. When a person changes roles, their access in the HR system updates. The agent wrapper does not know that happened until someone remembers to sync it. For a window of days or weeks, the agent is acting on stale authority. In a regulated function, that window is an audit finding waiting to be written.

A bolt-on permission layer is a copy of the truth. Copies go stale. The only permission model that cannot drift is the one that is not a copy.

The Durable Pattern: System of Record as Governance Layer

The architecture that holds is the one where the agent has no permissions of its own. It inherits them, live, from the system that already manages identity and access for the data in question.

The VentureBeat report describes Workday’s Sana as one implementation of this idea, and the shape is worth studying even if you never touch that specific product. The system of record becomes the agent’s permission and identity layer. The agent acts only within an authenticated user’s existing permissions. If the user cannot see a salary band, the agent invoked by that user cannot see it either. There is no second list to maintain, because there is no second list. Authority comes from one place.

The audit story follows the same logic. In this model, the audit trail stays inside the system of record, where the data lives and where compliance teams already look. The agent surface, in this case exposed through Gemini Enterprise per the report, keeps only interaction logs: what was asked, what was returned. It does not hold the authoritative record of who was allowed to do what. That stays in Workday. The orchestration layer is where you converse with the agent. The system of record is where governance is enforced and proven.

Treat Sana as one example of the pattern, not as the pattern itself. The durable idea, the one that will outlast any single vendor’s product cycle, is the principle underneath it: permissions and audit belong to the system that owns the data, and an agent is a way of acting through that system, never around it.

What This Changes for How You Buy and Build

If the system of record is the governance layer, two things follow that most agent procurement conversations get backwards.

First, the agent platform is not where you evaluate governance. You evaluate governance at the system of record. The right question to ask a vendor is not “what guardrails does your agent have.” It is “does your agent inherit permissions from our existing system of record, live, or does it maintain its own copy.” If the answer is the second one, you are buying a drift problem with a chatbot attached.

Second, the integration that matters is the boring one. Connecting an agent to a slick orchestration surface is easy and demos well. Wiring it so that every action runs inside an authenticated user’s real permissions, and so that audit lands in the system compliance already trusts, is the hard part and the entire point. The demo is the orchestration. The product is the inheritance.

Do This Now

Pick one function where you want agents and cannot yet deploy them, HR or finance, the place where “almost right” is unacceptable. Then run one diagnostic conversation with whoever owns that system.

Ask three questions. Where would an agent’s permissions come from: the system of record, live, or a separate policy layer we maintain? When a person’s access changes in the source system, how long until the agent reflects that, and is that lag acceptable for this function? Where would the audit trail of an agent’s actions live, and is it the same place our compliance team already audits today?

If any answer points to a copy, a wrapper, or a second list, you have found your real blocker, and it was never the model. Fix the authority architecture before you tune another prompt. Governance that is embedded cannot drift. Governance that is bolted on already has.

This analysis synthesizes The AI agent bottleneck isn’t model performance, it’s permissions (VentureBeat, May 2026).

Victorino Group helps HR and finance teams put agent permissions where the data already lives. Let’s talk.