Draft ERC: Agent Safety Framework (ASF) — attributable adoption of versioned safety specifications

What it claims

ASF is a draft ERC (placeholder number 9999, ethereum/ERCs PR #2113) for a registry that records the relation between an agent's existing control mechanisms: who accepted which safety requirement, in which pinned version, for which subject and scope, enforced where, and whether it is in force now. Its only normative dependency is ERC-165. It does not judge whether an action is permitted, does not evaluate policies, does not certify alignment, and does not prove enforcement. Declared enforcement locations are attributable commitments only.

How it works

A Safety Specification is an immutable, content-addressed document. It covers protected interests, constraints under named profiles (over an action, a state, a trajectory, a group, or a relation between trajectories), and who may adopt or enforce it. It also lists expected evidence, enforcement channels with a location (self, account, runtime, custodian, contract or collective), known bypasses, failure handling for unknown, denied and dependency-failure cases, and pre-accepted remedies. Publishing v2 does not affect adopters of v1. Deprecation is only a signal.

A Safety Binding is created by the adopter, which is always msg.sender. The adopter is part of every identifier and index key, so the registry cannot attribute a binding to an account that did not make it. The registry does not check whether the adopter was entitled to adopt for the subject. Consumers verify that against the permission source the binding references. A binding names interveners with explicit suspend, resume or terminate rights and moves through three states: Active, Suspended or Terminated. A suspension carries one of five restrictions: no new risk, shrink, essential only, de-risk only, or full stop.

Derived bindings must keep the parent's pinned version, sit inside the parent's validity window, and keep all ancestors holding. Their parameters must never be wider under the profile's declared order. The structural part of this rule is checked on chain. The profile-order part is off chain, which is one of the open questions.

check(requirement, bindingIds) evaluates clauses that carry explicit version lists, adopter, subject, scope and required enforcement locations. Clauses combine as all-of, any-of or k-of. The check returns Satisfied, NotSatisfied or Unknown with a reason for each clause. Unknown never counts as satisfied, and clause verdicts are never merged into a score. The resource's own authority rules decide which bindings it requires, so a subject cannot substitute a looser one.

flowchart TD
  F[Fulfiller offers binding] --> C[check requirement]
  C -->|Satisfied| A[Accept tender]
  C -->|NotSatisfied| R[Reject, release reservation]
  C -->|Unknown| W[Neither; kernel judgment clock runs]

Evidence

The draft includes two reference consumers. In ASFGuardedAccount, the operator can act only while the principal's binding is satisfied, and no code path skips the check. A guardian's DeriskOnly suspension blocks new exposure but still allows repayment and cancellation. FullStop blocks everything.

ASFTaskTenderAdapter accepts token-bound task tenders only from fulfillers holding their own binding. It handles the three verdicts as the diagram shows. The two consumers have 73 tests, 47 of them negative scenarios.

How to use it

The repository garyyang-finchip/agent-safety-framework holds the reference implementation, schemas, test vectors, worked examples and both consumers. The page gives no install commands, licence or contract addresses.

Limits

The evidence script has been rehearsed end to end on Anvil only, and the Sepolia run is still pending. The ERC number is not yet assigned. The author asks four open questions, which signal unsettled design:

• whether the kernel should normalize denial reasons from external policy mechanisms;
• whether profile-order checks for derived bindings should move on chain;
• whether five restriction values are the right granularity;
• whether incident and claim records belong in the kernel.

The author also asks for review of overlap with the existing mandate, verdict and delegation proposals.