[garyyang-finchip]

Adds the Agent Safety Framework (ASF): a registry of versioned, content-addressed safety specifications and of the scoped, attributable adoption relations (Safety Bindings) that bind agents and other subjects to them, with a registry-level check that consumers evaluate at the time of effect. The core requires only ERC-165.

Discussion: https://ethereum-magicians.org/t/draft-erc-agent-safety-framework-asf-a-registry-of-versioned-safety-specifications-and-of-the-scoped-attributable-adoption-relations-that-bind-agents-to-them/30073
Reference implementation, schemas, vectors, worked examples and two closed-loop consumers: https://github.com/garyyang-finchip/agent-safety-framework

[eip-review-bot]

File ERCS/erc-8468.md

Requires 1 more review from Editors: @g11tech, @jochem-brouwer, @samwilsn, @xinbenlv

[abcoathup]

Suggested change

	eip: 9999
	eip: 8468

Assigning next sequential EIP/ERC/RIP number.
Numbers are assigned by editors & associates.

Please also update the filename.

[abcoathup]

Suggested change

	discussions-to: https://ethereum-magicians.org/t/draft-erc-agent-safety-framework-asf-a-registry-of-versioned-safety-specifications-and-of-the-scoped-attributable-adoption-relations-that-bind-agents-to-them/30073
	discussions-to: https://ethereum-magicians.org/t/erc-8468-agent-safety-framework-asf/30073

Updated Eth Magicians title with assigned number & ERC title

[eip-review-bot]

All Reviewers Have Approved; Performing Automatic Merge...

[eip-review-bot]

All Reviewers Have Approved; Performing Automatic Merge...

[garyyang-finchip]

Renamed to ERCS/erc-8468.md and assets/erc-8468/, and updated discussions-to — thank you @abcoathup.

The HTMLProofer failure after the rename is the cached _site/all.html and _site/erc.html from this PR’s previous CI run still linking to /EIPS/eip-9999; the incremental Jekyll build does not regenerate the index pages, so the stale links survive the rename. The new page and its assets check clean, and the same content passed HTMLProofer at the previous head (acb2cff). A re-run once this PR’s Jekyll cache has turned over should clear it; I can close and reopen the PR to re-trigger whenever that is useful.

[github-actions]

The commit 182f5a8 (as a parent of 85278f5) contains errors.
Please inspect the Run Summary for details.

[garyyang-finchip]

Closing and reopening to re-run CI. The only HTMLProofer failures are all.html and erc.html linking to /EIPS/eip-9999 from the cached index; the branch itself uses eip-8468 throughout.

[agentcontrolmap]

A suspend-only guardian (rights = RIGHT_SUSPEND, no RIGHT_RESUME) can be permanently locked out of its FULL_STOP escalation path by the adopter itself, with no recovery available to the guardian.

Sequence:

1. Guardian holds RIGHT_SUSPEND only, binding is Active.
2. Adopter calls suspend(id, RESTRICT_DERISK_ONLY, ...) on their own binding.
3. Guardian calls suspend(id, RESTRICT_FULL_STOP, ...) to escalate — reverts with InvalidState.
4. Guardian calls resume(id, ...) to try to clear the state first — reverts with NotAuthorized (no RIGHT_RESUME).
5. The binding stays at DERISK_ONLY — strictly weaker than what the guardian was trying to enforce — until the adopter, and only the adopter, decides to resume it.

Reproduced against the reference implementation, re-verified today (2026-11-12) against the latest commit (d0f2de7, 2026-11-02) — 4 tests, all passing:

• control: guardian-only suspend to FULL_STOP works as expected when the adopter hasn't acted first.
• the lockout itself: confirmed as described above.
• scope limit, stated honestly: a guardian that also holds RIGHT_RESUME can still recover, but only in two sequential calls (resume, then suspend) — and this is itself a race: if the adopter re-suspends between the guardian's two calls, the guardian's second call reverts again.

This isn't the already-documented direction (Rationale: "a guardian suspends, the adopter resumes in the next block") — that one's intended. This is the reverse ordering: the adopter acting first, at a weaker restriction level, blocks the guardian from ever reaching a stronger one. The recent fix (test_N68, union-of-named-stops visibility) addresses a different issue and doesn't touch this — the revert still happens at the write-path state check. Security Considerations doesn't appear to cover an escalation-ordering case like this.

Net effect: for a guardian scoped to RIGHT_SUSPEND only — a named, tested configuration in the reference implementation itself, not a contrived role — the adopter has a one-call, no-cost way to permanently neutralize that guardian's ability to ever reach FULL_STOP, for as long as the adopter chooses to leave the binding at the weaker level.

Happy to share the test file if useful.

[agentcontrolmap]

(duplicate — see comment above)

[garyyang-finchip]

A suspend-only guardian (rights = RIGHT_SUSPEND, no RIGHT_RESUME) can be permanently locked out of its FULL_STOP escalation path by the adopter itself, with no recovery available to the guardian.

Sequence:

1. Guardian holds RIGHT_SUSPEND only, binding is Active.
2. Adopter calls suspend(id, RESTRICT_DERISK_ONLY, ...) on their own binding.
3. Guardian calls suspend(id, RESTRICT_FULL_STOP, ...) to escalate — reverts with InvalidState.
4. Guardian calls resume(id, ...) to try to clear the state first — reverts with NotAuthorized (no RIGHT_RESUME).
5. The binding stays at DERISK_ONLY — strictly weaker than what the guardian was trying to enforce — until the adopter, and only the adopter, decides to resume it.

Reproduced against the reference implementation, re-verified today (2026-11-12) against the latest commit (d0f2de7, 2026-11-02) — 4 tests, all passing:

• control: guardian-only suspend to FULL_STOP works as expected when the adopter hasn't acted first.
• the lockout itself: confirmed as described above.
• scope limit, stated honestly: a guardian that also holds RIGHT_RESUME can still recover, but only in two sequential calls (resume, then suspend) — and this is itself a race: if the adopter re-suspends between the guardian's two calls, the guardian's second call reverts again.

This isn't the already-documented direction (Rationale: "a guardian suspends, the adopter resumes in the next block") — that one's intended. This is the reverse ordering: the adopter acting first, at a weaker restriction level, blocks the guardian from ever reaching a stronger one. The recent fix (test_N68, union-of-named-stops visibility) addresses a different issue and doesn't touch this — the revert still happens at the write-path state check. Security Considerations doesn't appear to cover an escalation-ordering case like this.

Net effect: for a guardian scoped to RIGHT_SUSPEND only — a named, tested configuration in the reference implementation itself, not a contrived role — the adopter has a one-call, no-cost way to permanently neutralize that guardian's ability to ever reach FULL_STOP, for as long as the adopter chooses to leave the binding at the weaker level.

Happy to share the test file if useful.

Thanks @agentcontrolmap — reproduced and fixed in revision 9 (50ccc0e, pushed 2026-11-14). An intervener holding RIGHT_SUSPEND can now suspend a record that is already suspended; the registry widens the record (union of sets, a non-zero responseRef replaces, suspendedBy moves to the intervener) instead of reverting, so an adopter's earlier DERISK_ONLY suspension no longer blocks a guardian's FULL_STOP. The adopter's own re-suspension stays invalid. Change confined to ASFLifecycle; new tests N70–N72; suite 98 / 72 negative. Details and the Sepolia plan: https://ethereum-magicians.org/t/30073/29

For reviewers: revision 9 is text + reference implementation only; the interface and encoding are unchanged from revision 8.

[agentcontrolmap]

Follow-up to revision 9 (commit 71dac3d): your 98 tests pass, and six extra tests for the pre-emption scenario pass beside them. Details and the test file are in the Magicians thread: https://ethereum-magicians.org/t/erc-8468-agent-safety-framework-asf/30073/31