Draft ERC: Agent Safety Framework (ASF) — a registry of versioned safety specifications and of the scoped, attributable adoption relations that bind agents to them

What it is

ASF is a draft ERC on Ethereum Magicians that standardizes two objects, one check and one composition rule. A Safety Specification is a versioned, content-addressed document. A Safety Binding is an on-chain statement that an adopter accepted one pinned spec version for one subject and scope. The text requires only ERC-165, and a reference repository (garyyang-finchip/agent-safety-framework) holds the implementation, schemas, test vectors and worked examples. The ERC pull request had not been filed when the page was written.

How it works

Specifications carry protected interests, applicability, constraints under named profiles, enforcement channels (self, account, runtime, custodian, contract, collective), known bypasses, failure handling for unknown, denied and dependency failure, and pre-accepted remedies. Versions are immutable, so publishing v2 does not change what v1 adopters accepted. Deprecation is only a signal.

The adopter is always msg.sender and is part of every identifier and index key. The registry therefore cannot attribute a binding to an account that did not accept it. Whether the adopter was entitled to act for the subject is checked by consumers against the permission source the binding references, never by the registry.

Bindings can be derived from a parent. The derived binding must use the same pinned version and a validity window inside the parent's, all ancestors must hold, and parameters may never be wider under the profile's declared order. The on-chain rule is structural. The parameter-order rule is checked off chain.

check(requirement, bindingIds) takes clauses, each with a version list, adopter, subject, scope and required enforcement locations. Clauses combine by all-of, any-of or k-of. It returns Satisfied, NotSatisfied or Unknown, with a reason per clause. It tests only existence, state, validity, pin, adopter, subject, scope, enforcement and ancestors. It evaluates no policy, never scores, and never counts Unknown as satisfied. The resource's own authority rules decide which bindings it requires, so a subject cannot substitute a looser set.

flowchart TD
    A[Consumer calls check] --> B{Verdict}
    B -->|Satisfied| C[Action proceeds]
    B -->|NotSatisfied| D[Action blocked]
    B -->|Unknown| E[Treated as not satisfied]
    E --> F[Tender adapter: neither accept nor reject]

Preconditions / Affected

Consumers must read the binding and its permission source themselves. A declared enforcement location is an attributable commitment, not proof of enforcement. Evidence and the enforcing mechanisms carry the verification.

What to do

The page asks for feedback on four questions:

• Is the registry-level check the right boundary, or should the kernel normalize denial reasons from external policy mechanisms?
• Is splitting derived-binding rules between on-chain structure and an off-chain profile order acceptable?
• Is five restriction values the right granularity for suspensions?
• Should incident and claim records enter the kernel later?

It also asks for review of the overlap with the mandate, verdict and delegation proposals.

The two reference consumers show the check at an execution boundary:

• ASFGuardedAccount: the operator may act only while the principal's binding is satisfied. Suspension under DeriskOnly blocks new exposure but lets repayment and cancellation through. FullStop blocks everything, and no path skips the check.
• ASFTaskTenderAdapter: it admits only fulfillers holding their own binding. It rejects an unbound fulfiller and releases the reservation. On Unknown it neither accepts nor rejects, so the kernel's judgment clock stays in force.

Caveats

The page states that ASF does not decide whether an action is permitted, evaluate policies, certify alignment or prove enforcement. The evidence script has been rehearsed on Anvil only, and the Sepolia run is still to come. The page gives no gas costs or deployment addresses.