Limit an agent’s authority

Describe the task before granting access

An agent that reads code needs different authority from an agent that deploys a service. Do not grant both sets of permissions because the same product supports both actions.

Use three parts to define authority: an action, a resource, and a condition. For a fictional report fix, the agent can write to one feature branch while the task is active. It can read approved repository files. It cannot modify production data or repository protection rules.

The exact enforcement depends on the tool. If a token cannot express a branch restriction, use additional repository controls or an execution service. Document the remaining authority honestly.

Enforce the limit outside the model

A prompt is not an access-control system. The execution component must check the requested action and target against current permissions. It must not accept a model’s statement that approval already exists.

AWS recommends limited permissions and temporary credentials for appropriate workloads. OWASP applies similar least-privilege reasoning to agents and their tools. These principles require implementation in the actual identity and execution systems. AWS IAM guidance, OWASP agent guidance.

Use short-lived credentials where supported. Keep unrelated secrets out of the environment. A read-only repository task should not inherit a production database password from the developer’s shell.

Bind approval to the actual action

Approval to prepare a change does not imply approval to deploy it. A deployment decision should identify the artifact, target environment, and relevant conditions. If these change, the previous decision may no longer apply.

Consider an agent that proposes a safe database read, then executes a different query after receiving approval. A useful approval mechanism checks the operation that actually runs. A generic “continue” message without a defined target can conceal this difference.

Also separate identity from capability. Record which person or workload initiated the run. Verify that the initiating identity still has permission when the action occurs. Removing a person’s access should have an explicit effect on queued work.

Test a denial and an interruption

Verify more than the successful path. In an isolated test environment, attempt an action outside the permitted resource. Confirm that the execution system rejects it. Inspect the audit event without recording credentials.

Then test cancellation or credential expiry. Determine which work stops immediately and which operation can finish. A stop button does not necessarily reverse an action that already reached another system.

Keep a small permission record with the task. Include the owner, approved scope, actual controls, denial test, and expiry. This makes a later review specific enough to improve the workflow.