What should an AI agent be allowed to do without approval?

Decide what to delegate before the agent starts

Start with one recurring task. For example: collect specified configuration and audit evidence for a finding in a named test account, then prepare a proposed change. Name the owner, allowed resources, data handling rules, duration, and stop conditions. Read-only access still needs authorization: a log or object can contain sensitive data even when the agent cannot alter it.

Consider four questions before expanding that scope:

• Impact: could the action expose data, interrupt a service, delete something, or create a financial commitment?
• Predictability: are its target, dependencies, and likely effects understood?
• Recovery: can an authorized operator recover, and what could recovery itself affect?
• Evidence: can someone establish what happened and whether the required outcomes hold?

Bounded, repeatable work with observable results is a candidate for prior delegation. A production policy change with uncertain dependencies warrants review of the actual proposal. Reversibility alone is insufficient: restoring access after an outage does not erase the interruption.

Enforce AI agent permissions in tools and downstream systems. OWASP recommends restricted functionality, limited permissions, and human approval for high-impact actions, with authorization enforced beyond the model. OWASP: Excessive Agency. For AWS access, align allowed actions, resources, and conditions with the task, and use temporary workload credentials. AWS IAM best practices.

Match authority to the action

An API credential may permit a write without authorizing this particular business change. Keep technical permissions and the approval workflow aligned.

Drafting a policy grants no execution permission. Running an adversarial check also needs agreed targets and test limits. Verification does not grant authority to repair an unexpected result.

Make approval specific enough to enforce

A useful request shows the target and environment, operation, exact diff or arguments, required current state, expected service behavior, and expiry. It identifies both the authorized reviewer and the intended executor. The reviewer should understand what will change without reconstructing a chat.

Keep approval and execution as separate steps. At execution, check that authority remains valid and that the request still matches it. Reject denied, revoked, expired, or changed approval. A different target, operation, material argument, or failed precondition requires a new decision.

For an AWS permission change, use the policy review workflow to document the current policy, proposed policy, and required requests before asking for approval. The shared-role example shows why another workload’s access must be part of that decision.

A log entry or tool result saying “approved” cannot supply that authority. Treat collected content as evidence and enforce the decision through the authorized approval mechanism.

Follow one cloud change through both outcomes

Cotton’s interactive public-access case follows cotton-lab/canary.txt in the fictional cotton-demo-reports bucket. The proposal removes anonymous read access while retaining access for media-api. This synthetic S3 scenario makes no cloud requests and does not validate real AWS permissions.

For a real evaluation, establish the unwanted access and a working application baseline before the change. Agree what the application must still do. After authorized execution, collect fresh observations:

• Security: the unwanted read reaches the intended resource and is denied.
• Service: the intended application identity still reads the expected object through its required path.

A failed service check keeps the finding open. A missing check remains unknown. A timeout does not prove access was denied. Retain the target, caller, method, observation time, and evidence reference for both checks.

When applying this pattern to Amazon S3, inspect the actual policy and applicable controls. Block Public Access has no per-object setting, and AWS advises checking application behavior before restricting public access. Broader changes need broader checks. AWS S3 Block Public Access guidance.

Give verification separately governed evidence access and authority to withhold closure. Using another model or vendor alone does not establish that independence. The worked remediation article shows the fuller evidence record.

Resolve uncertainty before another change

If an execution request times out, mark its effect unknown and reconcile the target state with the recorded attempt. AWS explains why blindly retrying a request can create additional effects and how appropriate idempotent API contracts help. AWS: Making retries safe with idempotent APIs.

Check the particular operation’s retry behavior and current authority before another attempt. Recovery needs its own authorization and outcome checks. Restoring an earlier policy might restore the exposure too. Assign an owner to the unresolved outcome and keep closure blocked until the required evidence is available.

Test the boundaries before expanding autonomy

Ask an agent supplier to demonstrate rejected approval, substituted targets, changed policy state, expired authority, and a lost execution response in an isolated lab. Then test a successful security change that breaks the application, and a run with missing service evidence. Inspect downstream records to confirm blocked actions never reached the target.

Use Cotton’s ten-test evaluation checklist to record expected behavior, observed evidence, and stop decisions. Begin with one recurring workflow and expand delegation only when its authority boundaries and outcomes can be demonstrated.