Claude Code Security: How to Govern the Agent Running in Your Terminal

Claude Code is not a coding assistant that suggests. It is an agent that acts. In a normal session it executes bash commands, writes files across the repo, installs dependencies, and connects to MCP servers. Every one of those actions runs with the same permissions as the developer who launched it: their credentials, their SSH keys, their cloud access.

That is precisely what makes it productive, and precisely what makes it an endpoint-security problem. It is also a problem your existing stack cannot see. SaaS-side security tools watch OAuth grants and app traffic. Claude Code operates in a terminal, a plane where CASB, SSPM, and SSO logs have no visibility at all.

Claude Code ships with real safety machinery: permission prompts before sensitive actions, configurable allow and deny rules, and read-only defaults. For an individual developer on an individual machine these are good controls, and you should use them.

Their limits are structural, not qualitative. Every setting is per-developer and per-machine. Nothing aggregates across terminals, nothing enforces a single policy org-wide, and no security team can see what was allowed or denied anywhere. Approval fatigue works against the model too. After the fiftieth prompt, "allow always" becomes the default reflex, and those decisions accumulate silently on each laptop.

Claude Code exposes a hook system, and its PreToolUse hook is the enforcement point that per-developer settings are not. Before any tool call executes, a local, synchronous policy check runs. If the action violates policy, the hook returns permissionDecision: deny with a stated reason, and the tool never acts. The agent sees the denial and the reason, then moves on.

This is where destructive bash commands, writes to protected paths, and installs from non-allow-listed registries get stopped, before execution rather than in a post-hoc log review.

Blocking handles the actions you predicted. Audit handles the ones you did not. Per-terminal session capture records who did what, in which repo, on which terminal: every file change with a protected-file flag when a policy-guarded path was touched, every dependency install, every blocked action with its reason, and token usage and cost per turn. When someone asks what the agent changed and why, the answer is a trail rather than an interview.

Privacy is a tier, not an afterthought. By default Nexus stores metadata-only fingerprints, meaning prompt fingerprint and length, never prompt text. Deeper capture is an explicit opt-in per repository. That is what makes per-terminal telemetry deployable in organizations where recording developer prompts would be a non-starter. This trail is one layer of a broader AI agent governance program, and the observability half is covered in agent observability.

Ten controls, no gate. Apply them in order. The first four stop the highest-impact incidents.

One command: nexus wrap claude. It installs the hooks, starts the collector, and runs Claude Code governed, either by default or opt-in per run. Policy modes are per repository: enforce (deny violations in-flight), audit (record would-be blocks as findings without blocking), or off. The audit-first path lets you fit policy to real workflows before turning enforcement on.

The capture and enforcement layer is open source, so you can verify exactly what is recorded. The Nexus console adds the org-wide view: agent inventory, identity graph, shadow-AI findings, and the audit ledger. For agent-generated failures you will meet along the way, the errors hub covers the common ones, and Swfte security describes our own practices.