What Changes When an AI Assistant Gets Permission to Act?

A short from my book, Boxing Einstein. Adapted from Chapter 6, “What Keys Did We Give Him?.” This is an adaptation, not a verbatim excerpt.

The move from advice to action changes the permissions you need to examine, even when the underlying model stays the same. An assistant that proposes a change and an agent that can carry it out are different operating arrangements. In Chapter 6 of Boxing Einstein, I put the question bluntly: what keys did we give it? (Clark, n.d.).

Imagine a hypothetical assistant that reads project documentation and suggests corrections. Then give it access to open tickets, modify a repository and invoke a deployment service. Each addition might be justified. Taken together, they create a different path from an imperfect answer to a real consequence. The original approval to help with documentation does not describe that path.

This is why I would inspect the deployed arrangement rather than stop at a model's name or capability claim. The tools, credentials, stored state, external connections and human intermediaries determine what a recommendation can become. A capable system with narrow authority and a less capable system with extensive authority pose different questions.

An objective is not a permission grant

“Finish the task” is a statement of intent. It shouldn't automatically mean “acquire whatever access would make finishing easier.” If a system discovers that additional information or another tool would improve its answer, that is a reason to request a decision about scope. It isn't, by itself, authority to cross the boundary.

I would separate reading from writing, proposing from executing and temporary task access from standing access. For the hypothetical project assistant, reading deployment instructions need not imply permission to deploy. Preparing a proposed configuration need not imply authority to activate it. The boundaries should correspond to consequences people actually care about.

Delegation needs the same scrutiny. If one agent can ask another service to perform an action, limiting the first agent's direct credentials may not describe its effective reach. The useful inventory follows the path to the action, including which service accepts the request and whose authority it uses. A tidy list of direct permissions can miss the arrangement you're actually operating.

The permission review has to survive success

The book's concern is not that every added permission is a mistake. Sometimes multi-step action is the source of the benefit. Requiring a person to manually transfer every harmless intermediate result could consume the value of the tool. The decision is which authority the work needs, under what conditions, and how an exception expires.

I would revisit that decision when the task, tools, model, integrations or operational context change. A successful limited trial supports conclusions about that trial. It doesn't silently authorize a wider set of actions simply because the same assistant is asking for them.

The record should explain the allowed action, the boundary that enforces it and the evidence that would show the boundary failed. A controlled, benign test can then ask whether an unauthorized request is actually refused and recorded. Such a test needs an approved environment and scope; it is not an invitation to probe production systems to make a point.

Technical permissions are also only part of the picture. An assistant might lack direct access while a person routinely executes its instructions. That can be a legitimate workflow, but the human decision becomes part of the authorization boundary and deserves its own scrutiny. Removing a credential doesn't resolve every route to consequence.

I am less interested in whether a product calls itself an agent than in what it can cause before somebody has to make a separate decision. Read about Boxing Einstein for the argument that authority should be granted deliberately, rather than arrive as an unnoticed feature of useful intelligence.