Earning AI Agent Autonomy: Approvals First, Then Loosen

Short answer: roll out an AI agent the way you onboard a new hire. Start with every consequential action routed to a person for approval, record everything, and widen the agent’s autonomy only where the audit trail shows it is safe. The usual order is the reverse: broad access first, restrictions after something breaks.

A typical story. A team wires an agent to an MCP server with a long-lived API key because it is the fastest way to a demo. The demo works, so the key stays. Three months later the agent is writing to production systems, nobody remembers which actions it is allowed to take, and the first sign of trouble is a customer asking why they received six identical emails. We covered that failure mode in idempotency and duplicate agentic actions. The root cause is not the agent. It is that autonomy was granted up front instead of earned.

Why “tighten after the incident” fails

Access that starts wide almost never gets narrower. Everyone has built workflows on top of it, and removing a permission now breaks something. We described the same pattern in AI agent permission creep: permissions behave like a ratchet and only turn one way.

There is also an evidence problem. If the agent has run with unrestricted access, you have no baseline of what normal looks like. You cannot tell which of its thousand daily calls are routine and which are the one you should worry about.

The staged rollout

Think of three stages. Each one changes what the policy allows, not what the agent is.

Stage 1: observe and approve. Give the agent a credential reference, not a raw secret. Reads are allowed. Anything that writes, sends, deletes or moves money requires a human decision. At this stage the approval queue is the product: it is how you learn what the agent actually tries to do, as opposed to what you assumed it would do.

Stage 2: tune from evidence. After a few weeks, read the audit trail. Which approvals were granted every time, with the same shape of arguments? Those are candidates to automate. Which were rejected? Those are candidates for a hard deny. Which tools did the agent call that you never expected? That is your shadow behavior, and it is the finding that justifies the whole exercise.

Stage 3: automate the boring, keep the sharp edges. Move the repeatedly approved, low-risk patterns to allow. Keep approval on the high-impact ones, and add hard denies for the actions that should never happen, such as destructive SQL. Add behavior limits, such as calls per minute, errors per hour or distinct tools per day, so an agent that trips a threshold is escalated to a person even if each individual call looks fine.

The point is that “allow” becomes a decision backed by data. Each relaxation of policy can be traced to a set of past approvals that justified it.

What this needs from your infrastructure

Staged autonomy only works if three things are true.

1. The agent cannot go around the gate. If the agent holds the real API key, a policy is a suggestion. The call has to pass through something that holds the credential, evaluates policy and then makes the request, which is the idea behind decision tokens for credential dispensing.
2. Every call is attributable. You need the agent identity, the human or workspace it acts for, the decision and the outcome. Without that, stage 2 is guesswork. See auditing every agent API call and multi-agent trace propagation for what a useful record contains.
3. Approvals stay meaningful. If reviewers see hundreds of near-identical prompts they stop reading them. Approval fatigue is the reason stage 2 exists: automating the repetitive approvals is what keeps the remaining ones credible.

This applies across protocols. Whether the agent reaches a tool over MCP or hands work to another agent over A2A, the login handshake establishes who is calling. It does not say how much to trust them yet. Policy and the audit trail carry that part.

Failure modes to watch for

• Fail-open policy. A policy that cannot be parsed should not mean “allow everything”. Test your guardrails deliberately, as described in fail-open policies and how to test them.
• Loosening on thin evidence. Ten approvals is not a pattern. Set a minimum volume and age before a rule is automated.
• No way back. Every stage should have an exit. Keep a working kill switch and the ability to revoke an agent’s access at once.
• Treating the agent as the unit of trust. Trust is per action and per context. An agent that is safe to read invoices is not automatically safe to send them.

The business case

A staged rollout is easier to defend than a big-bang one. Security teams get a record of what the agent did and a clear rule for when it gets more freedom. Compliance teams get evidence for SOC 2 style controls and for the oversight expectations in ISO 42001. Product teams get to ship the agent sooner, because “starts with approvals” is an easier yes than “has production access”.

Fullmakt is built for this sequence:

• Credentials by reference. Agents never hold the secret. Fullmakt resolves it at call time and scrubs resolved credential values from captured output.
• Policy on every call. Hard denies, approval rules and behavioral limits are evaluated per request, across the protocols it brokers, including HTTP and MCP.
• Human approvals. Calls that need a decision are held until a person approves or rejects them, and the decision is logged.
• One audit trail. Agent, delegating user, decision, outcome and who resolved each approval, in one place (sensitive fields are kept out of stored arguments), which is the evidence you use to loosen policy with confidence.

FAQ

How long should an agent stay in the approval stage?

Until you have enough volume to see patterns, usually a few weeks of real traffic rather than a fixed date. Move on a rule by rule basis, not agent by agent.

Which actions should never be automated?

Anything irreversible or high-value that you cannot cheaply undo: deleting data, moving money, changing permissions, sending external messages in bulk. Keep these behind approval or a hard deny.

Does approval-first slow the project down?

It slows the first weeks and speeds up everything after. The alternative is usually a rollback or an incident review that stalls the whole programme.

Can I use this with any agent framework?

Yes. The gate sits between the agent and the systems it calls, so it does not depend on the framework, only on the agent calling tools through it.

How is this different from giving the agent a scoped token?

A scoped token limits which APIs are reachable. It does not evaluate the arguments of each call, ask a person, or give you the trail you need to widen scope safely. See scoped credentials for AI agents.

See how Fullmakt brokers credentials for AI agents or browse the Fullmakt blog.