The block became a message. Who gets it where you work?

Until recently Claude stopped the request outright when it hit a safety filter. It never went through, and that was the end of it.

But on 17 September Anthropic published a programme where it works differently. Inside the programme the request goes through. Anthropic looks at it afterwards. And if something looks wrong, Anthropic can send a message to the organisation's admins, who then have an agreed deadline to respond.

The programme is called the Life Sciences Verification Program, it covers life sciences only, and you will almost certainly never apply. Nothing about your own Claude account changed on 17 September. What the programme exposes is answerable today about any AI vendor you already use: who at your company receives a misuse notification, and what happens next? Most companies can't answer either one.

The block became a message

Anthropic is moving safeguards, in its own words, "from real-time blocking" to "offline monitoring": away from stopping the request while it happens, and toward looking at it afterwards. Follow one request through and you can see what that means.

Before: a researcher asks Claude for something, the filter catches it, no answer comes back. Nobody else hears about it. The incident is over in the same second it started.

After: the same researcher asks for the same thing. Claude answers. The traffic is retained for 30 days. If Anthropic's monitoring later finds something outside the purpose the organisation stated, then Anthropic writes that it can "flag these cases to organization admins to take action within pre-agreed timeframes".

Notice two words in that sentence. The first is "can". Anthropic is describing what it is able to do, and it isn't promising a message every time. The second is "admins", plural and unnamed. There's a role in that sentence and a deadline. There isn't a person.

Anthropic detects and tells. Whoever has to do something about it sits at the customer.

On scale: Anthropic writes that it has already "onboarded dozens of organizations" through an early-access programme, and that it expects "hundreds of organizations within the first week". The first is a count. The second is Anthropic's forecast for its own first week, and only the count tells you how widespread the programme is now.

Who receives the message when it arrives?

The grant is applied for by the organisation's admin, not by the researcher. That's on the application page, and whoever fills in the form is also first in line to receive the messages.

There are two kinds of grant, and each has its own clock:

• Standard Use covers most life science work and renews once a year. It can be extended to a whole team.

• High-risk Use is an add-on for teams working in areas Standard Use blocks. Anthropic writes that it removes "all safeguards that block life sciences requests". It renews every six months and covers a specific project.

Verification looks at three things: research credentials, security standards, and ethical oversight of the research. Access covers the biology-capable models: Mythos 5.1, plus Opus 5 and Sonnet 5 under a refined biosafety classification. The application form names them; the announcement says only "Mythos, Opus and Sonnet".

Three things the sources don't address, and all three are operational:

• What the deadlines are. "Pre-agreed timeframes" are agreed with the individual organisation. None is published.

• What responding means. Anthropic writes "take action" and doesn't expand on it.

• Whether a grant can be withdrawn mid-term. The renewal periods are public. The conditions for losing access are not.

Anthropic is precise about what it keeps and vague about what you have to do. The deadline is the one item in the whole programme the customer negotiates, and its length still isn't written down anywhere.

The condition: 30 days of retention

Anthropic requires 30 days of data retention for traffic in the programme, and says why itself: with no retained traffic there is nothing to review afterwards.

The requirement isn't new with this programme. Claude Fable 5.1 and Claude Mythos 5.1 have carried it since 1 September, when Anthropic's release notes said both models require 30-day data retention and aren't available under zero data retention unless Anthropic expressly authorises it.

So if your organisation chose zero data retention deliberately, that choice has closed two doors in eleven days, and somebody there should be keeping the list. The first was on 6 September, when eight features fell outside the same kind of arrangement.

So is the trade a good one? It depends on what you're afraid of.

Real-time blocking stops the individual request and doesn't see the pattern. It catches what's happening now, and it doesn't notice that the same account has asked something related fourteen times in a week. Offline monitoring sees the pattern and puts a human on the case inside an agreed window. In exchange, it lets the individual request through. That is human in the loop AI with the loop drawn around your organisation rather than around the model, and the human in it works for you.

Three groups can't take part: individual plans, third-party platforms, and organisations with a BAA. Anthropic gives no reason for any of them.

My own reading, and you should treat it as mine rather than Anthropic's: in all three cases the monitoring is missing a part of its machine. An individual plan has no admin to send the message to. A third-party platform doesn't route the traffic through Anthropic's own systems. And a BAA is a data-handling agreement that collides with a requirement to keep the traffic for 30 days.

The programme never mentions a data processing agreement

A BAA is an instrument under HIPAA, which is US health legislation. A Danish company doesn't sign a BAA. It signs a data processing agreement under GDPR. And no European equivalent is named anywhere in the programme.

So the list of who is shut out is written in a regulatory language that European data protection doesn't use. A Danish organisation can't read the page and work out which side of the line it's on.

The programme was written for the market it was written for, so this is not an accusation. But if you have to judge whether the carve-out applies to you, there is a sensible default: assume it does, until somebody writes otherwise. That is the cheap mistake to make. You find out about the opposite assumption when someone asks.

I wrote earlier in September about inference hooks, where the customer writes a control of their own that can say no while the request is happening. Put the two side by side and you can see that a "no" can sit in two places: at the vendor, which has moved its own no out of the way inside this programme, or at you.

Write down the last refusal, with the date and the model

Take the last thing Claude refused you. Not an invented example, the real one. You can finish this while you're reading.

Sort it into one of three boxes. The first two have always been there. The third is the one today's news proves exists.

1. It never changes. A boundary that applies to everyone, and that no rewording will move.

Test: say the same thing calmly and precisely once, in a fresh conversation. The same refusal means the wording wasn't the problem.

2. You can change it yourself. The model never got the document, the access, or the role.

Test: attach the document and state the role in a fresh conversation. If it goes through, it was a gap in the context.

3. It depends on which account is asking. This is the new one. Since 17 September there are accounts where the same question gets a different answer, because the organisation behind it holds a grant.

Test: none you can run yourself. This one costs a question to the vendor about what your agreement covers.

Then write down one line: the date, the model, and the exact request. That is the whole difference between a record and a note saying "we tested it, Claude won't", which nobody can reuse because it says neither when nor for whom.

And the rule that changes something today: one rewrite, not five. If you hit the same wall a second time, the answer is in the agreement.

AI implementation is also about what the model says no to

Most people talk about AI implementation as a question of what the model can do. Just as much of the work sits in what it won't do, and who can change that.

As an AI consultant and Claude specialist in Copenhagen I set Claude up for Danish companies, and this kind of question is a standing part of the job: who at the vendor takes the enquiry, what the agreement says about notice and deadlines, and who at your company gets the message when it comes. It's rarely hard to find out. It's just never anyone's job.

Boxes 1 and 2 are an AI audit you can run yourself in a morning, with the section above. Box 3 needs an answer from the vendor, and that is where most people stall: they know neither who to ask nor what to ask for. That is the kind of thing a retainer covers.

There's a sentence very few people can finish right now.

When your AI vendor decides something in your account is misuse, ______ gets the message, and then ______ happens.

Sources

• Anthropic: Introducing the Life Sciences Verification Program
• The application page, which carries the precise model names
• Claude Platform release notes, where the 30-day retention requirement was set on 1 September
• Anthropic's pricing page, which does not mention the programme
• Brinvik: Eight features fall outside your zero data retention arrangement

How this article was made. Claude read Anthropic's own pages, checked the quotes word for word and built every single file while Kim was asleep. Gate 1 killed the first spine and sent it back. Two claims about other vendors were cut, because their documentation could not be read from here and a guess was not good enough. The rules, the voice and the checklists are Kim's, written in advance and enforced along the way.