Claude Code hooks vs sandbox vs managed settings vs IAM: what each stops

the short answer

A sandbox limits what an agent’s process can touch: files, network, system calls. A hook-level policy decides whether a specific action should happen: this terraform destroy, this DNS delete. IAM and SCPs decide what the credentials can do at all. Harness managed settings lock one tool’s configuration, and device MDM delivers all of it. You need several; none replaces the others.

Sandbox: Process boundary: files, network
Hook-level policy: Per-action decision with context, before the call runs
IAM / SCP: What credentials can do, regardless of who or what uses them
Managed settings: One harness’s configuration, locked
Device MDM: Delivery and drift correction for all of the above

Side by Side

Layer	Stops	Does not stop	Cross-harness
Device MDM (Jamf, Intune, Kandji)	Missing or tampered config files, uninstalled clients	Any specific agent action	Delivers to all
Harness managed settings	Bypass mode, unmanaged permission rules, obvious command strings	Other spellings, scripts and wrappers; other harnesses	No
Sandbox (for example Claude Code Seatbelt or bubblewrap)	Writes outside the workspace, unapproved network egress	Destructive API calls over allowed network; reads of most of the disk by default	Per harness
IAM, permission sets, SCPs	Anything the credentials are not allowed to do	Allowed-but-wrong actions	Yes (credential-level)
Hook-level policy (Failproof)	Specific actions by effect and context, across supported harnesses; records each decision	Actions on harnesses or events without a blocking hook	Yes

What the Claude Code Sandbox Does and Does Not Cover

It is an OS-enforced boundary around Bash commands and their child processes: Seatbelt on macOS, bubblewrap on Linux and WSL2. Native Windows runs unsandboxed.
It is off by default; enable it with /sandbox or sandbox.enabled.
Writes are limited to the working directory and temp. Reads cover most of the machine, including ~/.ssh and ~/.aws/credentials, unless you add denyRead paths.
Network goes through a proxy with an allowlist that starts empty. If your allowlist includes AWS endpoints, a sandboxed aws route53 delete still succeeds.
File tools, MCP servers and hooks run outside it.

IAM and SCPs: The Floor

Service control policies set the maximum permissions in member accounts of an AWS Organization, including for root, but do not apply to the management account. They are ideal for “nobody deletes hosted zones in prod outside break-glass”. They cannot express “the agent should not, but the engineer may”, because both use the same role session. That distinction is what the hook layer adds.

Which Do You Need?

If your concern is...	Start with
Agents exfiltrating data to arbitrary hosts	Sandbox network allowlist, plus an egress policy
Agents destroying infrastructure	Hook-level deny on destroy, plus scoped profiles and SCPs
Agents disabling their own controls	A policy client agents cannot disable (`block-failproofai-commands`), plus Cloud-managed policies that a local pause does not affect
Developers bypassing settings	Device MDM redeploying managed files
No idea what agents are doing	Agent telemetry across the fleet
Several harnesses in use	A cross-harness policy engine

FAQ

Is a devcontainer enough?

A container limits the filesystem and processes, much like a sandbox. If credentials are mounted into it, the agent can still use them for any allowed API call.

Can a sandbox and Failproof run together?

Yes. The sandbox constrains the process; Failproof gates each tool call at PreToolUse, before it runs.

Which layer gives an audit trail of agent actions?

The agent layer: a hook-level tool like Failproof, or the harness’s own telemetry (such as Claude Code OpenTelemetry), records the prompt and tool call. Cloud audit logs record the API call and the human’s role session.

Sources

Checked against the sources below on October 21, 2026. Harness settings, hook capabilities and cloud features change between versions.