Astra cyber safeguards: buying checks

Retrospective covering 1 September 2026, written on 9 September 2026.

Astra cyber safeguards matter to buyers because model capability, permitted access and reliable task completion are different questions. My recommendation after OpenAI's September safety update is to test the exact service configuration you intend to buy, including what happens when its safeguards interrupt legitimate work.

On 1 September, OpenAI said Astra met the Critical cybersecurity capability threshold in its Preparedness Framework. The company described stronger safeguards before release and distinguished advanced cyber evaluation access from the default production configuration. These were the developer's assessments, rather than independent guarantees about customer workloads. OpenAI's safety update.

What changed for a procurement review

OpenAI also said safeguards could slow, pause or stop legitimate work. It described different handling across product surfaces: a user might be asked to review an action in ChatGPT or Codex, while a task using the API would stop. The update said Astra would be available soon, rather than announcing general availability on that date. OpenAI's explanation for users.

For procurement, this creates a practical acceptance question. Can the organisation still complete its work when a task is interrupted? A demonstration that only shows successful runs does not answer it.

The distinction is especially important for a process that writes to other systems. A reviewer needs to know what has already happened, what remains incomplete and whether repeating the task could duplicate an action. Ask the supplier or implementation partner to demonstrate those states with harmless test records.

Ask for an access description you can test

Replace vague statements about using the latest model with a precise description of the proposed service. Record the product, model, account arrangement, enabled tools and any additional programme access on which the use case depends.

Ask the sales or implementation team to identify which parts of the demonstration will be available in your account. If advanced permissions require separate approval, treat that as a dependency in the decision. Do not accept an implementation deadline that assumes an approval nobody has obtained.

Your acceptance test should use the customer configuration. A vendor's unrestricted internal test may be informative, but it answers a different question. Keep a record of settings and access so a later change can be assessed against the original decision.

For broader due diligence, the ICT supplier risk guide helps organise the commercial evidence. Here the priority is the boundary between a capability claim and a service you can use.

Build the interruption test first

Choose a workflow with a clear beginning, end and intermediate state. An internal report assembled from approved sample documents is a better starting point than an urgent customer process. Define which actions are allowed and which require a person.

Then ask the implementation team to show how an interrupted run is presented. The responsible employee should be able to answer the following without reconstructing the entire conversation.

Avoid turning the test into an attempt to defeat the safeguard. The objective is to understand business continuity when the service declines or pauses work. A team that can only complete the process by circumventing its controls has not demonstrated a supportable deployment.

Put human review into the operating cost

My assessment is that procurement should count review and recovery effort alongside normal task completion. A service that produces a useful draft quickly may still require substantial attention to verify sources, resolve interruptions and transfer the result into the business process.

Measure a representative set of tasks and record why people intervene. Separate an ordinary editorial correction from a permission decision or an uncertain side effect. That distinction helps identify whether the solution needs better instructions, a narrower scope or a different workflow.

Do not report every human intervention as failure. Review may be an intentional part of the control design. The business question is whether the combined process is useful and adequately staffed.

The AI governance framework template can help assign ownership. Keep the acceptance measures attached to the specific deployment so a general policy does not substitute for evidence.

Rehearse a partially completed business task

Consider an illustrative purchase-order workflow using fictional records. The task prepares an order, saves a draft in a business system and then stops before submitting it. A reviewer needs to distinguish that state from an order that has already been sent. Otherwise a restart could create a duplicate or leave the business believing an incomplete order is finished.

Ask the implementation team to demonstrate how the employee sees the draft identifier, confirms the order status and chooses the next action. Then repeat the exercise with the draft missing and with the receiving system temporarily unavailable. These are proposed acceptance scenarios, not reported Astra incidents or guaranteed product features.

For the wider approval decision, use the earlier Astra release-gate discussion. Here the practical question is whether staff can recover an interrupted task without guessing what the system has already done. Keep a manual route for a time-sensitive order until that rehearsal succeeds.

The useful procurement outcome is an approval with an explicit scope: this configuration, these tasks, these reviewers and this recovery procedure. A model's safety announcement can inform that decision, but it cannot make the decision for your organisation.