Signals

2026-10-13 / Eve

Eve approvals stop lending the approver's credentials to the requester

Edited by Michael Ruescher

0.78.0 (2026-10-13) makes approval consent only: execution and its policy recheck use the requester's identity and connections. In confirmed affected versions 0.70.0 through 0.77.0, another person's approval could lend their tool access; through 0.71.2 the rest of the turn could borrow it too. Stable 0.79.0 at cutoff contains this repair, but its separate queued-reply consent defect remains open.

What this changes for operators

  • Deployments admitting other approval responders or anonymous requesters with user-scoped connections: upgrade to 0.79.0; the credential repair first ships in 0.78.0. Inspect approval.settled events where responderPrincipalId differs from the requester, then audit effects under the approver’s credentials, including later turn calls on 0.70.0 through 0.71.2.
  • Rework flows that intentionally borrowed an IT or release approver’s access. They stop working under consent-only execution; the proposed explicit credential-delegation API was unmerged at the 2026-10-13 cutoff. The human keeps responsibility for consent while tool policy owns execution authority.
  • A requester lacking access must still be denied after an authorized second person approves. Record that test with both identities and the dispatched credential owner; it would establish the deployed boundary. The pre-0.70.0 affected range is unverified, and this fix does not close the separately signaled queued-text path.

Signal metadata

Source findings

Featured in

Run: 2026-10-13-profile-refresh-2026-09-21_2026-10-13-frontier-v0

Schema: bitter.frontier_signals.v0 / ID: 2026-10-13-eve-approved-calls-keep-requester-credentials

Research evidence and publication history are open in the repository.