AI agents cross a line that ordinary chat systems do not: they connect probabilistic decisions to real actions.
An agent that can read mail, update a record, run a tool, or spend money is part of your production control plane. Prompt quality matters, but prompts are not a security boundary. The controls below should exist before an agent receives production access.
Do not treat "access" as a single permission.
Use three distinct stages: This split gives you useful checkpoints. A support agent may read a ticket and draft an answer automatically, while sending remains gated. A finance agent may analyze invoices but require an approval before changing payment details.
A single broad credential turns every mistake into a high-impact mistake. Prefer separate credentials and scopes for separate tools.
Ask four questions for each tool:
Short-lived credentials and environment-specific roles reduce the damage from a bad decision, a leaked token, or a malicious instruction hidden in external content.
Agents need more than an API rate limit. They need a business-action budget.
Useful limits include:
The budget should fail closed. Crossing it should stop the run and request review, not trigger an improvised workaround.
Approval works only when the reviewer can see the exact action that will occur.
For a message, show the final recipient and wording together. For a deployment, show the target environment and revision. For a purchase, show the item, delivery address, and full total. Avoid vague approvals such as "continue" when several actions are still possible. The approval object should be concrete enough to log and later audit.
Email, webpages, documents, issue comments, and retrieved knowledge can all contain instructions that conflict with the agent's actual task.
Do not let retrieved content redefine the agent's goals, choose new tools, expand permissions, or select a new disclosure destination. Parse it as data. Keep authority in a separate, trusted control path.
Test whole workflows rather than individual prompts. A sequence of individually allowed actions can still produce a harmful result.
A useful audit trail answers two different questions:
Record the task identifier, tool, target, approval reference, before/after state, and provider response. Keep logs outside the agent's own write permissions when possible.
Observability should also include alerts for unusual tool combinations, repeated failures, sudden increases in volume, and actions outside normal hours.
A stop button is not a prompt that says "please stop." It is an independent control that can revoke credentials, disable tool execution, or block the workflow runner.
Define who can activate it, what it disables, and how recovery works. Practice using it before launch.
Before giving an agent live access, run at least these tests:
The goal is not to prove that the agent never fails. It is to prove that failures are bounded, visible, and recoverable.
Before production access, confirm that you have:
An AI agent should earn more authority only after its behavior is observable under real conditions. Start with read-only access, measure what happens, and expand one permission at a time.
This article is an English technical adaptation of the original Hebrew guide published by AI NEWS Israel: לפני שנותנים לסוכן הרשאה: שבע בקרות שחייבות להגיע לפני הייצור.