Allow it only for read tools, and turn write tools off first. Claude's help center warns that research can invoke connector tools without further approval. A long research run makes many calls, so a mistake or a poisoned result repeats at scale before anyone looks at it.
Why research is different
In a normal chat you see each tool request and can approve or deny it. Research mode runs many steps on its own. The help center states that it can invoke connector tools without further approval and advises disabling write capable tools first. It also says advanced research cannot use local MCP servers, so it relies on remote connectors.
OpenAI's MCP documentation shows a similar pattern in its example. It sets approvals to never because the example exposes only read tools for search and fetch, and it says to keep approval enabled for tools that can modify data or take consequential actions.
What can go wrong in a long run
- Volume. The assistant may pull far more findings than you expected.
- Drift. A tool that was safe at the start returns different data later.
- Injection. Text inside a finding, a package description or a ticket can include instructions. The OpenAI documentation notes that malicious instructions in data an MCP server can access may cause unintended actions, including sending private data elsewhere.
- No checkpoint. Nobody confirms step seven of twenty.
Settings before you run research
| Setting | Recommended value |
|---|---|
| Write tools | Off |
| Read tools | Only the ones the question needs |
| Scope of token | One project or one team |
| Sensitive tools such as export | Off |
| Reviewer | A named person reads the output before acting |
A safe pattern for research questions
Good research questions are bounded and checkable. Examples: which open critical findings in this project have a fix available, or which direct dependencies lost maintainer activity this year. Poor ones are open ended, such as clean up everything that looks wrong, because they invite action.
After the run, spot check three claims against the security tool itself. If one is wrong, treat the whole answer as a draft.
If you must allow some writes
Keep them reversible, make them leave a visible trail, and require a human to apply the final change. Never let a research run both decide and commit a change in the same pass.
A worked example: one bounded research question
This is an illustration, not a real run.
A lead asks for a research pass: for the three projects we ship to customers, which open high severity findings have a fix version listed, and which direct dependencies are the cause? Before running it, the lead disables the connector's write tools, keeps three read tools, and uses a token that can see only those three projects.
The run makes many calls. It lists the projects, pages through findings for each, and fetches details for a few vulnerabilities. It then writes a report. The lead reads the report, checks five rows against the product, and finds one wrong version number. The report is marked as a draft, the error is corrected by hand, and the fix work is created by a person.
Compare the unsafe version of the same task: a vague request to tidy up the vulnerability backlog, write tools on, broad token. Nothing in that setup limits what an unattended run might do.
Step by step: prepare a research run
- Write the question so it has a clear end and a checkable answer.
- List the tools the question needs. Switch off all others for the run if the chat app allows it.
- Confirm the token scope covers only the projects involved.
- Disable any tool that writes, deletes, exports in bulk or changes access, as Claude's help center advises for write capable tools.
- Decide who will read the output and by when.
- Run it.
- Check a sample of claims against the product and record the error rate you found.
- Re-enable normal settings if you changed any.
Table: question types and risk
| Question type | Example | Risk in an unattended run |
|---|---|---|
| Counting | How many open criticals per project | Low, verify totals |
| Listing | Which packages lack a fix | Low to medium, watch paging |
| Comparing | What changed since last month | Medium, depends on data freshness |
| Acting | Open tickets for everything critical | High, keep a person in the loop |
| Open ended | Clean up the backlog | Do not run unattended |
Signs a run went wrong
- The report mentions projects you did not name.
- Numbers differ from the product by more than rounding.
- The assistant mentions instructions or requests it found in data.
- The run took far more calls than the question needed.
If you see any of these, stop, disconnect the connector from research, and look at the tool call history.
Local servers
The help center says advanced research cannot use local MCP servers. If your security tool is only available as a local server, research mode will not reach it. That is a limit, and also a small safety benefit, since local servers run with your own privileges.
Policy wording
Research runs may use read tools only, with scoped tokens and a named reviewer. Any action that changes data happens outside the run, by a person, in the product.
Where Safeguard fits
Safeguard's autonomous remediation can open fix pull requests, and it is off by default with every category on Manual, so a person decides what happens next. The MCP Guardrail adds policy on which tools agents can call. You can preview findings with the free scan. The Safeguard CLI, installed with a curl or PowerShell installer, can also write code, and the download page lists a Local agent and a Cloud agent as available.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are triaged and notice which actions change state. Those are the ones to keep out of unattended runs.
Quick check
Does research mode ask me before each tool call?
Claude's help center says it can invoke connector tools without further approval, so plan on the basis that it will not.
What should I switch off first?
Any tool that can write or delete, then broad export tools.
Who should review the output of a research run?
A named person with access to the product, who checks a sample of claims before anyone acts on the report.
Sources
Last reviewed: 19 October 2026.
