Assistants, agents, and permissions

Identify how the system acts

An assistant can explain code, propose a plan, or suggest an implementation. An agent can also use tools and act on the environment. Product names do not provide a reliable boundary. Some chat interfaces can execute commands. Some coding tools only suggest text.

Inspect the available tools. A useful description states what the system can read, change, execute, and publish. This description also identifies which credentials and environment each action uses.

Anthropic distinguishes predefined workflows from agents that select their own sequence of tool use. This distinction helps explain how work proceeds. It does not determine whether a specific action is safe. Both designs need an explicit permission boundary.

Separate a goal from permission

Consider a fictional request: “Fix the invoice export.” An agent can inspect the repository, reproduce the defect, edit a branch, and run checks. It might also find credentials for the production database in its environment.

The goal does not authorize every available action. Reading a production table, changing invoice records, and deploying a new version have different consequences. A broad instruction such as “complete the task” does not explain which of these actions the organization permits.

Define the boundary before work starts. For this example, the agent can use invented data and a local database. It can create a pull request. It cannot access production records or deploy the change. A separate release process handles those actions.

Use technical controls for authority

Instructions help the agent understand the task. Credentials and access controls determine what the agent can actually do. Use both.

A read-only task should not receive write credentials merely because they are convenient. A test environment should not silently inherit production access. Review the connections between tools, identities, and resources. A harmless-looking command can have a large effect when it uses a powerful identity.

Define when work must stop

An agent needs a stop condition when the next action exceeds its authority. It also needs one when the evidence is insufficient.

For the invoice example, stop if the defect requires a production data correction. Stop if the requested behavior conflicts with the documented accounting rule. Report the conflict with the relevant evidence and the decision needed from an owner.

A time or cost limit is useful for repeated attempts. It does not replace a permission boundary. Ten authorized attempts and one unauthorized deployment are different problems.

Evaluate the result and the action record

At completion, inspect more than the final response. Review the changed files, executed checks, and remaining uncertainty. Check whether the actions stayed inside the agreed scope.

A capable agent can reduce manual work. The organization still needs to define the permitted actions, verify important outcomes, and own the release decision. More autonomy increases the importance of these responsibilities.