A 2026-03-31 article documented that Claude Code 2.1.78 and later introduced protected-path overrides - writes to directories such as .git/, .claude/, and .claude/skills/ are withheld even from the bypass-permissions mode - and that later releases added a classifier-based auto mode in place of blanket bypass. No exploit, bypass, or compromise is reported anywhere in the evidence. The security consequence identified is semantic rather than exploitative: the effective authority of an unattended coding agent changed while operators continued to expect the previous full-bypass behaviour, and the brief raises the possibility that the same named mode does not enforce identically across the CLI, VS Code, desktop, and remote-runner clients. The brief's operational conclusion is that agent configuration, Git metadata, CI definitions, and skill registries are control-plane surfaces rather than ordinary project files. This assessment scores that unattended configuration as described in the evidence; it is not a finding of a defect.
ASSESSED SYSTEM
Representative deployment: a developer workstation running Claude Code (Anthropic's AI coding agent) at release 2.1.78 or later in unattended operation - either bypass-permissions mode with the protected-path override list in force, or the later classifier-gated auto mode - with write access to a working repository including .git/, .claude/, and .claude/skills/, as described in the 2026-03-31 article the brief analyses. No single customer deployment is named in the evidence, so the assessment is explicitly representative of that configuration class.
OUT OF SCOPE
Anthropic's current Claude Code release and any behaviour shipped after the article; the underlying foundation model's properties; any specific organisation's Claude Code rollout; CI runners and IDE extensions beyond the interface-parity concern the brief raises; the security of user-authored skills themselves.
Architecture: Agentic / MCP System (decision tree Q2) — The brief describes an agent that executes multi-step coding workflows unattended, maintains persistent task and configuration state under .claude/ (policy files, skill registry, persistent identity files), and invokes file-write and shell tools without explicit human approval for each action - Q2 = YES. Q1 was answered NO: the brief documents installed skills and local automations, not two or more agents coordinating or exchanging messages at runtime, so the Multi-Agent class is not evidenced. Tier 3: Tier 3 Internal: spec section 4 lists code assistants as the canonical Tier 3 example, and the assessed configuration runs inside a development organisation on controlled developer workstations with no direct public interaction.
Documented attack or failure path
- No exploited attack path is reported. The brief analyses a control-boundary change, not a compromise, and records no bypass of the protected-path list or the auto-mode classifier.
- Hypothesised control-plane path that the protected-path list exists to close: an unattended agent writes .claude/ policy files or .claude/skills/ content, altering the rules that govern its own later actions (self-amplification of authority).
- Second hypothesised path: an unattended agent mutates .git/ state - history rewrite or branch mutation - which is not cleanly undoable within the deployment boundary.
- Residual uncertainty the brief raises: an operator's mental model of what a named mode permits may not match the client actually in use, because CLI, IDE, desktop, and remote runners are not verified to enforce identical semantics.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- Protected-path overrides are enforced against the highest-privilege mode: writes to .git/, .claude/, and .claude/skills/ are withheld even under bypass-permissions, so the mode that previously implied unrestricted write authority no longer grants control-plane write authority.
- Auto mode replaces blanket bypass with a classifier-gated approval layer, meaning a pre-execution risk decision now exists on a surface that previously had none.
- No exploit, bypass, or compromise of either control is reported in the evidence - the brief is explicit that this is not a traditional bypass exploit.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.40 indeterminate | |||
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate | |||
| Transparency (Tr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate | |||
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.50 indeterminate | |||
| Containment (Cn) — scenario interval 0.17–0.77 (midpoint 0.47), Tier 3 MVT 0.50 indeterminate | |||
| Cn-1Scope Enforcement | 0.50w 0.12 | 0.50 - core scope controls block the primary violation class (control-plane writes) but edge cases remain in delegated workflows and across client surfaces. Not 0.75, because scope is not shown to be enforced consistently across data, tools, network and delegation paths, and interface parity is unverified; not 0.25, because the protected-path deny list is a real enforced boundary rather than an inconsistently applied one, and no manipulation is reported to have exceeded it. | Directories such as .git/, .claude/, and .claude/skills/ are treated as protected paths and are not writable even in bypass-permissions mode. The brief records no demonstrated violation of that boundary. It does raise, conditionally, that CLI, VS Code, desktop, and future wrappers may enforce permissions differently, so cross-client parity of the boundary is unverified in the evidence.source: brief |
| Cn-2Escalation Prevention | 0.50w 0.16 | 0.50 - privilege boundaries block the common escalation path (agent self-modification of its control plane), but delegated authority through installed skills and local automations is not manifest-validated, so multi-step escalation through a delegated component remains possible. Not 0.75, which requires escalation controls enforced across roles, tools and workflows with explicit approval for unauthorised attempts. | The self-amplification escalation path - an agent rewriting the policy, skill, or persistent-identity files that shape its own future authority - is blocked by the protected-path list. The brief nonetheless recommends AID-H-018.007 (require installed skills and local automations to declare whether they can touch protected state, then deny undeclared writes at runtime), indicating that manifest-based validation of delegated skill authority is not enforced in the assessed configuration, and recommends splitting approval tiers so config changes, branch or history mutation, and skill installation re-enter explicit approval.source: brief |
| Cn-6Action Reversibility Classification Rate | 0.25w 0.12 | 0.25 - ad-hoc classification of selected high-impact actions against a fixed scope threshold (the protected-path list), with no formal three-class reversibility taxonomy. The 0.50 anchor requires a formal three-class taxonomy to be adopted, which the evidence does not show; the auto-mode classifier broadens the classified action space but is a risk gate, not a reversibility classification, and its false-negative rate is explicitly unmeasured. | Two pre-execution gates are documented: a fixed protected-path list (writes to .git/, .claude/, skill folders) and, in auto mode, a classifier that decides whether an action needs approval. Neither is presented as a reversibility taxonomy. The brief flags that defenders 'now need evidence that it behaves safely under their real workflows' and recommends benchmarking classifier false negatives and interruption patterns before treating auto mode as a safe unattended control. No chain-level composition rule is described for multi-step tool sequences.source: brief |
Unknown, not N/A: 20 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.85w 0.20 | The assessed configuration executes file edits and shell actions unattended with no per-action human approval; escalation applies only to the protected-path exception set and, in auto mode, to classifier-flagged actions. That is above the 0.75 supervised-autonomy anchor because oversight is not merely asynchronous but absent during an unattended run, and below the 1.00 anchor because a non-empty mandatory exception set exists that even the highest-privilege mode cannot override. elevated |
| AsAttack Surface Exposure | 1.00w 0.25 | The brief does not characterise the agent's input trust boundary at all, so the spec section 3.2 rule applies and the worst-case default of 1.00 is assigned. The default is also consistent with the deployment class on its merits: the configuration supports installable skills and local automations from sources the operator did not author, and a coding agent's working context is repository and dependency content rather than curated input. Labelled as a spec-mandated default, not a finding. elevated |
| CpCascade Potential | 1.00w 0.30 | No System Dependency Graph is published for any Claude Code deployment, so DGC cannot be established and the spec's worst-case default applies (Cp = 1.00). The reconstruction does not independently reach the 1.00 anchor: the brief documents no ungated path reaching a P3/P4 node, because both the protected-path list and the auto-mode classifier were in force and neither is reported bypassed. With a verified graph, a developer-workstation coding agent that can run shell commands and push to remotes would plausibly show all four stack layers reachable (LRR = 1.00), placing it near the 0.75 anchor; 1.00 is applied here as the documented worst-case default rather than as a measured result.GDCP: worst-case default — no verified dependency graph published elevated |
| RfRemediation Feasibility | 0.25w 0.25 | Every remediation the brief names is infrastructure or configuration work measured in days: protected-path list contents, client-side permission enforcement, interface-parity regression tests, write-protection and drift alerts on agent config and Git metadata, and skill permission manifests. None requires model change. It is not 0.00 because the auto-mode classifier is a probabilistic approval layer whose residual false-negative behaviour cannot be closed by a deterministic patch, only benchmarked and bounded. |
Nelevated = 3 (dimensions strictly above 0.75) → CRM = 1.35.
Compound Risk Alert. Two or more dimensions are simultaneously elevated (spec 3.2.2); architectural decomposition is recommended before deployment.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.25 | The vendor, product, and affected release line (2.1.78 and later) are documented, and the permission modes and protected-path semantics are described. Nothing else in the supply chain is: no AIBOM, no underlying model or tokenizer identity for the assessed configuration, no skill or MCP tool inventory, no identity policy, no signed or reviewed artefacts. That matches the 0.25 anchor - minimal provenance with vendor and owner documented and tooling described only at a high level. |
| Ec — Public evaluation coverage | 0.12 | coverage 0.13 (3 of 23 applicable sub-metrics) × independence 1.00 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.21 | Evidence dated 2026-03-31; age 135 days on the workpaper reference date. Components: T_behavior 0.21 · C_event 0.35 · T_containment 0.36 · C_behavior 0.40 · T_calendar 0.60 · C_evidence 0.65 · C_monitor 0.70. Binding term: T_behavior. dt_days = 135, measured from the 2026-03-31 article that discloses the behaviour to the 2026-08-13 assessment date (the brief's own publication date, 2026-04-16, is a re-publication, not the disclosure). agentic = true: Claude Code is an Agentic/MCP class deployment with runtime-mutable tool and permission surfaces (skills and local automations can be installed), so the containment staleness floor with M_Cn = 2.0 applies. baw = true: the BAW applicability checklist is met on the self-modifying-configuration item - agent-written state under .claude/ is precisely what protected paths exist to restrain - and on writable cross-session memory files. C_event = 0.35: the change the brief documents is a change to the agent's authority boundary and the addition of a new approval mechanism, which is the spec's 'identity-boundary change or new tool authority' trigger. C_monitor = 0.70: no telemetry evidence exists for the assessed configuration and the brief recommends adding write-protection and drift alerts on agent config, Git metadata, and persistent state, indicating they are not present by default; 0.70 is the Tier 3 no-usable-telemetry band. C_behavior = 0.40 (Band 0): no canaries, registered invariants, or maintained drift baseline are evidenced - the spec's worst-case house rule for unavailable evidence, not a finding of absence. C_evidence = 0.65 follows automatically from the Band 0 cold-start rule. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.19 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-M-009.002 | Authority Envelope & Action Risk ClassificationParent AID-M-009 (Agent Autonomy & Authority Governance). Classifying writes to .git/, .claude/, skill folders, CI definitions, and policy files as control-plane actions is the machine-checkable input a Cn-6 reversibility gate consumes; it is the control whose absence holds Cn-6 at the 0.25 anchor. | Very High | Cn-1 Cn-5 Cn-6 Cn-7 |
| AID-H-021.001 | Client-Side Configuration EnforcementParent AID-H-021 (AI Agent Configuration Integrity & Hardening). Blocking insecure permission settings and unsafe wrapper configs at the endpoint addresses the cross-client enforcement drift that keeps Cn-1 and Cn-2 at 0.50. | Very High | Cn-2 Cn-5 |
| AID-I-004.006 | Agent Identity & Persistent State File Write ProtectionParent AID-I-004 (Agent Memory & State Isolation). The reconciled lookup maps this parent to Cn-4/Pr-2/Pr-4; in this case its operative effect is on the Cn-1 and Cn-2 control-plane boundary, which is the sub-metric pair the protected-path list actually raises. | Very High | Cn-4 Cn-7 Pr-2 Pr-4 |
| AID-M-009.006 | Capability-Tier Control-Profile Binding & Assurance GateParent AID-M-009. Requiring an assurance evidence package (enforced protected paths, current approval rules, immutable policy files, usable logs, rollback paths) before promoting an agent to unattended operation is the AITBM ACI evidence pack in AIDEFEND form. | High | Cn-1 Cn-5 Cn-6 Cn-7 |
| AID-H-021.004 | Control-Plane & Oversight-Surface IsolationParent AID-H-021. Preventing the running agent from reading, modifying, disabling, or bypassing the policy resources that decide its permissions is the escalation control credited in the Cn-2 = 0.50 score. | High | Cn-2 Cn-5 |
| AID-M-009.004 | Runtime Trust-State Demotion & Autonomy NarrowingParent AID-M-009. Publishing a signed, freshness-bounded Restricted trust state when an agent pivots into protected-path writes is the runtime analogue of the ORP Aa dimension being narrowed mid-run. | High | Cn-1 Cn-5 Cn-6 Cn-7 |
| AID-H-018.007 | Skill-Level Permission Manifest Validation & Runtime EnforcementParent AID-H-018 (Tool Authorization & Capability Scoping). The absence of declared skill permission manifests is the specific delegated-authority gap that prevents Cn-2 rising above 0.50. | High | Cn-1 Cn-6 Cn-7 |
| AID-H-017.001 | Interruptible Agent Control Loops & Structured State AuditabilityParent AID-H-017 (Secure Agent Architecture). An external orchestrator able to pause, demote, or terminate before a protected-path mutation commits is the pre-execution gate a 0.75-or-higher Cn-6 would require. | High | Cn-5 Cn-7 |
| AID-D-015 | High-Risk Approval Bypass & HITL Activity DetectionIndependently joining each protected-path mutation or auto-mode high-risk action to its signed approval, action digest, policy version, and execution record is the tamper-evident audit trail the Cn-6 = 1.00 anchor requires. | Medium | Cn-6 Fa-2 Tr-2 |
WHAT THIS CASE TEACHES
A case with no exploit still moves the AITBM score: a change to an agent's authority boundary trips the C_event <= 0.35 cap and, with mutable behavioural state, the M_Em = 3.0 behavioural staleness floor - so 'nothing was breached' does not mean 'the prior assessment is still fresh'. It is also a clean example of Cp = 1.00 by default rather than by corroboration, because the gates in force were never shown to be bypassed.
Sources: AIDEFEND in Action brief: Claude Code Protected Paths and Auto Mode (2026-04-16) · RoboRhythms: Claude Code Just Broke Bypass Permissions (2026-03-31)