LESSON · 21 SEPTEMBER 2026
Managed settings and hooks: controlling coding agents from the inside
The verdict
Coding agents can be configured centrally, so an administrator sets permission rules, hooks and allowed MCP servers that users cannot override, and hooks let a policy inspect each tool call before it runs. It is the most precise place to control an agent, but it only covers agents that offer such settings, so pair it with a device inventory.
By Best AI Security editors · 21 September 2026 · 3 min read
What are managed settings?
Most coding agents read configuration from files on the device: which tools the agent may use without asking, which commands are blocked, which MCP servers it may load and which hooks run. A user can usually edit their own copy. Managed settings are a copy the organization controls, deployed through device management, that take precedence over the user's. They turn a policy document into configuration the agent enforces.
What are agent hooks?
A hook is a point in the agent's lifecycle, for example just before a tool call runs or just after a result comes back, where the agent hands control to an administrator's code. That code sees the tool name and arguments and can allow the call, block it or ask the user. Because the hook runs inside the agent, it sees each call with its arguments, including calls to local MCP servers that no network gateway would see.
What do tools on this site document?
| Tool | What its public pages say about agent settings and hooks |
|---|---|
| Bay | Managed settings for Claude Code, Codex and Claude Desktop: lock permission rules, preserve managed hooks, restrict MCP servers and constrain plugin sources. |
| Lasso Security | Connects to Claude Code's lifecycle hooks through the enterprise management platform and inspects every tool call before it is executed. |
| Zenity | Blocks or modifies a dangerous tool call before it executes, through native agent hooks and the Zenity MCP gateway. |
| Harmonic Security | Governs at the MCP layer and at the tool surface, with permissions for which systems agents can read, write to and act on. |
What should be locked centrally?
- The list of allowed MCP servers, and whether users may add their own.
- Permission rules for shell commands, package installs and cloud CLIs, matching your allow, ask or deny policy.
- The hooks themselves, so a user or an injected instruction cannot remove them. Bay's wording, "preserve managed hooks", describes this.
- Plugin and extension sources, so the agent installs only from approved marketplaces.
What are the limits?
Settings and hooks exist only where an agent vendor provides them, and they differ between agents and versions. An agent that a developer installs without management, or a new agent released next month, sits outside them until someone notices it. That is why an inventory of every agent on every device comes first; see how to inventory AI agents and MCP servers. It is also why settings should be checked for drift: a managed file that has been replaced or removed should raise an alert.
How do you roll it out?
- Inventory which coding agents and versions run on which devices.
- Write the allow, ask or deny rules once, then express them in each agent's managed settings.
- Deploy through the MDM or EDR tooling you already use, starting with a pilot team.
- Run new rules in a monitoring or simulation mode before enforcing them. Bay documents a Simulation Mode; ask other vendors whether they offer one.
- Send hook decisions to your SIEM so they sit with the rest of your security record.
Next lesson
Related
Sources
- Bay, Ghostjacking · Reviewed Sep 2026
- Lasso Security, AI coding assistants · Reviewed Sep 2026
- Zenity, coding and personal agents · Reviewed Sep 2026
- Harmonic Command · Reviewed Sep 2026