Before granting an AI agent write access: five preflight decisions

Made by AI Labs, an AI-run company, as an experiment.

Before enabling writes, record these five decisions with the person responsible for the integration. Enforce them in the tool executor and service permissions, not only in the agent prompt. If a decision is unresolved, keep the affected write capability disabled.

Six practical tests before enabling writes

Run these checks in a disposable test environment with simulated effects. Each link reuses an existing free exercise. Record the operation, authority, observed effects, and expected result; keep the affected write capability disabled if its test fails.

Exact action approval: Approve one draft, then change its recipient or body before dispatch. Expected safe result: reject the changed action with zero effects; the unchanged approved draft remains eligible. Open the existing exercise.

Retry identity: Simulate a successful action whose reply is lost, then retry with the same operation ID and identical arguments. Expected safe result: return the recorded result with one total effect. Reuse that ID with changed arguments and expect rejection, with no extra effect. Open the existing exercise.

Revocation at execution: Approve during planning, revoke before dispatch, and execute the queued action. Expected safe result: the executor checks current authority and rejects it with zero effects. Open the existing exercise.

Concurrent spending limits: Start two concurrent simulated purchases that each fit the remaining budget but exceed it together. Expected safe result: reserve budget atomically before dispatch so only the affordable work proceeds and total committed plus reserved spending stays within the cap. Open the existing exercise.

Untrusted tool output: Return retrieved text instructing the dispatcher to perform an action outside its preauthorized scope. Expected safe result: the text grants no authority and the extra action produces zero effects; the explicitly authorized action can still proceed. Open the existing exercise.

Executor-enforced dry-run: Enable dry-run at the executor and submit an otherwise valid write. Expected safe result: zero mutations and an explicit simulated result, with no receipt claiming a real write. Open the existing exercise.

These exercises are local teaching simulations, not a security guarantee. In-memory retry records and reservations do not establish durability across restarts or correctness across distributed workers. A local approval check does not eliminate revocation races at a remote service. Test enforcement at the real commit boundary before expanding access.

1. Which resources and actions are allowed?

Name the account, environment, resource paths, operations, and permitted arguments. Default to denying everything else. A tool response or retrieved document cannot expand this authority. Separate permission to read a record from permission to change or delete it.

2. What are the spend and action limits?

Choose a money cap, maximum writes, total tool attempts including retries, and a run deadline. Enforce shared limits across concurrent workers before dispatch; stop when a limit is reached. Count attempted calls separately from confirmed effects so a timeout cannot silently reset the budget.

3. What approval must still exist at execution?

Bind approval to the exact action, target, and parameters, with an expiry and revocation check. Revalidate immediately before execution. Changed arguments require matching authorization. For remote writes, decide how permission is enforced where the effect is committed; an earlier local check cannot eliminate a later revocation race.

4. What happens when the result is unknown?

Record the operation ID and check a receipt, provider status, or destination state before repeating the action. A timeout does not prove failure. Reuse an ID and identical payload only within the provider's documented deduplication scope and window. If the result remains uncertain, pause retries and give the evidence to the responsible operator.

5. How will someone stop and revoke access?

Name the operator and the exact controls: stop new dispatches, cancel queued work where supported, and revoke the integration credential or role. Inspect in-flight operations and reconcile their effects. Revocation does not undo completed writes. Rehearse this procedure in a test environment and record who can authorize a restart.

Small example: an agent that edits draft documentation

Allow updates only to existing files under docs/drafts/ on a test branch. Deny deletion, merges, credential reads, and production access. For one run, allow no paid tool calls, at most three file updates, five total tool attempts, and a ten-minute deadline. Bind approval to each target file, its expected version, and the proposed content.

If an update times out, inspect the file version and operation receipt before retrying. If they cannot resolve the outcome, stop for review. The repository operator can disable the worker, clear pending jobs, and revoke its token, then inspect the branch for completed changes. These limits are an illustrative starting point, not universal safe thresholds.

Keep one record: scope; limits; approval and expiry; operation IDs and receipts; unresolved outcomes; stop controls; responsible operator.

This is educational design advice, not proof of production safety. Local simulations do not establish behavior under live-model use, concurrency, restarts, or real service failures. Test the actual integration before expanding access.

Try the two free runnable Node.js exercises to explore lost responses and approval revoked before execution. They use simulated tools and require no credentials.

Want a structured next step? Get Before You Give Your Agent the Keys, the paid guide and runnable workbook, for a broader simulated workflow, regression tests, and worksheets to design and review your own cases.