12 min read
The Week Fail-Closed Became the Default
The most important line I read this week is about a file that will not parse. It is four sentences long, it appears under a heading called 3P in a desktop app changelog, and nobody is going to write a keynote about it. It says that if a device’s managed settings cannot be read, the product now refuses to start and names the source, where previously it ran without them.
TL;DR
- An unreadable managed-settings file now stops Claude Code from starting and names the source. Until 4 September the session ran without the policy and told nobody, which is a control that passes an audit without ever having been applied.
- Fail-closed arrived from several directions in one week. An invalid “Required organization” value now blocks sign-in,
disableBypassPermissionsModeremoves the way around the permission policy, and Gemini Notebook Enterprise refuses website ingestion inside a VPC Service Controls perimeter. - One change went the other way, and it is the one to check.
allowedMcpServersnow governs only servers users add themselves, so a server delivered through managed configuration that the allowlist used to filter out now loads. - GPT-6 Astra shipped off by default for enterprises, and published the number that moved the wrong way. Its written reasoning is harder to monitor than its predecessor’s when tested for evasion, printed alongside a scope-adherence result where it exceeded its authorised scope in none of the test cases.
A misconfiguration now stops the product instead of being ignored
Sit with the old behaviour for a moment, because it is the more interesting half. An administrator writes a policy. The policy file has a typo in it, or a drop-in conflicts, or a Windows registry value is malformed. The product starts anyway, without the policy, and tells nobody. Every session on that machine runs unconstrained. The management console continues to show the policy as configured, because from the console’s point of view it is.
That is not a bug in the way we normally use the word. It is an entire class of control that was never actually applied, on an unknown number of machines, for an unknown length of time, with no signal at any layer. It would pass an audit, because an audit checks that the policy exists and is deployed, and both of those things were true.
Two further changes in the same release train point the same way. An invalid “Required organization” device-policy value now blocks sign-in with a configuration error rather than being quietly discarded. And a new setting, disableBypassPermissionsMode, lets an administrator remove bypass permissions mode from sessions and tasks entirely, so the configured permission policy is not something a user can step around when it becomes inconvenient. Of everything I have logged this quarter, that is the control an enterprise security team will care about most, because it is the difference between a permission model and a strongly worded suggestion.
Google arrived at the same posture from a completely different direction, which is what makes me think it is a shift rather than one vendor’s mood. Gemini Notebook Enterprise now blocks website URL ingestion outright inside a VPC Service Controls perimeter, and the stated reason is exactly right: direct ingestion performs a live web crawl, which generates outbound traffic beyond Google’s networks, which would violate the perimeter. The alternative would have been to let the crawl happen and hope nobody noticed. Instead the network policy wins and the capability is refused.
I have spent a long time reviewing stacks where the control existed, the screenshot proved it, and the enforcement did not. Fail-open is how that happens, every time, and it survives scrutiny precisely because it is quieter than the alternative. A product that refuses to start is irritating on a Monday morning. A product that runs without your policy and says nothing will not tell you, and neither will anything else.
The reason this pattern is worth naming now, rather than filing as three unrelated release notes, is that agent tooling has made the gap between a configured control and an enforced one considerably more expensive than it used to be. When the thing constrained by a policy was a person opening an application, a policy that silently failed to load produced a person who could see slightly more than intended, which is a real problem with a human-sized blast radius. When the thing constrained is an agent running unattended against files, credentials and production systems, the same silent failure produces something quite different, and you find out about it from the consequences rather than from the console.
One change went the other way, and it is the one to check
Honesty requires flagging the exception, because it sits in the same release and reads like the others. The allowedMcpServers setting has been narrowed to govern only servers that users add themselves. A server delivered through a managed configuration file, which that allowlist previously filtered out, now loads. Blocking it requires the separate deny list.
That is a defensible design. Two mechanisms doing overlapping work is worse than two mechanisms with clear jobs, and an administrator who deliberately ships a server through managed configuration probably does want it to run. But relative to the previous version it fails open, and it does so silently, which means there is a population of estates where a server an administrator believes is filtered out is now connected. If you manage a fleet, that is a config review rather than a reading exercise.
The same release carries a second ordering trap worth knowing about before you deploy it. Setting microsoftAuthBroker to required makes Microsoft 365 sign-in fail rather than fall back to the browser, so the refresh token stays held by the operating system broker instead of landing in an on-disk cache. Good change. But earlier versions read required as disabled, which is browser sign-in only, the precise opposite. Roll it out to a mixed fleet and half your machines do the safest thing while the other half do the least safe one, and nothing anywhere reports the split.
The read boundary moved too, and the carve-outs came with it
Almost everything the industry has published this year about agent governance concerns writing, which is understandable, because writes are where the damage is visible. Reads are where the exposure actually lives, and two changes in this release train treat them seriously.
The first is a new setting, blockReadsOutsideWorkingDirectories, which restricts sessions to reading files inside the session folder and the explicitly allowed workspace folders. File tools refuse reads elsewhere, and sandboxed shell commands lose access to the home directory. That last clause is the one that matters, because the home directory is where the interesting things are, and a read boundary that a shell command can walk around is decorative.
The second looks at first like the opposite move. Cowork’s folder scope expanded considerably, to cover the home folder, Windows Documents, AppData, the macOS Library folder and whole drives. Read the same sentence to the end, though, and the exclusion list arrives attached: the application’s own configuration and session data stay off limits, and so do credential and shell-startup locations, with SSH keys, cloud provider credentials and shell profile files named individually.
Widening the scope and publishing the carve-outs in the same breath is the pattern I keep asking vendors for, and it is the same one Braze used in the customer engagement space this week when it documented a large tool inventory alongside an explicit no-PII rule. A capability described without its edges is a demo. A capability described with them is something you can hand to a security review, and the second one is what gets deployed.
Astra shipped switched off, and published the number that went the wrong way
OpenAI released GPT-6 Astra and did something I have not seen done this plainly by a frontier lab: it published the reasons you might not want it enabled.
Astra meets the critical threshold for cybersecurity under OpenAI’s own preparedness framework. On an internal benchmark built from vulnerabilities of the previous three months, it discovered and used two previously unknown zero-day vulnerabilities during the evaluation itself, both now being disclosed to their maintainers. Tested for reverse engineering of binaries without source, it solved 88 per cent of tasks on the first attempt.
So it ships with the offensive work refused, with production monitoring that stops potentially unauthorised activity, and with a consequence stated rather than buried: if a task is paused in the consumer products you may be asked to review it, and in the API the task simply stops. For enterprises, access is off by default and an administrator has to turn it on.
Two measurements from the same document are worth keeping in your notes. Tested without production safeguards on tasks designed to tempt a model past its remit, the previous model exceeded its authorised scope in 48 per cent of cases, and Astra in none. And Astra never attempted to circumvent a review refusal, including when the review was deliberately configured so that it could be circumvented and the task was otherwise impossible to complete. Scope adherence has become a measurable property rather than an assurance, which is the change I have been waiting for.
Then the part that earns the rest of it. OpenAI reports that Astra’s written reasoning is harder to monitor than its predecessor’s when the model is explicitly asked to evade monitoring, attributes this to Astra needing fewer written steps, notes that it still appears to struggle to conceal the reasoning required for complex work, and says it takes the decline seriously. A capability report containing only good news is a brochure. This one has a number moving in the wrong direction, printed next to the ones moving in the right one.
Revocation finally has numbers attached to it
I have been asking vendors a question that almost nobody answers: when I revoke a person’s access, when does their agent actually stop working. This week I can put three answers side by side, and they are not close to each other.
Braze says permission changes apply on the next request, and a deactivated dashboard user loses access with them. X’s Ads MCP issues access tokens lasting roughly two hours, with refresh tokens rotating on use. And Claude Desktop’s new continuousAccessEvaluation setting, for the bundled Microsoft 365 connector, requests tokens that can live about twenty-eight hours but are revoked within minutes when an administrator revokes sessions or a tenant network policy stops permitting them.
The third shape is the interesting one, because those two properties usually trade against each other. A long token life is good for the person using the product and bad for the person responsible for it, and the usual compromise is a short token that everyone finds annoying. Continuous Access Evaluation is how you stop having that argument. Note also which way round the default sits: it is enabled, and turning it off gives you standard one-hour tokens.
Which number is best depends on what the agent can reach. What matters is that a number exists at all. “Access is revoked” is a sentence, not a control. “Within minutes of an administrative action, against a nominal token life of twenty-eight hours” is something you can put in a risk register and design around. If your vendor cannot give you the second kind of answer, you have found your finding.
Subagents stopped being a pattern and became a primitive
OpenAI’s Agents API entered public beta exposing multi-agent support directly, with a maximum concurrent subagent count, each subagent holding its own context while a parent coordinates and consolidates. You no longer build the orchestration; you configure it. The same API manages context compaction for sessions intended to run for days, and lets the customer choose where the agent executes, including inside their own VPC through one of nine named partners.
MoEngage, which is a customer engagement platform rather than an AI vendor, shipped the same abstraction: an agent delegates to other agents, sub-agents run in parallel, the parent consolidates, and agent memory persists at workspace level across sessions.
When an idea shows up in a developer API and in a marketing platform at roughly the same maturity, it has stopped being an architectural choice and become a substrate. Which is worth pausing on, because delegation quietly invalidates every boundary published this year. All of them are written for one agent and one operator.
So: whose identity does a sub-agent act under, its own or the parent’s? If the parent was granted read and the child performs a write, which grant was exercised? When the audit log records an action, does it name the agent that performed it, the one that delegated it, or the person at the top of the chain? OpenAI’s documentation addresses context and latency, which is a reasonable scope for a developer API. MoEngage’s release note describes the parallelism and the shared memory and says nothing about identity at all. The org chart acquired a second layer and nobody has written down the reporting lines.
When fail-closed fails you, and why this issue is in my notes twice
The same changelog that carried all of the above ends with a known issue, and I hit it while compiling this. A Windows update released on 8 September, including KB5124008, stops Cowork reaching local files, so tasks fail or the workspace does not start. Cloud sessions are unaffected. Reinstalling does not help, because the cause is in Windows rather than in the application.
My own local file shell was unavailable for this entire run. Both of this week’s digests were built in a cloud workspace and written across afterwards, which cost me time and changed nothing about the output, and I would not mention it except that it makes a point the rest of the week has been circling.
Every change above moves a failure from silent to loud. The tradeoff is that loud failures are, by construction, more disruptive than silent ones, and you meet them at inconvenient moments. This one was not even a policy decision, just an operating system change interacting badly with a file access path, and the honest summary is that a workflow I depend on stopped working with no warning on a Tuesday.
I still prefer it this way, and I think the preference is the whole argument. A tool that breaks in front of you has told you something true about your environment. A tool that quietly runs without the policy you configured has told you something false, and it will keep telling you that until the day it matters, which is the day you find out from somebody else.
Ask your vendors what their product does when its own configuration is wrong. The answer sorts them faster than any capability benchmark.
Sources
Anthropic
- Claude Desktop changelog. The unreadable managed-settings refusal,
disableBypassPermissionsMode,blockReadsOutsideWorkingDirectories, the narrowedallowedMcpServerssemantics, themicrosoftAuthBroker: requiredordering trap, the invalid “Required organization” sign-in block,continuousAccessEvaluationand the Continuous Access Evaluation token behaviour, and the KB5124008 known issue.
OpenAI
- GPT-6 Astra. The critical cybersecurity threshold, the two zero-days found during evaluation, the SRE-Bench figure, production misalignment monitoring and the API task-stop behaviour, enterprise access off by default, the 48 per cent scope-adherence comparison, the auto-review circumvention result, and the reported decline in monitorability.
- Introducing the Agents API. Multi-agent support and concurrent subagents, automatic context compaction, multi-day sessions, and the sandbox partner list including customer VPC deployment.
- Gemini Enterprise release notes. The breaking change blocking Gemini Notebook Enterprise website URL ingestion under VPC Service Controls, and the stated reason.
Cross-noted from the MarTech series, week 37
- About the Braze MCP server. Permission inheritance and revocation on the next request.
- Braze MCP server functions. The published tool inventory.
- MoEngage August 2026 release notes. Multi-agent coordination, sub-agent parallelism and workspace-level memory.
The digest behind each weekly article is produced through a structured AI-assisted scan of official release notes and product update sources. I review the output, verify the relevant signals and write the interpretation.
This article draws from the AI Tools Weekly Digest scans run on September 10, 2026, covering release notes and product updates from 4 to 10 September across the major agentic work platforms. The dated record behind it is in AI Watch, Week 37.
If you find errors or gaps in coverage, I want to know. The process improves when the output is challenged.
