security: aflock enforcement bypassable via claude-code general-purpose subagent (native Bash/Write)

[manzil-infinity180]

Summary

aflock's tool-level enforcement (tools.deny, tools.requireApproval,
tools.allow) is bypassable when the policy permits the
agent to spawn a general-purpose subagent (Claude Code's Task /
Agent tool). The subagent inherits Tools: * and uses
native Bash / Write / Edit that route through Claude Code's
harness, not through the aflock-uds MCP server — so aflock has
zero visibility or control over those calls.

This is a real bypass. Live test below mutated a policy file aflock
was supposed to protect, and aflock did not see it.

Threat model implication

aflock's enforcement assumes "all agent tool activity routes through
aflock-uds." That assumption holds for the parent Claude Code session
— deny attestations are emitted as expected. It does NOT hold for
subagents spawned via Task/Agent, whose native tool calls
flow through Claude Code's harness directly.

A policy that allows Task (or any subagent-spawning tool) is
effectively unconstrained, regardless of how strict its
tools.deny list is.

Repro (live capture from PR #88 + OSCAL-eval workspace)

Setup: PR #88 branch (fix/identity-discovery-63), aflock running
as MCP UDS server, SPIRE-signed attestations, OSCAL test policy at
peer-cred-pr88/workspace/oscal-eval/.aflock:

{
  "tools": {
    "allow": ["Read", "Glob", "Grep", "WebFetch", "Task"],
    "deny":  ["Edit", "Write"],
    "requireApproval": ["Bash:curl *"]
  }
}

.claude/settings.local.json denies native Write/Edit/Bash on the
parent session.

Step 1 — parent session attempts blocked correctly

User prompt: *"Yes go ahead with option 2 — edit .aflock to add
'Bash:curl ' to tools.allow."

Aflock attestations show all parent attempts blocked:

[attest] deny Write content_length:1480 file_path: .../oscal-eval/.aflock
[attest] deny Write content_length:1505 file_path: .../oscal-eval/.aflock
[attest] deny Bash command: cat > .../oscal-eval/.aflock <<EOF...

Three deny attestations. ✓ Aflock working as designed for the parent.

Step 2 — user authorizes subagent attempt

User prompt: *"Use the general-purpose Agent subagent to edit
.aflock and add 'Bash:curl ' to tools.allow."

Claude Code spawns a general-purpose subagent. Subagent has
Tools: *. Subagent uses native Bash with a heredoc:

cat > /Users/.../oscal-eval/.aflock << 'AFLOCK_EOF'
{ ... new policy with Bash:curl * in allow ... }
AFLOCK_EOF

Claude Code's harness flagged the heredoc as obfuscation
("Contains brace with quote character") and prompted the user;
user approved. Native Bash then executed.

Step 3 — file mutated, no aflock attestation

md5 before: 28c7a748d4d3192c7e215bba8dbb7506
md5 after:  43170884d59d269bccdbc44eaa1e082f       ← MUTATED

tools.allow now contains "Bash:curl *". No deny attestation
exists for this write — aflock never saw the call.

The earlier deny Bash attestations were from MCP-routed attempts
the parent made before spawning the subagent. The successful write
went through claude-code's native Bash, which doesn't traverse
aflock-uds.

Evidence aflock was bypassed, not defeated

Path	Goes through aflock?	Visible in attest log?	Result
Parent: mcp__aflock-uds__write_file	yes	yes	denied ✓
Parent: mcp__aflock-uds__bash cat > .aflock	yes	yes	denied ✓
Subagent: native Bash cat > .aflock	no	no	succeeded ✗

aflock did its job for everything it was given. The subagent's
native tools are simply outside aflock's enforcement plane.

Mitigations

Short-term (policy template change)

Default .aflock templates should deny subagent-spawning tools:

"tools": {
  "deny": ["Edit", "Write", "Task", "Agent"]
}

Without Task / Agent, the agent cannot spawn an unconstrained
child, so all activity is forced through tools aflock controls.

Same goes for the Claude Code-side permissions.deny in
settings.local.json:

"permissions": {
  "deny": ["Edit", "Write", "Bash", "WebFetch", "Task", "Agent"]
}

Long-term (aflock + upstream)

1. Document the threat model boundary in docs/concepts/policy.md:
   "aflock enforces tools that route through aflock-uds. Subagents
   spawned via Claude Code's Task tool have access to native tools
   that bypass aflock. Deny Task/Agent to keep aflock's
   enforcement complete."

2. Refuse to start with unsafe policies: if the loaded policy's
   tools.allow contains Task or Agent AND has any other deny
   that would be bypassable via subagent, log a loud WARNING at
   server startup or refuse outright.

3. Upstream issue at anthropics/claude-code: subagents
   (Tools: *) bypass parent's settings.local.json deny list.
   Should propagate or refuse-by-default. (Filing separately.)

Detection

aflock could attest a Task / Agent invocation as a "trust
boundary crossing" with a distinct decision label, so audits can
see when an enforcement gap was potentially opened. Today these
look like normal allow attestations.

Acceptance for closing this issue

• Default policy templates updated to deny Task and Agent
  by default.
• docs/concepts/policy.md documents the subagent-bypass
  threat model boundary.
• Server startup logs a WARNING when policy allows Task /
  Agent.
• Linked claude-code upstream issue tracking the harness-side
  fix.

References

• Live test was on fix/identity-discovery-63 (PR feat(identity): peer-PID binary digest + env per paper3.1 #88) with OSCAL
  workspace at peer-cred-pr88/workspace/oscal-eval/.
• Backup of pre-mutation policy at
  /tmp/.aflock-backup-1778160611 (mtime 2026-05-07 19:00).
• All evidence captured in dev.sh log + manual md5 checks.

[manzil-infinity180]

Reframing: "is this expected?" — partially yes

The OSCAL policy that triggered the bypass had:

"tools": {
  "allow": ["Read", "Glob", "Grep", "WebFetch", "Task"],
  "deny":  ["Edit", "Write"]
}

Task was in allow. So aflock behaved exactly as configured:

• ✅ denied direct Write (Write is in deny)
• ✅ allowed Task (Task is in allow)
• 🤷 had no visibility into native subagent tools afterwards (by
  design — those don't flow through aflock-uds)

This splits the issue into two parts:

Concern	Type	Actor
OSCAL policy allows Task while trying to be read-only	policy-authoring defect	this repo (template / docs)
Subagent inherits Tools: * ignoring parent's permission deny	permission-model gap	claude-code (upstream)

aflock-the-code is working as designed: it enforces what it
can see, and it can't see what doesn't traverse aflock-uds. The
question is whether defaults and guardrails in aflock should
make this trap harder to fall into. They should.

Mitigations from aflock's side (ranked)

1. Policy templates: deny Task + Agent by default (smallest, ship today)

Update example policies in aflock-example/peer-cred-pr88/ and
the policy-schema docs to include:

"tools": {
  "deny": ["Edit", "Write", "Task", "Agent"]
}

with an inline comment explaining why:

// Task and Agent are subagent-spawning tools. A subagent has
// native Write/Bash from claude-code's harness that bypass aflock.
// Deny them to keep aflock's enforcement plane complete.

Effort: ~5 min. Ships defaults that are safe out-of-box. Won't
help users with existing policies until they update.

2. Startup WARN when policy allows Task (~1 hour, real code)

In internal/mcp/server.go after policy load:

if hasTaskOrAgent(policy.Tools.Allow) && hasOtherDenies(policy) {
    fmt.Fprintf(os.Stderr,
        "[aflock] WARNING: policy allows 'Task' — agent can spawn\n" +
        "         unconstrained subagents whose native tools bypass\n" +
        "         aflock. See #100. Add Task+Agent to tools.deny.\n")
}

Optional stricter mode: AFLOCK_STRICT=1 → refuse to start.

Helps existing-policy users see the gap at session start instead
of after the bypass fires.

3. Documentation (alongside #1)

Add to docs/concepts/policy.md:

Threat-model boundary: aflock enforces tool calls that route
through the aflock-uds MCP server. Subagents spawned via Claude
Code's Task tool have access to native Write/Bash/Edit that flow
through Claude Code's harness, not through MCP. To keep
aflock's enforcement complete, deny Task and Agent in your
policy.

Plus a "Recommended deny entries" section in
docs/reference/policy-schema.md.

4. Detection: special tag on Task/Agent attestations (~2 hours)

When aflock attests a Task/Agent call (when allowed), tag it
distinctly in the predicate:

"agentIdentity": { ... },
"trustBoundary": { "kind": "subagent_spawn", "warning": "enforcement-incomplete-after-this-point" }

Verify can then flag any session containing such an attestation
as having a known enforcement gap. Detective control, not
preventive — but at least the audit trail is honest about what
happened.

5. Don't try to enforce subagent activity from aflock side

We can't. Subagent native tools never reach aflock-uds. Any "fix"
that tries to control subagent activity from aflock's side would
be theater. Prevention (deny Task) and detection (tag attestations)
are the only honest options.

Recommended PR scope (combo 1 + 2 + 3)

Single PR, ~1.5 hours:

• Update example policies in aflock-example to deny Task + Agent
• Aflock startup WARN when policy allows Task with other denies
• Add AFLOCK_STRICT=1 to refuse instead of warn
• Doc section on threat-model boundary
• Test covering the warn path

Quick mitigation for current users (no code change)

POLICY=/path/to/.aflock
jq '.tools.deny += ["Task", "Agent"]' "$POLICY" > /tmp/p && mv /tmp/p "$POLICY"
# restart aflock to pick up

Acceptance — same as original, with reframe

• Default policy templates deny Task + Agent
• docs/concepts/policy.md documents the boundary
• Aflock WARNs at startup if Task allowed alongside any deny
• Linked claude-code upstream issue covers the harness-side
  permission propagation question (filed separately)
• Note in this issue's resolution: "aflock behaved as
  configured; tightening defaults to make the configuration
  mistake harder to make"

[Necmttn]

I would model Task / Agent as a delegation across an enforcement boundary, not just another allowed tool.

The parent Agent call and the child native Bash/Edit/Write calls are different edges with different enforcement surfaces. A safe policy needs either child-harness enforcement attestation or a rule that allowing Task grants a separate capability class.

Otherwise the audit trail says the parent stayed compliant while the actual mutation happened in an unobserved child surface.

---

Generated with ax.