Governing Claude Code with Alyria
Claude Code enterprise security starts with Anthropic's own controls: managed settings, permission rules, hooks and an OS-backed sandbox, all documented for admins. They configure the agent's session well, and Anthropic's documentation is plain that they are client-side configuration: a developer with local administrator rights can edit the managed source itself, and managed settings bind Claude Code only. Alyria Beacon adds the endpoint layer those controls leave out: one inventory, one written policy and one signed audit chain for the CLI, the IDE extensions and everything else running on the same machine.
Start with the vendor's own controls.
Each control below is named the way Anthropicnames it, and links to the vendor's documentation. Deploy them: they are the fastest path to a working baseline.
managed-settings.json
The organization's policy file, deployed to a system directory (macOS: /Library/Application Support/ClaudeCode/, Linux and WSL: /etc/claude-code/, Windows: C:\Program Files\ClaudeCode/) or delivered by MDM or server-managed settings. Nothing from user, project, local or --settings overrides it, apart from a few stricter lower-level values.
Managed settingspermissions.deny rules
Deny and ask rules such as Read(./.env) or Read(./secrets/**) enforced above every other settings level; allowManagedPermissionRulesOnly can ignore permission rules from lower files entirely.
PermissionsPreToolUse hooks
Shell commands or HTTP endpoints Claude Code runs at defined lifecycle points; a hook returns a JSON decision that can block a tool call before it executes.
Hooks referenceAllowed MCP servers
allowedMcpServers and deniedMcpServers come from the managed source, optionally locked with allowManagedMcpServersOnly so the managed list is the only list that applies.
Managed MCPSandboxing
An admin-configurable sandbox that constrains Bash filesystem and network access on supported platforms, with locks (allowManagedDomainsOnly, allowManagedReadPathsOnly) that read from every admin source.
SandboxingLogin and provider controls
forceLoginMethod, forceLoginOrgUUID and allowedProviders pin which account and which API provider a managed machine may use.
Admin setupWhat the native controls leave uncovered.
Drawn from what Anthropic states about its own limits, not from us.
The policy is on the machine, inside the agent
Anthropic's documentation states that a developer who is an administrator on the machine can edit the managed source itself, which is why the docs recommend MDM tooling redeploying the profile or file on a schedule. Where whole-machine isolation is required, the docs point to sandboxing or a container, not the settings layer.
Cloud sessions do not read device policy
A session in an Anthropic-hosted environment does not read the device's MDM profile or managed settings file; policy for those sessions has to come from server-managed settings. The file and the cloud settings are two policies to keep in sync.
Managed settings bind Claude Code only
In the words of the managed-settings documentation: other tools are outside it. A developer who calls the API from another tool isn't under them. Anything else installed on the laptop, and every MCP server other clients connect to, needs its own layer.
Hooks cannot see the fleet
Hooks run in Claude Code's own lifecycle at the decision points the client exposes. They are powerful, and the sample policy below blocks reading .env inside Claude Code; what no hook can tell you is whether any other client on any machine is configured to trust the MCP server that request would have reached.
A practical starting point.
The shape of a baseline managed policy, from Anthropic's own examples:
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./secrets/**)"
],
"disableBypassPermissionsMode": "disable"
},
"allowManagedPermissionRulesOnly": true
}What Anthropic's controls cover, and what the endpoint adds
| Area | Claude Code native controls | Endpoint governance with Alyria |
|---|---|---|
| MCP servers | Managed allowedMcpServers / deniedMcpServers lists enforced inside Claude Code, fail closed on an invalid allowlist value. | Continuous inventory of every server named in every client's config files, including stdio servers that never cross the network, with Lyra policy evaluated on every MCP call locally. |
| Secrets and regulated files | permissions.deny rules such as Read(./.env); sandbox read-path allowlists under admin locks. | Policy on what an agent may do across tools, so the rule written once also covers the CLI that is not Claude Code; Umbra leases replace standing credentials. |
| Shell and network | Bash sandboxing on supported platforms, hooks that can block a command before it runs. | Sequence policies at the endpoint, such as after reading a secret, block network egress, evaluated regardless of which agent issued the call. |
| Audit trail | Session-level telemetry to Anthropic or your endpoints; hooks can log decisions the client makes. | A signed, tamper-evident audit chain for policy decisions and MCP activity, exportable for audit and routed to your SIEM by Spectra. |
| Beyond Claude Code | Out of scope by design: managed settings bind Claude Code only. | One policy and one audit chain covering Claude Code, Cursor, Codex, GitHub Copilot and whatever ships next quarter. |
What Alyria Beacon adds.
Governance at the endpoint, not the gateway: the same policy, secrets and audit whether the agent is Claude Code or something ships next quarter.
- Alyria Beacon is a signed, user-space agent with no kernel driver: it installs read-only, about 30 minutes, and starts in monitor mode so you see what enforcement would do before anything is blocked.
- It inventories every AI tool and version on the machine and the MCP servers each one trusts, and flags down-level tools, unpinned servers and secrets left in config.
- Lyra evaluates the written policy on every model and tool call at the endpoint where the call originates, with no cloud round-trip, including for stdio servers.
- Every decision lands in one signed, hash-chained audit record; Spectra routes the same signal as OpenTelemetry into Elastic/Kibana or another SIEM.
- Umbra issues short-lived credential leases injected at the moment of use, so the agent uses secrets without storing them.
Questions security teams ask about Claude Code and Alyria.
Do Alyria and Claude Code managed settings replace each other?
No. Use both. Managed settings are the fastest way to put a policy inside Claude Code and are worth deploying regardless. Alyria Beacon covers what Anthropic's documentation puts outside the settings layer: other tools on the same machine, a developer with administrator rights, and the cloud sessions that do not read device policy.
Does Alyria Beacon put a hook in Claude Code?
No. Alyria Beacon runs beside the agent as a signed, user-space agent and acts where the call originates. It needs no hook configuration in the agent's settings and no plugin, which is what lets one policy also govern tools that have no hook API.
What happens first, inventory or enforcement?
Inventory and monitoring. Alyria Beacon deploys read-only and starts in monitor mode, so the first thing you get is a fleet-wide Agent Exposure Report of agents, versions and MCP servers, not a block.
- Native policy file
- managed-settings.json (system dir, MDM, or server-managed)
- MCP enforcement
- Allowlist and denylist inside Claude Code, managed source only
- Endpoint layer
- Alyria Beacon: signed, user-space, no kernel driver
- Rollout
- Read-only install, monitor mode first
- Audit
- Signed, hash-chained chain; OTel export via Spectra
See what your agents are wired to.
Start in monitor mode: inventory the AI tools, versions and MCP servers on every endpoint, see what enforcement would decide, and turn on enforcement when you are ready.