ERC-8468: Agent Safety Framework (ASF)

What it is

ERC-8468 (Agent Safety Framework) is a draft ERC filed as ethereum/ERCs pull request #2113 by garyyang-finchip, using placeholder number 9999 until an editor assigns one. The text is at revision 6. It adds a registry that records which participant accepted which safety specification version for which subject and scope, and whether that acceptance still holds. It does not judge actions. The text requires only ERC-165, and the reference code is in the garyyang-finchip/agent-safety-framework repository.

How it works

A Safety Specification is an immutable, content-addressed, versioned document. Publishing v2 changes nothing for adopters of v1. A Safety Binding is the on-chain adoption record. The adopter is always msg.sender and is part of every identifier and index key. A binding pins one specification version for one subject and scope, and carries an external authority basis, declared enforcement locations, a validity window, named interveners and a lifecycle (Active, Suspended, Terminated). Interveners hold separate suspend, resume and terminate rights. Bindings can derive from a parent: same pinned version, validity inside the parent's, ancestors must hold, parameters never wider.

Suspension carries response requirements as a combinable bit set (no new risk, shrink, essential only, de-risk only, full stop; full stop dominates), plus the hash of a structured intervention response document.

check(requirement, bindingIds) evaluates clauses combined by all-of, any-of or k-of. A clause fixes versions, adopter, subject, scope, enforcement locations and required interveners. It returns Satisfied, NotSatisfied or Unknown with a reason and the response set in force per clause. That set is the union over the binding and its suspended ancestors, and is empty if the chain is terminated or expired. Unknown never counts as satisfied. Verdicts are never scored, and native results from external permission or policy mechanisms are kept as they are.

Two rules matter for integrators:

• A suspension recorded by an intervener cannot be lifted by the adopter. Only an account holding the resume right can lift it. The adopter can still terminate, and the terminated record keeps showing the stop.
• Since revision 6, an intervener's suspension is a standing stop keyed by (adopter, subject, specification, intervener). It outlives termination of the binding it was recorded through. While it stands, no binding of that adopter for that subject and specification satisfies a clause naming that intervener. Sibling bindings and fresh adoptions are refused with StoppedByIntervener.

A clause that names interveners also closes the resume right: the binding must not grant resume to any account the clause does not name. Revision 4 added this, and the zero-account wildcard was removed.

The registry never verifies that the adopter was entitled to adopt for the subject. Consumers check that against the permission source the binding references.

Preconditions / Affected

This matters to anyone building guarded accounts, task escrows or counterparties that need to test an agent's acceptance at the moment of effect. Two reference consumers show the pattern:

• ASFGuardedAccount: the operator may act only while the principal's binding is satisfied. "No new risk" and "de-risk only" block new exposure but allow repayment and cancellation. "Full stop" halts everything.
• ASFTaskTenderAdapter: admits only fulfillers whose own binding names the task publisher as a required intervener. It rejects unbound or publisher-suspended fulfillers. On Unknown it neither accepts nor rejects, so the kernel's judgment clock stays in force.

What to do

Read the open questions in the thread and respond if the design affects you:

• Whether profile-order rules for derived bindings should be checkable on chain rather than off chain.
• Whether the response document's inFlight rule (actions already authorized or sent) should also appear on chain.
• Whether any interest falls outside the five protected domains.
• Whether incident reports and claims should stay outside the kernel.
• Whether (adopter, subject, specification, intervener) is the right stop granularity, and whether to offer a "created before" clause member for replacement bindings.

The author specifically asks for feedback on the overlap review against the mandate, verdict, delegation and identity proposals.

Revision 5 evidence is on Sepolia (26 October 2026): 36 transactions, all successful, against the live TASK-KERNEL v3.0 TaskToken, with contracts verified on Sourcify:

• ASFSpecificationRegistry: 0x1939665F5905d0d9135Da4f27e36f1B8c84E014b
• ASFBindingRegistry: 0xc3e1A1Cb021Ab96EBBeD3279018840016114A5c4
• ASFGuardedAccount: 0x40AaD5106A7a13B15892E53099f6bD06bCF80aD3
• ASFTaskTenderAdapter: 0x51772fabFB757Fb5A4186c0435Ec4fa76D75CE4e

The transaction record is in docs/sepolia-evidence.md in the repository.

Caveats

• The Sepolia deployment is revision 5's. Revision 6 (standing stops, stopOf, interface identifier 0x2db6eb8a, 90 tests with 64 negative) is not deployed there.
• The interface identifier has changed in every revision that touched the interface: 0xb99bdc2a, then 0x1ff33bef, then 0x2db6eb8a. The requirementId values changed in revision 3 with the clause encoding. Do not hard-code earlier values.
• The registry does not decide whether an action is permitted, evaluate policy, certify alignment or prove enforcement. Declared enforcement locations are attributable commitments, and evidence and external mechanisms carry the verification.
• Revision 5 moved the registry's check into the externally linked library ASFEvaluation so it deploys within Sepolia's per-transaction gas cap. Revision 6 moved writes into a second linked library, ASFLifecycle.
• The draft is not final, and the title changed from "Agent Safety and Security Framework" to "Agent Safety Framework (ASF)" in revision 5.