Claude Code — Governance Capability Matrix
Superseded. The maintained, evidence-cited matrix is L0-L3 Capability Matrix. This page predates that consolidated matrix and is retained only as legacy detail — not, as an earlier revision of this page claimed, because any
aa-devtool-saassource comment references this directory (none do; that claim was wrong and has been removed). Where the two disagree, the rendered matrix wins.
Governance level: L2Enforce
Detection: which claude / ~/.claude directory marker
MCP support: Yes
Managed settings: Yes
| Capability | Status | Reason |
|---|---|---|
| network deny | Yes | Proxy (aa-proxy) intercepts and enforces network egress deny rules for the managed launch; Claude Code’s managed settings carry no network-restriction keys, only permissions.* tool patterns and MCP allow/deny lists (aa-devtool-claude-code/src/apply.rs) |
| network allowlist | Yes | Same as network deny — proxy-only; managed settings have no native network-allowlist config |
| file read | Partial — eBPF | Proxy cannot inspect local filesystem operations, so eBPF is the only path — and it is a detection path, not an enforcement one. The probes are kprobes/kretprobes on the openat/read syscalls (aa-ebpf-probes/src/main.rs); uprobes in this tree attach to OpenSSL only. They are observe-only: a PATH_BLOCKLIST hit sets an alert flag on the emitted event and the syscall proceeds. Linux-only, and these file-I/O kprobes are x86_64-only (hardcoded __x64_sys_*) |
| file write | Partial — eBPF | Same as file read — kprobes on write / unlink / rename, observe-only, same platform bounds. Nothing here blocks a write |
| process spawn | Partial — eBPF | eBPF tracepoint on sched_process_exec is the detection path; no SDK is embedded in Claude Code to govern spawns directly |
| MCP allowlist | Yes | The adapter writes enabledMcpjsonServers / disabledMcpjsonServers into the managed settings.json (aa-devtool-claude-code/src/apply.rs) — not a separate mcp_servers.json |
| sub-agent lineage | No (L0) | Claude Code sub-agents are not registered, get no topology entry and no per-child policy scope — see the L0-L3 Capability Matrix. No SDK is embedded in Claude Code |
| prompt redaction | Yes — on the LLM host | Redaction runs on what the proxy decrypts, and llm_only defaults to true: only the built-in LLM providers plus any operator or integration mitm_hosts entry are MitM’d, and every other host is transparently tunnelled and never scanned (aa-proxy/src/config.rs). Claude Code’s api.anthropic.com traffic is in the built-in set, so its prompts are covered; the MCP-registry and telemetry endpoints it also calls are not |
| response redaction | Yes — on the LLM host | Same scope as prompt redaction: inbound bodies are scanned on MitM’d hosts only. A tunnelled host’s response is never decrypted, so nothing in it can be redacted |
| budget enforcement | Yes | Gateway tracks spend from proxy-observed request/response pairs for the managed launch — no SDK is embedded to emit cost events directly |
| audit ingestion | Yes | The managed launch injects AA_AGENT_ID and the proxy records the requests it intercepts for that process (measured: two /v1/messages POSTs, an MCP-registry GET and a telemetry POST for one headless run — AAASM-5276). It is not a complete record: the prevention-evidence sink is bounded and lossy by design — it drops on a full channel and deletes on rotation, counting both in its SinkCompleteness sidecar (AAASM-5449). There is no SDK-level semantic event stream |
Notes
Claude Code declares L2Enforce, the same static ceiling as the Codex, Copilot
and Windsurf adapters. No adapter declares L3Native, and no Agent Assembly SDK
is embedded into Claude Code — governance is applied through managed settings,
the intercepting proxy and (on Linux) eBPF.
GovernanceLevel is a static, self-declared ceiling in any case. What is
actually protecting a Claude Code install, and the evidence for it, comes from
the protection ladder reported by aasm integrations status — see
Protection Levels.
Last updated: 2026-08-14 by Chisanan232