What Is an Agentic AI Managed Setting? Not Editable

Agentic AI managed settings are the permission rules an administrator sets above the developer. No project file, local file, or command-line flag can loosen them. That is the whole idea. The rest of this post is the how.

Last week I wrote about the circuit breaker and prompt injection. Both of those assume the rules hold. This one asks the question: who can edit the rule? You cannot govern what a developer can edit. You can govern what only the admin can.

What is an agentic AI managed setting?

In Claude Code, settings live in five places. From the top: managed settings, command-line flags, the local project file, the shared project file, then the user’s own file. Anthropic’s permissions documentation puts managed settings first and says no other level can override one. Not even a flag at launch.

A managed setting is any rule delivered through that top layer. An admin ships it by MDM, an OS policy store, a file called managed-settings.json, or the admin console. The developer cannot edit it because the developer does not own the channel.

So the definition is short. A managed setting is a rule the person running the agent cannot change.

Why does the edit right matter more than the rule?

Because a rule someone can delete is advice. I said that about skill.md last week, and it holds here. A project settings file is checked into git. Anyone with commit rights can open it, remove a deny line, and push. The agent then runs with the rule gone, and nothing in the log says why.

Agentic AI managed settings close that hole from the other side. The rule sits where the developer has no write access. In my work in regulated loan origination, this is the difference an auditor cares about. Not what the rule says. Who could have changed it, and when.

How do allow, ask, and deny resolve?

Claude Code checks rules in a fixed order: deny first, then ask, then allow. The first match wins, so a narrow allow cannot carve an exception out of a broad deny. A managed deny on git push beats every allow below it, however specific.

One line in the docs matters more than the rest. Claude Code enforces permission rules, not the model. A prompt or a CLAUDE.md file shapes what the agent tries, but it does not change what the harness permits. That is the harness doing the governing, which is where I have argued it belongs since Govern the Harness.

What can a managed setting not do?

It cannot see the command the way the operating system sees it. A Bash rule matches the text the agent writes. Deny rm and the agent can still reach /bin/rm or wrap the call in a subshell. Anthropic says this plainly: a Bash rule is not a security boundary around the program.

So I treat agentic AI managed settings as the policy layer and pair them with the sandbox for the OS layer. Anthropic’s sandboxing page gives filesystem and network isolation that holds even when a prompt injection gets past the model. Two layers, two failure modes, one policy.

Which keys do I lock first?

Three, in this order.

First, disableBypassPermissionsMode. Bypass mode skips every prompt, including writes to .git and .claude. Locking it out is the one change I would make before any other.

Second, allowManagedPermissionRulesOnly. This key makes agentic AI managed settings the only source of permission rules, so Claude Code ignores every project and user rule. That is stricter than most teams want on day one. But it is the setting that makes the audit answer clean.

Third, the deny list itself. Credential paths, git push, the shell network tools. Small, explicit, and boring.

Where does this sit in the six layers?

Enforcement. Agentic AI managed settings are the hook’s older sibling. A hook runs code before a tool call, while a managed setting decides whether the call is even on the table. In regulated origination I want both. Still, if I could keep only one, the deny rule the developer cannot edit wins.

Can a developer on your team remove a permission rule with a single commit? If yes, you have advice, not governance.

Bottom line

Instructions in, results out was IT. Intent in, outcomes out is agentic AI. But intent only becomes an outcome inside a boundary, and a boundary the developer can edit is not one. Agentic AI managed settings are the boundary the developer cannot edit. I go deeper on this in Intent In, Outcomes Out and Earned Autonomy.

Question for the comments: who owns your managed-settings file today and does that person sit in engineering or in risk?

Go deeper

Agentic AI Architect: control design for enterprise agents.
Agentic AI Case Studies: deployment evidence, one teardown at a time.
Agentic AI P&L: cost, payback, and risk in a CFO’s voice.
Agentic AI SDLC: the lifecycle that builds the agents.
Substack first access: agenticaiarch.substack.com/subscribe

Dr. Harish Kotadia, Ph.D., is an Enterprise AI Architect with 20+ years of IT consulting experience serving Fortune 100 clients, specializing in agentic AI systems built on Anthropic Claude, AWS Bedrock, and Google Vertex AI.

Disclaimer:

This blog post is based on publicly available academic publications, vendor documentation, open standards, and news items from reputed media sources linked above. This post is intended for educational purposes, to help the enterprise agentic AI community build a shared vocabulary from public, authoritative sources.

Views and opinions expressed here are my own and do not represent those of any employer or client, past or present. The analysis presented is my independent interpretation of the published sources linked above and does not constitute legal, financial, or consulting advice of any kind.

What Is an Agentic AI Managed Setting? A Rule the Developer Cannot Edit