# Retest boundaries whenever a new tool is added

A model that previously could only summarise may become much more consequential when it can send, update or retrieve additional data. Treat that capability change as a new security review.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Compare capabilities, not tool counts

Adding one general-purpose connector can expand authority more than adding several narrow read operations. List what the new tool can read, change and transmit, including the service identity behind it and the destinations it can reach.

Map those capabilities to the user's intended tasks. A document assistant that gains a ticket-creation tool may legitimately draft a support request, but that does not imply permission to attach every retrieved document. Review fields and attachments as well as the operation name.

Check combinations with existing tools. A lookup tool plus an upload tool can create an export path even if neither was described as an export feature.

## Establish policy before exposing the tool

Implement caller, object and destination checks in the executor first. Give the tool a constrained input contract and a bounded result. Decide which operations require approval and how that approval is tied to the payload.

Test the executor directly with prohibited targets before connecting it to the model. This provides a stable baseline independent of prompt behaviour. Keep the feature disabled for normal users until these checks pass.

Then update prompts and task examples to explain the intended use. Clear instructions improve behaviour, but they should describe a capability already constrained by code rather than become its only constraint.

## Run old attacks against the new authority

Replay the existing injection corpus with the new tool available. A payload previously harmless because no export path existed may now become effective. Add cases aimed at the new arguments, destination handling and result format.

Include persistent conversations created before the release. Their stored context may contain instructions that were previously unable to cause an action. Decide whether older sessions can access the new capability immediately or need a fresh task boundary.

Test benign work too. Overly broad blocking can push users toward manual workarounds that bypass the intended controls. Measure useful completion alongside prohibited effects.

## Roll out with a capability-level rollback

Enable the tool for a limited audience or workflow and observe policy denials, unexpected proposals and downstream actions. Keep a switch that disables the capability without requiring a full model rollback.

If rollback is needed, account for queued and in-flight operations. Removing the tool from the next prompt does not cancel work already accepted by an executor. Define how those operations are stopped, allowed to finish or reviewed.

The release record should explain the authority added, the checks that constrain it and the evidence from testing. This gives future reviewers a meaningful starting point when the next connector changes what the assistant can do.

## Sources

- [OWASP: prompt injection prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)
- [OWASP: authorisation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)