AI agent governance: a buyer's guide to authority and approvals

Autonomy is something you grant per agent; a person stays accountable for what it does. So the first thing an AI agent governance platform has to show you is who granted what: which agent owns the work, what it’s allowed to do, what waits for a person and what record is left afterward.

If you lead a team running several agents, the buying test is simple to say and hard to pass. Pick one consequential action, such as sending a report or deploying a change, and ask the vendor to show who allowed it, what made it wait and which paths it could take around that control.

Start with the authority you’re granting

Choose one job your agents already do. Write down three names: the person accountable for the result, the agent doing the work and the decision that has to stay with a person.

Then split the job into its grants. Preparing an output, accepting it and acting on it are three different permissions. A report can pass review without anyone allowing it to be sent. A repository connection can let an agent read code without letting it deploy. Name the action you need controlled before you look at anyone’s approval screen.

Six questions to take into every trial:

1. Owner: after the session ends, can a teammate see who owns the task and what it was for?
2. Access: who can grant or revoke the agent’s tools, accounts and data?
3. Spend: which limit applies, and what happens to work already running when the limit is hit?
4. Approval: what exactly waits, for whom, and what happens after a rejection or a changed request?
5. Execution: where does the work run, and what happens to it when someone steps in?
6. Record: can someone with access connect the request, the decision, the result and the cost?

Four boundaries to keep apart

These four are easy to blur into one control, so test each on its own.

Role and ownership say who is responsible for the job and where an agent reports. Paperclip’s org chart shows reporting lines next to assigned work. A title doesn’t give an agent access to anything.

Task review and approval decide whether finished work can close. A reviewer can be an agent or a person, so if a human has to sign off, check that the approver really is a human.

Tool-call permission decides whether one specific action, through a connected tool, can run. An approved report doesn’t grant it.

Credentials and runtime reach set what the underlying account and the machine running the agent can do. Provider permissions are their own limit, and shell commands can take a different path from connected tools. A control on one path says nothing about the others.

Ask what the control actually stops

For each consequential action, fill in this worksheet in every product you trial. Ask to see the result, not just the feature name.

Where the approval sits matters as much as whether it exists. A notice after the action can’t stop it. A check-in the agent chooses to make depends on the agent. A gate only works if it sits at the point where the action would otherwise run.

Task review and human sign-off

In Paperclip, Reviewers and Approvers are optional settings on a task. You add them from the task’s Properties after it’s created, and each one can be an agent or a person. The execution policy catches an agent’s attempt to mark the work done and sends it to review first. If the reviewer asks for changes, the task goes back to the agent that did it.

That’s a gate on finishing the task. It doesn’t approve every command or API call made during the work. In a trial, ask to see the reviewers set, an attempt to finish, a request for changes and the task state afterward. A screenshot of the reviewer picker isn’t proof the flow works.

Tool actions and consent

For tools connected through Paperclip, each action is Allowed, Ask first or Off. Allowed runs without asking, Ask first waits for a person, and Off denies it. New active actions start as Allowed, including writes and destructive ones, so narrow the policy on purpose. The action permissions guide has the details.

When a call waits for review, connector review requests give you two ways to say yes:

• Allow once approves that stored call and nothing else.
• Always allow also lets the same agent use the same action on that connection with different arguments, within the current project when there is one. It’s only offered for eligible requests.

Decline rejects the call without running it. Approving runs the stored call with its saved arguments, but that isn’t proof the provider accepted it, so check the result. Revoking a trust rule removes that allowance, and future calls are checked against the remaining policies. It doesn’t undo what already happened.

Access and the paths around it

Ask separately who can change policy and which credentials the agent can reach. In Paperclip, human roles and explicit permission grants are separate from the agent reporting tree, and explicit grants can outlast a role change. Changing someone’s role isn’t proof their access is gone.

An Allowed tool can’t do more than its provider credential allows. The reverse also holds: a credential with broad rights may still be usable through a path the tool gateway doesn’t watch. Ask first on a connected tool doesn’t cover workspace shell commands. Shell git and gh with a bound GitHub identity are a documented example. Ask for a demo of the route your agent will actually take.

Costs, records and stepping in

Make spending part of the trial. Ask which limit applies, how running work is counted and what stepping in does to work already in progress.

Paperclip’s budget docs are upfront about the edges. Running work can add spend before it stops, some providers report usage only at the end, and unpriced or pending usage affects budget decisions. A displayed total can be known spend rather than the full bill. A subscription-backed run that reports $0 still costs the subscription.

For records, the Activity API gives company members a basic feed with sensitive attribution removed. Full attribution, its filters and CSV export need the audit:view_agent_actions permission, so check who on your team holds it. An export is capped at 10,000 rows and logs an audit.exported event. Its columns include agent, run and responsible-user IDs, but they don’t add up to one joined record of the output, the cost, the approval and every runtime action. Ask someone with access to export a short period and list what else they’d have to pull together.

Work through one decision before you commit

For example, let’s say you are a team lead trying to get a recurring report written and reviewed, but you don’t want approving the report to quietly allow the agent to send it.

Fill in these slots before the trial:

• [report]: what it must contain and how you’ll judge it.
• [agent]: who prepares it.
• [reviewer]: the agent or person who checks it.
• [approver]: the person who accepts it.
• [later action]: what happens after acceptance, such as sending it to a client.
• [connection]: the account and tool the later action uses.
• [provider rights]: what that account can do upstream.

Ask the vendor to run it with those decisions kept apart. First, check the task review. Then check whether the later action needs its own consent on the path it will really take. Ask for a rejection and a changed request too, not just the happy path.

Write down what stayed blocked, what the change needed and which evidence backs each answer. Keep credentials and private report contents out of any shared demo. What you want at the end is a clear answer about authority, not just a finished report.

Keep, adopt or build

Keep what you have if you can still see owners, check costs and review the actions that matter. A shared task list may be enough for now.

Adopt a control plane when those jobs repeat across several agents and people. Paperclip’s fit is the org chart for agents: roles, assigned work, budgets, configured review and a human who answers for the result. Judge it on the boundaries you need. It doesn’t intercept every runtime action.

Build or extend when you need controls no available path gives you, and you have an engineer to own them. Count access changes, upgrades, recovery and record-keeping in the estimate.

Keep the filled-in worksheet. It shows which jobs a tool covers and which still need a person or another control.

Questions to settle in the trial

Does approving a report authorize a tool action?

No. Task review covers finishing the work. An outside tool call needs its own permission and provider access. If the job needs both, set up both.

Does Ask first cover shell commands?

Ask first on a connected tool covers calls through Paperclip’s tool gateway, not workspace shell commands. Check the runtime and credential limits separately.

Is a run trace all the evidence I need?

A trace helps explain what ran. It doesn’t show on its own who granted authority, which policy applied or which action waited. Look at the decision and result records too.

Take one real job into the trial. Use the assign-and-review guide to check task review, then test the later action’s path before you grant it.