The article proposes a new permission model for AI agents where approvals include specific scope, expiry, replay rules, and audit tracking to ensure actions remain valid within a defined timeframe.
An agent gets approval to deploy a staging change. It reaches the deploy API, gets a timeout, and resumes thirty minutes later. The earlier approval and plan are still available. In that gap, the artifact, target environment, or rollout window may have changed. For consequential actions, an approval should describe the action that was approved, rather than becoming a standing permission. A practical grant can bind a specific action and resource, the relevant arguments, an expiry, a replay rule, and an audit record. At execution time, the question is more specific than "was this approved?" It is "does this approval still cover this call against this resource with these parameters?" Four checks make that concrete: Scope: Record the exact tool operation and resource. deploy is too broad if the target is a particular service and environment. Expiry: Set when the grant stops applying. A short window can cover a deploy confirmation without surviving the rest of a long-running run. Replay protection: Decide whether the same approval can authorize a second attempt, a changed argument, or a different resource. That should be an explicit choice. Audit record: Preserve what was approved, for which resource, when, and what actually executed. A run ID and an approval record give you somewhere to start when the answer is disputed. Retries are the awkward part. The agent may have created a release but not reached the deploy API. Or it may get an ambiguous response after issuing a database migration, a force-push, a destructive write, or a production configuration change. Retrying could be correct, could duplicate the side effect, or could need a fresh approval because the original grant expired or surrounding state changed. There is no universal retry rule. The workflow needs an explicit state for "unknown outcome," plus an explicit decision to inspect state, retry, request a new approval, or stop. Quietly treating an old grant as authority for the next attempt hides the decision that matters. At Future AGI, the gateway applies policy to each MCP tool call and its arguments, which gives us a place to keep a grant tied to the action that was approved. “How are you handling retries after an approval has expired, especially for deploy, migration, or force-push actions?”
The article discusses the principle that AI agents should not self-authorize actions and explores where to draw the line in allowing models to make decisions independently, emphasizing external controls like approval systems and policies.
A discussion thread seeking input on how to handle authority and permissions for AI agents that take real actions, including audit trails and scope of permissions.
The article outlines a framework of key questions and controls for AI agent permissions to ensure safe and accountable operations before making changes.
The article asks how engineers manage permissions for AI agents in production, highlighting common problems with broad access and lack of audit trails.
The article discusses whether request metadata for AI agents should be visible alongside existing agent permissions, highlighting trade-offs between transparency and user control.