Default agent actions behavior

Language model–based agents are increasingly used to not just generate text, but to take actions: call APIs, run commands, read and write files, and update databases. Many setups today assume that if an agent has a capability wired in, it is allowed to use it. The default behavior is often to perform actions whenever the agent decides they’re helpful.

These actions can be simple, like fetching something from an external URL, or more impactful, like running commands locally on a machine or updating files and databases. From a usability perspective this can look appealing: you ask for something, and the agent goes ahead and does it. But this action-first default hides important risks and makes systems harder to control.

A safer baseline is that the default agent behavior should be: perform no actions. An agent should start in a mode where it can read, reason, and suggest, but not execute anything that changes the outside world. Any action it is allowed to take should be explicitly configured and explicitly permitted.

In practice, this means that which actions can be executed must be set up deliberately. Tool use, external calls, command execution, and write access should all be treated as opt-in capabilities. If a system wants an agent to be able to fetch a URL, run a specific command, or update a certain database, that must be granted explicitly, not assumed because the agent technically can do it.

This follows a zero trust mindset for agents. Do not assume an agent is allowed to act just because it has access to a tool. Assume no action is allowed by default, and then selectively enable narrowly scoped capabilities with clear permissions and boundaries. This makes it easier to reason about what an agent can do, reduces the risk of unintended changes, and keeps control in the hands of the people designing and operating these systems.

Leave a comment