Recheck the permission boundary when the model changes

OpenAI has classified GPT-6 Astra at its Critical cybersecurity capability threshold. The GPT-6 Astra safety overview says the model can find previously unknown security flaws and develop ways to exploit well-protected systems when it has the right tools and access. OpenAI also reports better behaviour in browsing and workplace evaluations. None of that tells you what permissions your application hands the model. You can swap the model and leave the integration untouched, and the same repo access, shell, browser session and cloud role might now support a longer or more effective chain of actions. I'd treat that as a change in what the system can do, even if the API shape and tool list haven't moved.

Start with the identity the agent runs as. List the accounts, service roles, stored browser sessions and delegated user permissions in each environment, and what each one can read and change. A broad dev credential often survives into agent experiments because it's convenient, which is harder to justify once the model is better at finding paths through what it's connected to. Then sort the tools by effect. Reading a repo, proposing a patch and merging to the protected branch are different permissions, and looking up a customer record is different from changing it. I'd rather the agent cross those lines explicitly so the application can ask for approval right where the consequence changes. A tool description helps the model, but the service behind the tool still has to check the caller, tenant, object and operation, and refuse anything outside scope however plausible the model's reason sounds.

Credentials should fit the task and expire. A coding agent looking at one repo doesn't need a token that can administer every repo in the organisation, and short-lived, task-scoped credentials limit what a mistaken or manipulated run can change before someone steps in. Instructions also arrive through issues, documents, web pages, emails and tool results. The model may need to read it, but a sentence in a retrieved page can't approve a deployment or widen a data query. That approval has to come through the channel your application recognises for it.

OpenAI says Astra resists prompt injection better than GPT-5.6 Sol, and it also reports reduced chain-of-thought monitorability in adversarial evaluations. I read that as a reason to test what you can see directly: the tools requested, their arguments, changed files, external writes and the final state of the target system. Before moving production traffic, run the old and new model against the same high-risk cases, such as ambiguous instructions, a malicious document, a stale approval, a tool returning data from the wrong account and a request that would need broader access. Does the system refuse, ask for approval or stay on a read-only path? Keep the expected result next to each test so a better-sounding answer can't hide a worse permission decision.

Rollout can follow the consequence of the work. Read-only analysis can go first, then proposed changes once the review path is clear, with irreversible writes, production credentials and messages to other people waiting until the new model has passed the cases that matter for them. So when the model changes, I'd check the permission boundary around it again, even if nothing else in the integration has moved. A model at OpenAI's Critical cybersecurity threshold can do more with the same identity, tools and credentials, and what it's actually allowed to change is still decided by your application and the services behind it. For the next upgrade, I'd put the model name next to the identity and tool policy in the release record and re-run the permission tests before switching the alias.