Who signs off on an AI agent going to production?

Three separate approvals, held by three different owners, and most organizations run only the first. Model or use-case approval belongs to the business system owner, accountable for purpose and outcome. Deployment approval belongs to security and, where personal data is involved, privacy or legal. Permission scope approval, which determines what the agent can reach and act on, belongs to the owner of each connected system. The third is the one that gets skipped.

The reason it gets skipped is structural. Permission scope is set in a configuration file by an engineer during implementation, days or weeks after the approval meeting, and it never returns to a review. A committee approves an agent to help with support tickets. An engineer grants it write access to the CRM because the ticket workflow needed it. Both actions are defensible. Neither party knows about the other.

Fix it by making permission scope an approval artifact rather than an implementation detail. The agent's tool list, credential scopes, connected MCP servers, and writable downstream systems go into the approval package, and any expansion after go-live triggers re-approval.

Assign a single accountable owner rather than a committee, because committees approve and nobody owns the drift. Security advises, privacy and legal assess, the business owner accepts the risk.

Add a scheduled re-review tied to model version changes, since the system that was approved is not the system running after a provider updates the underlying model.

Akto Argus monitors the runtime permission surface of agentic applications, which is what makes scope drift visible between approvals rather than at the next audit.

Approve the blast radius, not the use case.