Your AI Agent Has Access. That Doesn’t Mean It Has Approval.

An engineer argues that AI agents need both permission policies and approval policies, distinguishing between tool access and runtime approval for high-impact actions. The post outlines tiered risk levels, context-rich approval records, expiring approvals, and fallback model policies to ensure safe AI automation.

An AI agent can have valid credentials, a healthy model route, and permission to invoke a tool. It can still need a human to say: not this action, not now. That distinction matters. Many AI products treat tool access as a binary setting: But the risk of an action changes with context. Sending a draft to an internal teammate is different from emailing 10,000 customers. Updating one test record is different from modifying a production account. Reading a document is different from exporting a customer database. The biggest control failure is often not giving an agent too much permission. It is giving it permission without creating a decision point for high-impact actions. A permission policy asks: Is this tool available to this agent or model route? An approval policy asks: Should this exact action happen now, for this target, with these inputs? A production AI agent needs both. A model may be allowed to call a refund tool, but a refund above a certain amount may need review. A model may be allowed to update a CRM, but changing account ownership may require approval. A model may be allowed to deploy, but production deployment should not use the same policy as staging. Tool access is the baseline. Approval is the runtime control. Not every agent action needs a human in the loop. If every tool call creates a confirmation dialog, the product becomes slow and people start approving without reading. Approval gates work best for actions with meaningful impact: The decision should consider more than the tool name. It should consider: An approval request should not say only: The AI agent wants to use refund customer . That gives the reviewer almost no useful information. A better approval record includes the context needed to make a decision: json { "action": "refund customer", "customer id": "acct 4821", "amount": 890, "currency": "USD", "environment": "production", "reason": "Duplicate charge detected by workflow", "risk level": "high", "decision": "require human approval" } The reviewer should be able to answer: What will change? Who will be affected? What evidence led to this recommendation? Can the action be undone? What happens if it is rejected? How long is this approval valid? An approval without context is just another button. Use risk levels instead of one global rule A practical policy is usually tiered. Low-risk actions Allow automatically: retrieve public documentation summarize an internal ticket create a draft response label an item update a non-critical status field Medium-risk actions Require a threshold or lightweight confirmation: send a customer-facing message create a ticket with external visibility modify a limited set of records run a batch job below a volume limit High-risk actions Require explicit approval: production data deletion permission changes financial actions large-scale outbound communication production deployment sensitive-data exports This lets teams preserve the speed of AI automation without treating every action as equally safe. Approval should expire An approval is not permanent permission. A reviewer may approve a specific action for a specific customer, amount, environment, and time window. That approval should not silently authorize the same agent to repeat the action tomorrow against a different target. Useful approval records include: request ID action details policy version model and prompt version approver timestamp expiry time final execution result This matters when an AI workflow is investigated later. Fallbacks need their own approval policy A fallback model is not automatically allowed to perform every action available to the primary route. When a system switches models because of latency, errors, rate limits, or degraded output, it should re-check the action policy. A lower-cost or backup route may still be able to summarize, retrieve, or draft. It may not be the right route to execute a payment, change permissions, or send an external message. The route changed. The risk decision may need to change too. Final thought Production AI agents should not be controlled only by prompts and API keys. They need clear boundaries between: what an agent can access what it can propose what it can execute automatically what requires a human decision Permission gives an agent capability. Approval gives a team control. VectorNode helps teams manage model access, routes, observability, and production controls across global and Chinese frontier AI models from one infrastructure layer. Learn more at https://www.vectronode.com/