Claude Code security

Runtime guardrails for Claude Code workflows.

Claude Code can be enormously useful because it can inspect code, run terminal commands, edit files, and drive developer workflows. Those same capabilities need identity, policy, runtime controls, and audit evidence.

Hooks are useful signal, not the whole control

Tool hooks can provide rich structured intent: command text, file paths, tool names, and request context. That makes them valuable for developer experience and early policy checks.

Security teams should still treat hooks as cooperative. The primary enforcement boundary should live at the runtime layer so subprocesses, shell chains, and direct file access inherit policy even when the agent does not follow the clean tool path.

Controls teams should require

  • Agent and session identity for each Claude Code run.
  • Default-deny reads for `.env`, private keys, cloud credentials, and database URLs.
  • Terminal command policy for destructive commands, shell pipes, and background processes.
  • Approval-gated edits to auth, payment, infrastructure, CI/CD, migrations, and production config.
  • Audit reports that show commands, files, denials, approvals, redactions, and final session status.

Where AgentGuard fits

AgentGuard is being built as the runtime layer around coding agents. For Claude Code, the intended shape is hooks for structured signal, process wrapper enforcement for actual behavior, and audit logs that a security reviewer can trust.

Claude Code can propose. The runtime should decide what executes.

Using Claude Code in a security-sensitive repo?

Talk to Securie