When the Model Changes, Its Authority Must Change Too

Enterprise systems are designed for continuity. Users, service accounts, connected tools and approved workflows often move from one model version to the next. The business sees less disruption; the access-control system sees the same product family. Neither tells the board whether yesterday's authority remains proportionate to today's capability.

The danger is the combination, not the model in isolation. A stronger model connected to code repositories, cloud consoles, customer records or operational tools can change what an existing permission makes possible. Even if the supplier's safeguards improve, the organisation still owns its identities, integrations, delegations, human review and response when something goes wrong.

Use a four-step reauthorization gate. First, classify the change in terms the business understands: which work is faster, more autonomous or newly possible? Second, map the affected workflows, data, credentials and third parties. Third, narrow inherited access while the changed combination is tested against realistic tasks, exceptions and attempts to exceed scope. Fourth, restore only the permissions that have a named owner, visible monitoring, an escalation route and a withdrawal mechanism.

This is not a demand to stop every upgrade. Low-impact use may pass quickly. High-impact use should not. The rule is proportional: the more consequential the new capability and the more powerful the connected authority, the stronger the case for a fresh decision.

Anthropic's 1 September announcement makes the customer side of the problem visible. Its planned Enterprise Frontier Safeguards would let eligible customers keep monitoring data in their own cloud accounts, use their own keys and access policies, and send automated flags to their own reviewers. Anthropic says it designed the system with more than 100 customers and major cloud partners. The rollout is phased and its effectiveness is not yet independently established. ²

The procurement questions are nevertheless concrete. Who holds the activity data? Whose keys protect it? Which behaviour is monitored across sessions? Who sees a flag? Which person can clear a false positive or stop real misuse? Can the control operate through the cloud route the organisation actually uses? A supplier promise is useful only when it fits the customer's custody, review and incident obligations.

In the European Union, AI Office and national enforcement powers apply from 2 August 2026. The European Commission says current obligations include transparency and copyright rules for general-purpose model providers, plus security and safety duties for the most advanced models that pose systemic risks. Specified transparency requirements are also active. The later high-risk-system duties follow separate dates: December 2027 for Annex III systems and August 2028 for high-risk AI embedded in regulated products. ³

That timetable matters. Leaders should not describe all AI Act duties as either already in force or postponed. Providers and downstream organisations need an accurate role, model and use-case analysis. A supplier's 'Critical' label does not itself determine the EU legal category, and the Commission's overview does not replace the Act. It does, however, make provider documentation, security and downstream information a live procurement concern.

The United States currently depends more on supplier frameworks, contracts, sector obligations and developing standards. NIST has an AI data-centre security draft open for comment until 25 September; it is a consultation, not law. ⁵ The United Kingdom's AI Security Institute reports rapid capability growth and vulnerabilities in every model safeguard it tested, supporting independent re-evaluation without turning a UK result into a global performance claim. ⁴

Singapore is advancing assurance tooling and proposed international testing work. ⁶ In markets with less evaluation capacity, limited local-language testing or different cloud and data arrangements, a supplier's global control may be harder to verify. Keep the reauthorization trigger; adapt the evidence, reviewers, storage and escalation route.

Independent testing of Astra is not yet public, and OpenAI says its detailed system card will follow at launch. Anthropic's enterprise safeguards are not yet broadly available. The newest arXiv batch includes work questioning whether agent guardrail evaluations measure the right thing and another paper proposing progressive authority for recursive agents, but these are a workshop submission and a theoretical preprint—not deployment proof. ⁸⁹

That uncertainty argues for a reversible decision. Do not infer that the model is unsafe everywhere, or that supplier safeguards make it safe everywhere. Record which claims were supplier-assessed, what your organisation tested, what remains unavailable and the date on which authority will be reviewed again.

Add a capability-change clause to model approval and supplier management. Define the events that require review: a supplier threshold change, materially greater autonomy, new tool use, wider context, a changed monitoring architecture or credible independent findings. Name the executive who can pause inheritance and the people who can restore access.

Apply the rule to one current model upgrade. Identify which permissions would carry over automatically, which workflows could create material impact and whether monitoring follows the actual path into production. Then run the four-step gate: classify, narrow, test and restore. The result should be a short authority record, not a technical dossier—what changed, what may act, who owns it and when the decision expires.