Seven Controls to Put in Place Before an AI Agent Gets Production Access

Yaniv Shenhav — Sun, 20 Sep 2026 19:26:15 +0000

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.

1. Separate read, recommend, and execute

Do not treat "access" as a single permission.

Use three distinct stages:

Read - retrieve the minimum data needed for the task.
Recommend - prepare a proposed action without changing external state.
Execute - make the approved change through a narrowly scoped tool.

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.

2. Give every tool its own narrow permission

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:

Which resources can it access?
Which operations can it perform?
How long does the permission last?
Which environment does it apply to?

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.

3. Add an action budget

Agents need more than an API rate limit. They need a business-action budget.

Useful limits include:

maximum records changed per run;
maximum messages sent per hour;
maximum cost per transaction and per day;
maximum number of retries;
maximum number of external systems touched in one workflow.

The budget should fail closed. Crossing it should stop the run and request review, not trigger an improvised workaround.

4. Put approval at the point of commitment

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.

5. Treat external content as untrusted input

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.

6. Log decisions and effects separately

A useful audit trail answers two different questions:

Why did the agent decide to act?
What changed in the external system?

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.

7. Build a real stop mechanism

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.

A small pre-production failure drill

Before giving an agent live access, run at least these tests:

A document contains an instruction that conflicts with the assigned task.
The agent is given the wrong recipient or resource identifier.
A required external service fails halfway through the workflow.
The same event is delivered twice.
An approval expires before execution.
The agent tries to exceed its action budget.
The stop mechanism is activated during a run.

The goal is not to prove that the agent never fails. It is to prove that failures are bounded, visible, and recoverable.

The minimum launch checklist

Before production access, confirm that you have:

a tool allowlist;
least-privilege, short-lived credentials;
separate read and write paths;
explicit approval for high-impact actions;
action and cost limits;
idempotency protection;
tamper-resistant logs;
monitoring and alerts;
a credential-level stop mechanism;
tested failure and recovery paths.

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: לפני שנותנים לסוכן הרשאה: שבע בקרות שחייבות להגיע לפני הייצור.

DEV Community: Yaniv Shenhav