TL;DR: Sort your AI hardening list into two columns before you pay for a plan upgrade. One column holds settings your plan enforces, where users can't change them. The other holds settings it only requests. Anthropic's Claude Code docs show where that line sits today, and a personal account sits on the wrong side of it.
Key takeaways:
On September 30, 2026, a security analyst at a credit union asked me for a numbered hardening list and a one-page security case for a plan upgrade. My two answers on the upgrade didn't match, and this post fixes that.
The gap between policy and enforcement came up on four client calls between September 21 and October 5, 2026.
Anthropic's documentation, checked October 22, 2026, ranks managed settings above every user and project file. Nothing a developer sets can override a managed key.
The same documentation says server-delivered settings are a client-side control on unmanaged devices, and a person who signs in with a personal account never receives them.
Plan contents change. Read the vendor's page on the day you write the memo, and sort your list first.
What does your AI plan enforce, and what does it only request?
An enforced setting is one a user can't change. A requested setting is one you ask people to follow. Sort every item on your hardening list into one of those two columns before you spend money. The sort shows which items need a purchase and which only need a decision.
A rule you enforce holds on the day someone is in a hurry. A rule you request holds until they are.
Anthropic's Claude Code documentation draws this line itself. It ranks settings from highest to lowest: managed settings, command line, project local, shared project, and user. A managed key wins over the same key anywhere below it. Nothing in a developer's own files overrides it. Your administrator delivers managed settings from the company admin console, or pushes them to machines through device management.
Why did a plan upgrade look like the security answer?
Because the analyst who asked me had no other lever. She had a policy, an approval council, an intake form, and a spreadsheet of every approved tool. Her own words for what was missing: "there's an AI policy, but maybe there's a gap in enforcement."
On that September 30 call she asked for two things. First, a short list in order, "something that I should do as number 1 compared to number 5." Second, one page she could show executives on what the higher plan buys in security terms. Her team used Claude on the Team plan, and she told me Enterprise cost the same.
I gave two answers that pulled apart. Early in the call I said Enterprise is where the governance features sit. Later I said managed settings for Claude Code don't need Enterprise. Both had some truth. Neither was useful, because plan contents change.
So I checked the vendor's page on October 22, 2026. Anthropic's server-managed settings documentation says the feature is available for Claude for Teams and Claude for Enterprise customers. For that one control, the upgrade case didn't hold. Enterprise may still earn its price on other grounds, and this post doesn't judge those.
The question that lasts is the sorting question: which lines on my hardening list can the plan we have enforce, and which are only requests? A law firm asked a version of it on October 8, 2026. It had already picked Enterprise and wanted to know which risks on its own register were the real ones.
Which settings can nobody override?
Rules you put in managed settings. Anthropic's example enforces a permission deny list, such as blocking reads of .env files and a secrets folder. It also switches off the option that lets developers bypass permission prompts, and it limits permission rules to the ones the administrator wrote. Managed settings can also run an audit script after every file edit.
Each of those is a lock. A developer can't switch it off from a laptop.
Even a lock has edges, and the documentation says so. A rule that blocks curl matches the command as Claude writes it. It doesn't match a full path or a command wrapped in a shell. For network limits that don't depend on command text, Anthropic points to a sandbox allow-list of domains. Test each enforced rule by trying to undo it. A rule you haven't tried to break is still a request.
Where does enforcement still leak?
At four places, and the documentation names all of them. Anthropic describes server-delivered settings as "a client-side control, not a security boundary" on unmanaged devices.
A personal account. Settings aren't delivered to accounts outside your organization. The analyst found this hole herself: an approved site reached with a personal account looks the same to the firewall. I proposed single sign-on (SSO, one company login) so the work account is the only door.
A different provider. Setting a third-party provider variable, or a custom base URL, makes the client skip the settings fetch.
The first launch. With no cached copy and no connection, Claude Code runs without server-managed settings. A setting called
forceRemoteSettingsRefreshmakes it refuse to start instead.An unmanaged laptop. Anthropic says endpoint-managed settings, pushed through device management, give stronger guarantees because the file can be protected at the operating system level.
Each leak is also an event worth a ticket. The post on what a SOC should alert on first for AI use shows how to turn them into a short watch list.
How do you build the two-column list this week?
Write every hardening step on one line. Beside each, ask one question: can a person with a laptop undo this? If yes, it goes in the request column. If no, and you've tried, it goes in the enforced column.
Here are four lines from a sample list, sorted by the documentation:
Block reads of secrets files: enforced, when it's a managed deny rule. A request, when it lives in a team wiki.
Stop developers from bypassing permission prompts: enforced, through a managed setting.
Limit permission rules to the ones the administrator wrote: enforced, through a managed setting.
Keep staff off personal accounts: not a settings job. It needs sign-in control and network control.
Then price the upgrade against the request column only. If the plan you have enforces what you need, you keep your money. If it doesn't, you have a written reason.
The same sort answers a question the law firm's director of DevOps asked on October 8: could a configuration file in each repository set limits for a coding agent? The documentation calls that file shared project settings. It ranks below managed settings, and anyone with the repository can edit it. Treat it as a team default. Put the rules you can't lose in managed settings. My earlier post on who approves the code your AI agent wrote covers the policy side of coding agents.
Frequently asked questions
What goes first on the list?
A company account requirement comes first. Next come settings users can't override, then what each tool can reach, then action features kept off until someone reviews them, then logs sent to your security monitoring system. Open one step at a time.
Does the Team plan include managed settings?
Anthropic's server-managed settings page, read on October 22, 2026, lists Claude for Teams and Claude for Enterprise. Plans change. Read the page again on the day you decide.
Can a managed setting stop a determined developer?
Not on every machine. On unmanaged devices Anthropic says the control is client-side. Device management gives you a stronger lock, and watching for the leaks gives you the rest.
Who owns the request column?
One named person owns the whole list. Each request needs an owner and a way to show the rule is followed, such as a screenshot or a log line.
How do I make the case to executives?
Show the two columns. Enforced items have a lock and a test. Requested items have an owner and evidence. That's a security story a leader can read in one minute.
A setting you haven't tested is a request. Write it in the right column with a name beside it, and say so out loud.