Paperclip’s consent card can approve a different change

paperclipai/paperclip issue #10714 is the inspected primary source: “Change-consent gate binds an accepted `request_confirmation` to a target key, not to the approved content.” The two related records below were inspected as supporting context, not treated as independent confirmation.

The facts

- paperclipai/paperclip issue #10714 was created 2026-08-02T23:25:16Z and was open at inspection; its title is “Change-consent gate binds an accepted `request_confirmation` to a target key, not to the approved content.” - paperclipai/paperclip issue #10717 was created 2026-08-03T00:42:42Z and was open at inspection; its title is “Link resolved board verdicts to external subjects (subjectRef + decision-lookup API) and detect contradicting agent actions.” - paperclipai/paperclip PR #10713 was created 2026-08-02T21:58:24Z and was open at inspection; its title is “fix(security): replace 2 unsafe curl Bearer patterns in secrets skill examples (BLU-26477).” - The repository reported 75444 stars, 4992 open issues, default branch master, and last push 2026-08-03T00:56:44Z. - The latest tagged-release baseline checked was v2026.722.0 published 2026-07-22T23:05:41Z.

What changed

paperclipai/paperclip issue #10714 reports: Summary assertConsented() in server/src/services/change-consent-gate.ts is the consent gate for agent-authenticated changes to protected agent configuration — the instructions bundle, the agent profile fields, and company skills. It requires an accepted request_confirmation interaction for the change's **target key**. It never compares the approved change to the change that is actually applied. Approval is bound to a *target*, not to a *diff*. One accepted card therefore authorizes an arbitrary later write to that target: different content, a different file path, or a delete where an edit was approved. All line citations are against master 717684ad8f5f33fd3b6e8cf7a96aa7062d8ff29b. What the gate checks change-consent-gate.ts:165-175, the row predicate: The SQL that produces those rows (:141-163) filters on companyId, createdByAgentId, kind = 'request_confirmation',

paperclipai/paperclip issue #10717 reports: Problem When multiple agents in one company act against a shared external system (e.g. GitHub) under a single agent-identity/PAT, a resolved decision (via request_item_verdicts / request_confirmation) can be silently reversed by a later, unrelated agent action on the same external subject. Concretely, we hit this shape: 1. A board verdict resolves a question about an external subject (e.g. "should GitHub issue #N be closed?"). 2. An agent acts on that resolution correctly. 3. Minutes later, a *different* agent — with no visibility into the resolved verdict, because it only lives in the requesting issue's interaction history — takes a contradicting action on the same subject, citing stale context (e.g. a checked-in planning doc that predates

paperclipai/paperclip PR #10713 reports: Summary Fixes 2 curl -H "Authorization: Bearer $PAPERCLIP_API_KEY" patterns in the ## Reading Granted Secrets section of skills/paperclip/SKILL.md (lines 455 and 462 on master at the time of PR #8872's branch point) Replaces both with the safe _auth() { printf... } | curl --config - pattern from PR #8872 The token is now piped via stdin into curl's config, keeping it out of process argv (/proc/*/cmdline is world-readable) Related Parent fix: #8872 (contains the safe pattern; these 2 violations were added to master after its branch point) BLU-26477 — tracking issue BLU-18566 — original security fix BLU-18563 — parent tracking issue Test plan [ ] Both examples in ## Reading Granted Secrets use _auth

Why it matters

Approval without content binding is theatre. Durable decisions need an immutable digest, exact mutation scope and a queryable subject reference; otherwise one accepted card can authorize a different edit and another agent can unknowingly reverse a settled verdict. The operational test is whether persisted state, execution authority and visible user outcome describe the same event. Broad retries, hidden suppression or permission expansion can hide the symptom while making the boundary less trustworthy.

Current

The primary record was open when captured on 2026-08-03. The release baseline was v2026.722.0 published 2026-07-22T23:05:41Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts HTML row were checked. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/paperclipai/paperclip/issues/10714. Supporting records are https://github.com/paperclipai/paperclip/issues/10717 and https://github.com/paperclipai/paperclip/pull/10713. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Bind consent to exact bytes plus path and verb, require a real diff, consume approval once, and make external actions attributable by agent and run. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.