Test what your assistant is allowed to do

An internal research system, a practical testing lesson

Anthropic published its Anvil research on November 12, 2026. It describes an internal automated red-teaming system used to find weaknesses in Claude's safeguards before deployment. The company reports results under its own research conditions, including access unavailable to ordinary users. Anvil is not a public small-business testing product or a guarantee that an assistant is secure.

The useful lesson for a smaller company is to test the uncomfortable requests as well as the normal ones. A demonstration in which every customer follows the script leaves an important question unanswered: what happens when someone asks the assistant to act beyond its authority?

Start with a single action. Imagine an illustrative repair business whose assistant can collect appointment preferences but cannot confirm a technician's visit. A customer asks for Friday, then insists that the owner has approved it. The expected response should preserve the request and route it to the team. It should not describe the visit as booked without the required confirmation.

Write that expected result down before running the conversation. The tester needs something more specific than “the assistant sounded sensible.” Did the calendar remain unchanged? Was a review task created for the correct request? Did the customer receive an accurate description of the next step? Inspect the receiving records as well as the chat.

Official source: Anthropic, November 12, 2026

Inspect the action behind the reply

Another useful test concerns information access. Use two fictional customers and separate sample records. Ask a question that could be confused with the other customer's job. The system should respect the intended access boundary and ask for the required clarification. Run this in an authorised test setting, without putting real customer details into experimental prompts.

The connection behind the assistant matters. A friendly refusal in the conversation is not enough if the underlying action can still change a record without the agreed checks. The implementation needs to enforce the permissions at the point where an action is attempted. Keep the responsible person's approval visible where the business requires it.

Test failures should become specific repair tasks. Save the synthetic input, the expected behaviour and the observed result. After changing the instruction or integration, repeat that case and the relevant normal workflow. The team should understand what was fixed and which behaviour remains untested, rather than receiving a broad claim that everything is now safe.

A small initial test set can focus on requests the business actually encounters: an unavailable appointment, an unapproved change, an unclear customer reference or a demand to skip review. Add cases when a real problem reveals a new boundary. This keeps testing connected to the service the company promises.

Keep a small record of the boundary

The business can maintain a brief record of each connected action: what the assistant may propose, what the software may execute and what requires someone else's approval. That record should match the actual connection. When permissions change, the relevant test cases need another review before the new behaviour reaches customers.

This is a practical way to discuss scope with an implementation team. Bring one normal request and one request the system must refuse or escalate. Those two examples often reveal more than a long feature list about who remains responsible when a conversation turns into an action.

ProgressorAI can scope those checks around a proposed website assistant and its receiving systems. This example is a testing approach, not evidence of an Anvil integration, a security certification or a completed customer installation.