Most of the governance conversation in agentic AI stops at two questions: what data can this agent see, and what task is it allowed to run? Those are the right questions to start with. The problem is that people treat them as the finish line.
They're not. Source access and task scope tell you what an agent is permitted to know. They say nothing about what it's permitted to do with that knowledge. Those are different things, and collapsing them together is where real exposure lives in regulated environments.
What source/task gating actually controls
When you configure an agent with source-level gating, you're drawing a boundary around which systems it can query. A lending agent gets access to the loan origination system. A claims agent gets access to the claims database. That boundary is real and it matters — an agent that can't see data it isn't supposed to see can't leak it.
Task gating adds another layer: this agent is scoped to handle balance inquiries, or fraud alerts, or policy renewals. Again, meaningful. An agent that doesn't have a fraud-investigation task in its repertoire shouldn't be running one.
But here is exactly what neither of those controls touches: whether the agent, having been granted access to the loan origination system for read purposes, can also write to it. Whether an agent scoped to handle fraud alerts can also trigger an account freeze as part of resolving one. The action — read, write, delete — is a third axis, and it's invisible to the first two.
The account-freeze problem
Take a concrete scenario. A fraud-detection agent is legitimately scoped: it has read access to transaction history, and its task is to surface suspicious patterns for review. That's a reasonable configuration. The agent is doing exactly what it was set up to do.
Now the agent surfaces a pattern that looks like account takeover. Its next tool call — because the harness wired it that way, or because a prompt somewhere described the full remediation workflow — is to freeze the account.
That write action is consequential in a way the read wasn't. Freezing an account affects a real customer. It may trigger regulatory notification obligations. It may need to be logged against a specific compliance workflow, countersigned, or deferred to a human. The source access was correct. The task was in scope. The action was not governed at all.
Source gating answers: can this agent reach the system? Task gating answers: is this use case permitted? Neither answers: is this specific action — freeze, update, delete — authorized for this agent, on this record, at this moment?
The same logic applies to credit decisions. An underwriting agent with read access to an applicant's credit file and a task scope of "evaluate loan eligibility" can, if nothing stops it, write a decision back to the origination system. The read was governed. The decision write — which carries fair lending exposure, adverse action requirements, and model governance obligations — was not.
Why this gap exists
Harnesses are built around capability, not consequence. The design question when wiring a tool to an agent is "can this agent use this tool to do its job?" It's rarely "should this specific action type — write, delete — require a separate authorization check that the tool call itself doesn't provide?"
The result is that action type ends up implicit. The tool exists, the agent has access to it, so the action is available. That's fine in low-stakes environments. In regulated ones, it's a gap that doesn't show up until an audit — or until a customer calls to ask why their account is frozen.
Action vocabulary as a governance primitive
What we built in AutoPIL's Action Vocabulary work is a way to make action type explicit — a first-class dimension of the policy, not something inferred from tool availability.
The vocabulary is intentionally simple: read, write, delete. Read covers any operation that retrieves data without modifying state. Write covers any operation that creates or modifies a record. Delete covers any operation that removes one. Every tool call an agent makes gets classified against this vocabulary before it executes.
That classification is then evaluated against the policy for that agent, in that context, against that resource. An agent can be permitted to read from the loan origination system and explicitly denied write access to it — even if the tool it's calling technically supports both. An account-freeze action requires a write gate that's separate from the read gate that let the agent see the suspicious transaction in the first place.
Policy in AutoPIL binds three things together: the resource (which system or data type), the principal (which agent or role), and the action type (read, write, or delete). All three have to be authorized for the call to proceed. Source access alone is not authorization to write.
What this changes for regulated use cases
For financial services, it means an agent can be given read access to customer account data for a specific task — say, identifying candidates for a pre-approval offer — without inheriting any write capability against those accounts. The read and the write are separately authorized, separately logged, and can be separately revoked.
For credit decisions specifically, it means the action of writing a decision back to the origination system is a distinct policy event. You can require that write to pass through a human review step, or require it to be logged against a specific model governance record, without changing anything about how the agent reads data upstream.
For account-level actions like freezes or closures, it means those writes can be scoped to specific agent roles — a fraud remediation agent — and denied to agents that only needed read access to surface the original alert. The agent that found the problem and the agent authorized to act on it don't have to be the same agent, and now the policy can enforce that distinction cleanly.
The audit trail changes too
When action type is a first-class dimension of policy, it shows up in the audit trail that way. Every write that AutoPIL permits or denies is logged with the action type, the resource, the agent, and the policy that resolved the decision. That's a materially different artifact than a log of tool calls.
A regulator asking "how did this account freeze happen, and was it authorized?" gets a policy decision record that shows the agent's write action was evaluated against an explicit write-gate policy, not just inferred from tool availability. That's a defensible answer. "The agent had access to the tool" is not.
Anil Solleti is the founder of AutoPIL, a governance-first agentic AI platform for regulated enterprises, and a partner at VibrantCapital.ai.