Allow always means the assistant stops asking permission and runs that tool whenever it decides to. Claude's help center says to choose it only for servers and tools you trust to run unsupervised. For security connectors, that fits read only lookups, and rarely fits anything that creates, edits or deletes.
What the prompt is for
Tools in MCP are model controlled, which the specification explains as the model discovering and invoking tools from context and your prompt. The same page says there should always be a human in the loop with the ability to deny invocations, and that applications should show which tools are exposed, show when they are invoked, and present confirmation prompts.
The approval prompt is that human in the loop. Allow always turns it off for one tool.
A simple sorting rule
| Tool type | Example in a security connector | Allow always? |
|---|---|---|
| Read, narrow | Show one project's open findings | Usually fine |
| Read, broad | Export every finding across the company | Think twice |
| Write, reversible | Add a comment to a ticket | Keep the prompt |
| Write, hard to undo | Change a policy, dismiss findings, delete data | Keep the prompt |
Read is not automatically harmless. A tool that returns a lot of data can still expose it to places you did not intend. A broad read is also a stronger target for prompt injection that tries to pull data out.
A trap in the labels
OpenAI's documentation warns that a server can mislabel a write action as read only. The MCP tools page says clients must treat tool annotations as untrusted unless they come from trusted servers. So the label that says read only is a hint, not a guarantee. Judge a tool by what you verified it does.
How to set it up sensibly
- Start with every prompt on. Use the tools for a week and watch what they do.
- List the tools that were called often and always returned plain data.
- Allow always for those, one at a time.
- Leave prompts on for anything that changes state.
- Recheck after the vendor changes the tool list. Claude's help center warns that server developers can change tool behavior without notice.
Revoking a decision
If a tool starts behaving differently, switch the permission back. Claude's help center also lets users disable tools they do not need from the search and tools menu, and lets owners disable interactive tool calls in organization settings.
A worked example: a two week review
This example is illustrative.
A team connects a security connector with eight tools. On day one all approval prompts are on. Over two weeks, people keep a short log: tool name, what the question was, whether the result matched the product, and whether anything surprised them.
At the end the log shows that three tools were called most days: list projects, list findings for a project, and show one vulnerability. All returned plain data that matched the product every time. Two tools were called a few times: a broad export and a ticket creator. One tool was never called.
The team decides to set Allow always for the three lookup tools, keep prompts on for the ticket creator, and ask the vendor to disable the broad export for this workspace. The unused tool is turned off from the tool menu.
Step by step: decide per tool
- Write the tool's name and what it does in one sentence.
- Ask whether it can change anything. If yes, keep the prompt.
- Ask how much data one call can return. If a lot, keep the prompt or disable it.
- Run it ten times with different inputs and compare with the product.
- Check whether the result can contain free text written by outsiders. If so, note the injection risk.
- Decide, write the date and the name of the person who decided.
- Set a re-review trigger, such as any vendor change to the tool.
What Allow always does not cover
- It does not make a tool safe. It only removes a prompt.
- It does not apply to new tools that appear later, which should get their own decision.
- It does not protect against a tool whose behavior changes under the same name. The help center warns that developers can change tool behavior without notice.
Table: signals to revoke a permission
| Signal | Action |
|---|---|
| Tool output includes unexpected instructions | Revoke, report to the vendor |
| Tool returns more fields than before | Revoke, ask what changed |
| Tool starts to need new scopes | Revoke, review the scopes |
| Users stop checking answers | Revoke, retrain |
| The vendor changes the description | Re-review before allowing again |
The human factor
Prompts lose value when people click through them. If every call asks permission, users learn to approve without reading. Allowing a few low risk lookups makes the remaining prompts rarer and more meaningful. That is the best argument for Allow always: it is not about speed, it is about keeping the prompts that remain worth reading.
A policy sentence you can use
Allow always is acceptable for read tools that return limited, non sensitive fields and have been tested against the product. It is not acceptable for any tool that writes, deletes, exports in bulk or changes access. Owners review the list each quarter.
Where Safeguard fits
Safeguard's MCP Guardrail is built for the policy layer above individual prompts, so a decision about which tools agents may call does not depend on each user clicking the right button. The free scan at gold.safeguard.sh/scan is a safe way to see typical read output.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow the conversation and note which tool calls are lookups and which would change something. That is the line for Allow always.
Quick check
Is Allow always permanent?
It stays until you change it. Revisit it whenever the connector's tool list or behavior changes.
Can I allow one tool and not another?
Yes. The help center describes tool level choices, and unneeded tools can be disabled from the search and tools menu.
Should every user decide for themselves?
Better to set a team rule. Individual choices vary, and one careless Allow always can expose more than the team intended.
Sources
- MCP specification, tools
- Claude Help Center, custom connectors using remote MCP
- OpenAI developer docs, MCP
Last reviewed: 19 October 2026.
