How to Govern AI Agents: Access, Audit, and Compliance

Your governance model was built for two kinds of actor: humans, who are slow, accountable, and have a manager; and service accounts, which are fast but deterministic and do exactly one narrow thing. An AI agent is neither. It's fast like a service account and open-ended like a human, with the accountability of neither. It can take a thousand consequential actions an hour, each one a judgment call, and when you ask why, the honest answer is sometimes "the model decided." That combination is what breaks the old playbook, and it's what this post is actually about.

Most "AI governance" writing stops at the policy-document layer — a committee, a set of principles, an acceptable-use page. That has its place, but it doesn't govern anything. Governance that holds in production is three concrete control problems, each one made harder by the agent's nature: who the agent is allowed to be (access), what the agent actually did (audit), and how you prove both to someone who didn't trust you (compliance). This is written for the architect who has to wire those controls, with enough framing that the people signing the risk acceptance know what they signed.

Give the agent an identity, not a borrowed one

The first governance decision is the one teams make by accident: under whose identity does the agent act? The lazy default is a service account with broad rights, because it's the fastest path to a working demo. It's also the single worst governance choice you can make, and it poisons everything downstream.

An agent running as a god-mode service account has two failures baked in. First, access: it can reach every record in the system, so the only thing standing between a customer and another customer's data is the model's good behavior on a bad day — a prompt, not a boundary. Second, audit: every action it takes is logged as that one service account, so when something goes wrong you can see that "the integration user" did it, but not which agent, which session, or on whose behalf. You've blinded both controls at once.

The fix is to treat the agent as a first-class principal. It gets its own identity, its own scoped permissions, and — critically — it acts on behalf of a specific user or context, inheriting that user's access rather than transcending it. This is the difference between "the agent can see what it should" and "the agent can see everything and we hope it won't." On Salesforce this is concrete rather than aspirational: an Agentforce agent grounded on Data Cloud runs inside the platform's sharing and permission model, so it literally cannot retrieve a record the asking user has no right to. The boundary is enforced by the system, not requested in a paragraph.

“

The cleanest access control for an agent is the same one you'd want for a new employee: it can only ever see what the person it's acting for could see. Anything broader than that isn't a capability — it's a liability you haven't been billed for yet.

Least privilege is a moving target, not a one-time grant

For a human, least privilege is mostly a setup problem — provision the right roles on day one and review them quarterly. For an agent it's a continuous one, because an agent's privileges are really the union of two things: what it can read (its grounding scope) and what it can do (its tools). Both expand over time as you add capabilities, and each addition is a privilege grant that usually gets no review at all.

The discipline that matters here is separating those two surfaces and governing them differently. Read access should be scoped by the identity model above. Action access — the tools — should be governed at the tool, not the prompt, because that's the layer a user can't argue the model out of.

• Enumerate every tool as a privilege. A tool that can issue a refund, send an email, or update a record is a grant of authority. Maintain the list the way you'd maintain a list of admin permissions, because that's what it is.
• Put the hard limits in the tool, not the instructions. "Never refund over $500" belongs in the refund tool's logic and required arguments, where a jailbreak hits a wall, not in a sentence the model can be talked past.
• Require a human gate for the irreversible and the expensive. Some actions should never be fully autonomous. Encode the threshold — dollar amount, data sensitivity, customer tier — as an approval step the agent cannot skip.
• Re-review on every capability you add. The agent that was safe with three tools is a different risk surface with eight. New tool, new review — the same way you'd re-review a role that suddenly got write access to payroll.

Audit means reconstructing a decision, not logging a request

Here's the part that separates real agent governance from a checkbox. Traditional audit logs answer "who did what, when." For an agent that's necessary and badly insufficient, because the interesting question is almost never what it did — it's why. When an agent issues a wrong refund, "agent X called the refund tool at 14:32" tells you nothing you can act on. You need to reconstruct the decision.

Reconstructing a decision means capturing the whole turn as one linked record: the input it received, what it retrieved and from where, which model version was behind the wheel, the reasoning or tool-selection it produced, the exact tool calls with their arguments, and the final output. If you can't replay why the agent did something, you can't govern it — you can only react to it. That trace is simultaneously your debugging tool, your audit evidence, and your eval input. It is the most load-bearing artifact in the entire system, and it's the one most teams discover they didn't capture only after the incident that needed it.

Two non-obvious requirements fall out of this. Pin the model version in every trace, so when a provider bumps the model underneath you, your audit shows behavior changing on a date you can name instead of a mystery in next quarter's complaint volume. And make the trace immutable and queryable — an audit log you can't search under deadline, or that the system could have overwritten, is not an audit log. It's a folder.

Compliance is proving the boundary to someone who didn't trust you

Access and audit are controls you build for yourself. Compliance is the same controls, but provable to a regulator, an auditor, or a customer's security team who starts from the assumption that you're wrong. The bar is higher, and the agent's nature raises it further: a non-deterministic actor is exactly the thing a control framework is least comfortable with.

The useful move is to map agent behavior onto the data-protection questions an auditor already asks, instead of inventing a new vocabulary. They will ask, in some dialect: what personal data can this thing access, on what lawful basis, who can it disclose that data to, can you show it didn't exceed those limits, and can a person contest a decision it made about them. Notice that every one of those resolves back to access and audit. If your access model is enforced by the platform and your audit trail can reconstruct any decision, you can answer all five with evidence rather than assurances.

• Data residency and scope. Be able to state exactly which data the agent can ground on and where that data lives — not "the CRM," but the specific objects and the region.
• Purpose limitation. The agent should be constrained to the job it was authorized for. An open-ended agent that can wander into any workflow is hard to attest to and harder to defend.
• Right to explanation. For decisions that affect a person — a denied application, a routing, a price — you need to produce the reasoning behind that specific decision. That's the decision trace, surfaced.
• Human accountability. Every autonomous action needs a named human or team who owns its outcomes. "The model decided" is not an answer any regulator accepts, and it shouldn't be one you accept either.

The pattern worth internalizing: good compliance is mostly good access and audit, made legible. You rarely need a separate compliance system. You need the access boundary to be real and the audit trail to be complete, then the work is exposing them in the shape an auditor recognizes. For the person signing the risk acceptance, the way to size all of this is in business terms: take the worst single action your agent can take, multiply by how often it runs, and ask what's standing in the way. A refund limit that lives in the prompt instead of the tool is an open question about how much money one jailbroken conversation can move; a broad-identity agent that crosses customers once is a breach-notification event regardless of how rarely it fires. If a paragraph of instructions is the only thing between you and that number, the control belongs in the system, not the prompt.

Governance is a runtime property, not a launch gate

The deepest mistake in this whole topic is treating governance as something you certify once, at launch, and then file away. An agent is a living system: the model updates, the data shifts, you add tools, the world moves. Every one of those changes can quietly invalidate a control you signed off on months ago. The permission scope that was correct in March includes a new object by June. The eight-tool agent passed a review the three-tool agent never re-took.

So governance has to run continuously, with the same instruments doing double duty. The decision traces that serve audit also feed the evals that catch the agent drifting out of policy. The tool-permission review that serves least privilege is also the change-management gate. The agent you governed at launch and the agent running today are not the same system, and only one of them is the one your customers are talking to. A control you set and stopped watching is a control you no longer have.

This is exactly why running an agent is a different discipline than building one — and why we treat it that way. In our Data-to-Agent method, the access model is set in Agent Ready, but the audit, the eval-backed policy checks, and the ongoing privilege reviews live in Agent Care, as a named operating responsibility rather than a launch checkbox. We build and run agents and stay accountable for how they behave over time, because governance that isn't owned by someone after launch is just documentation that was true once.

If you take one thing from this: stop thinking of agent governance as a policy and start thinking of it as three wired controls — a scoped identity, a complete decision trace, and a continuous review — each chosen because the agent is fast, open-ended, and opaque in ways your old model never had to handle. Get those three right and the policy document writes itself. Get them wrong and the policy document is the only governance you have.