Give an AI agent a smaller set of keys.

Imagine asking an assistant to make a tidy index of one project folder. It needs to read the selected documents and propose a useful summary. It does not automatically need permission to reorganize your drive, delete old files, or publish the result somewhere else.

The difference sounds obvious when written out. It becomes less obvious when one convenient integration arrives with a broad set of capabilities.

I would rather start with a small set of keys and a well-defined job than a large set of keys and a request to be careful.

Separate reading, proposing, and changing

Treat these as different steps in the product experience.

The assistant reads the folder you selected. It prepares an index in a preview. A separate action writes the approved index to a named destination. None of those steps should quietly grant permission for the next one.

For the write step, make the proposed result concrete: the exact destination, whether a file will be created or replaced, and the content that will be saved. “Continue?” is a weak description of a consequential action.

This separation also gives the interface somewhere sensible to stop. A useful draft is still a result when a person is not ready to apply it.

Put the restriction outside the prompt

OWASP’s guidance on excessive agency recommends minimizing tool functionality and permissions, enforcing authorization in downstream systems, and requiring approval for high-impact actions. The practical implication is that a model’s instructions should not be the only thing preventing an unwanted operation.

In the folder example, enforce the selected paths in the tool layer. Reject an unexpected destination there. An instruction that says “only use this folder” should not sit in front of a credential that can write anywhere.

Check authorization again when the action is executed, rather than assuming an earlier preview is still valid. The selected folder, user session, or proposed content may have changed.

A document is material, not permission

OWASP’s separate explanation of prompt injection describes how external content can influence a model’s behavior. Text found in a document should therefore be treated as input to the task, not as permission to broaden it.

Consider a project note that says to send the completed index to another address. The assistant may need to summarize that sentence. It should not inherit authority to send anything merely because it read it.

A boundary worth testing is whether the tool still rejects that action when the model requests it. A reassuring answer from the assistant is not enough evidence.

Let people see what happened

For the proposed folder tool, I would show the files considered, the result prepared, and the final write outcome. Keep that activity record focused on the task rather than copying every private document into a second log.

Also make it clear when permission has ended. Finishing one index should not silently authorize a later background job across new folders.

Limited permissions and review steps reduce risk; they do not make a system immune to mistakes. They do make the intended behavior easier to explain and test.

The aim is not an assistant that asks about every keystroke. It is one whose freedom matches the job, and whose next meaningful action never comes as a surprise. That is where an off switch and clear recovery behavior become part of the same design.