The permission has to fit the action

“Make the agent safe” sounds like an instruction until somebody has to implement it. Then the awkward questions begin. Safe for whom? Doing what? With which account? Under whose authority? For how long?

I find these smaller questions more productive. They lead towards decisions a system can actually make.

Suppose an assistant is asked to arrange a replacement laptop. Searching a catalogue, comparing specifications, sending an internal recommendation and placing an order are separate actions. They may involve the same conversation and contribute to the same goal. They also carry different consequences. A single permission called “help with procurement” hides most of the useful detail.

I would have the assistant produce a structured proposal before each consequential step. The proposal would identify the operation, resource, recipient, amount where relevant, and the authority it believes applies. That is a proposed design pattern, rather than a claim that today's assistants consistently behave this way.

The system receiving that proposal should decide whether it can proceed. Its rules need to exist independently of the model's account of those rules. A model can help interpret a request or explain why approval is needed. Allowing it to rewrite the conditions of its own access would make the boundary rather accommodating.

There is established machinery for this separation. Open Policy Agent separates policy decisions from their enforcement and evaluates structured input against policies and data. Using such an engine does not make an application secure automatically. The application still has to supply trustworthy facts and ensure that every relevant execution path obeys the result.

That last point matters. A beautiful permission check is decorative if a background worker can perform the same action through an unchecked endpoint. The enforcement point belongs where the capability is exercised. If the assistant cannot obtain the credential or submit the operation without passing that point, the rule has a chance of being real.

The permission itself should describe enough of the action to remain meaningful. Approving an email to a named colleague should not silently authorise a different recipient or an attachment added later. Approving a purchase within a limit should not become permission to start a subscription. Material changes need a fresh decision.

OAuth Rich Authorization Requests provides one useful building block by carrying detailed authorisation requirements rather than relying only on broad scope strings. The standard leaves application-specific meaning to implementers. A service must still decide, for example, whether a revised request asks for more authority than the original grant.

Conflicts also need an explicit order. An individual may approve an action that organisational policy forbids. A standing permission may have expired. A resource owner may have revoked access since the task began. AWS's policy-evaluation documentation offers a concrete example of a system in which explicit denials can override permissions. Other systems may use different rules, but ambiguity should be resolved deliberately.

I would also separate refusal from uncertainty. “This action is prohibited” and “I cannot establish who owns this account” call for different responses. The first should stop. The second might be resolved through a verified identity check or a question. Collapsing both into a generic error encourages users to keep clicking until something happens.

Testing should be equally specific. Change the recipient after approval. Revoke access between planning and execution. Submit the same request twice. Let a tool return a document containing instructions to expand access. Ask whether the system preserves its boundary under each variation.

These tests are less theatrical than asking a model whether it intends to behave responsibly. They are also easier to interpret when they fail.

The human experience matters throughout. Approval requests should describe the actual consequence in ordinary language. A person cannot give useful consent to a vague summary hiding several operations. Too many needless prompts are another failure: eventually every button begins to look like the one that makes the interruption go away.

The aim is a system that knows when existing authority is sufficient, when a specific decision is missing and when it must stop. That is a much more practical ambition than a reassuring adjective attached to the word agent.