A practical tool-permissions checklist

Describe actions and resources together

Connecting an agent to an account is only the beginning of a permissions decision. The useful question is what that connection allows the agent to do during a particular job. A simple written checklist can make those capabilities understandable to the person operating the system and the person maintaining it.

Start with an inventory of tools. For each one, record the action, the resources it can reach, and the identity it uses. Reading one project folder, reading an entire drive, creating a draft, and publishing a page deserve separate entries.

The Model Context Protocol’s security guidance recommends minimizing authorization scopes and avoiding bundles of unrelated privileges. That supports a practical starting point: request access for the actual task, then expand it deliberately when a new operation requires it.

For an editorial assistant, a useful first inventory might allow reading an approved source folder and writing to a drafts folder. Add the exact folder identifiers to the checklist. “Can use storage” leaves too much interpretation for a reviewer to understand the intended boundary.

Decide where review belongs

List the operations that need someone to inspect a concrete result. Sending a message, publishing content, changing access, and deleting a record are reasonable candidates to examine. The appropriate boundary depends on the task and the consequences of an error.

Make the review useful. A publishing request should show the destination, the final content, and the assets being attached. A deletion request should identify the record. Avoid a vague approval prompt that forces someone to reconstruct what is about to happen.

OpenAI documents risks from prompt injection and unintended data sharing, and recommends combining constrained data flow, clear instructions, and tool confirmations. These are risk-reduction measures rather than a guarantee of correct behavior.

Our checklist suggestion is to record both the review condition and the information shown at that point. This turns “ask before publishing” into an operation someone can actually assess.

Enforce the policy outside the prompt

A written instruction can explain the desired behavior, but the service handling a tool call should still check authorization. MCP’s own security policy assigns server developers responsibility for access controls, input validation, and least-privilege design.

For each write tool, document who may invoke it and which objects that identity may change. Validate identifiers before the operation happens. Keep credentials out of model-visible tool results and routine logs. Consider separate credentials for a draft-only integration and a publishing integration so their privileges can be reviewed independently.

Test the boundary with concrete examples: an allowed folder, a different folder, an expired session, and an object owned by another user. Record what the service actually does in each case.

Include recovery and an owner

Finish the checklist with four operational details: who owns the connection, how access is revoked, where actions are recorded, and which changes can be undone. Assign someone to review the inventory whenever tools or scopes change.

For a pilot, rehearse one recovery scenario. If an agent writes an incorrect draft, can you locate the action and restore the earlier version? If a credential is revoked, does the next operation fail clearly? Record the answer and any remaining gap. Permissions become easier to maintain when the checklist covers the full life of the connection, including its removal.