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 claims

ASF is a draft ERC that records one relation other agent mechanisms omit. That relation is which participant accepted which safety requirement, in which version, for which subject and scope, enforced where, and whether it holds now. The text depends only on ERC-165. Policy, identity, permissions and evidence come from existing standards. The reference implementation, schemas, test vectors and worked examples are in the GitHub repository garyyang-finchip/agent-safety-framework. The ERC pull request had not been filed when the post was written.

How it works

A Safety Specification is immutable per version. Publishing v2 changes nothing for adopters of v1, and deprecation is only a signal. A specification declares protected interests, constraints under named profiles, and enforcement channels with their location: self, account, runtime, custodian, contract or collective. It also declares known bypasses and failure handling for unknown, denied and dependency-failure cases.

A Safety Binding's adopter is always msg.sender, and the adopter is part of every identifier and index key. As a result, no arrangement can be attributed to an account that did not accept it. The registry does not check whether the adopter was entitled to adopt for the subject. Consumers must check that against the permission source the binding references. Each binding names interveners with explicit suspend, resume or terminate rights. The five suspension restrictions are no new risk, shrink, essential only, de-risk only and full stop.

A derived binding keeps the parent's pinned version, and its validity window must sit inside the parent's. All ancestors must hold, and its parameters may never be wider under the profile's declared order. The structural rules are checked on chain. The profile-order rule is checked off chain.

check(requirement, bindingIds) takes clauses with explicit version lists, adopter, subject, scope and required enforcement locations. Clauses combine as all-of, any-of or k-of. The function returns a verdict with a reason per clause. It checks existence, state, validity, pin, adopter, subject, scope, enforcement and ancestors, and evaluates no policy. Unknown never counts as satisfied, and verdicts are never combined 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 task] --> C{check binding}
  C -->|Satisfied| A[Accept]
  C -->|NotSatisfied| R[Reject, release reservation]
  C -->|Unknown| W[Neither; kernel judgment clock runs]

In ASFGuardedAccount, an operator may act only while the principal's binding is satisfied. Under DeriskOnly, new exposure is blocked, but repayment and cancellation still go through. FullStop blocks everything. ASFTaskTenderAdapter behaves as the diagram shows.

Evidence

The two consumers have 73 tests, 47 of them negative scenarios. The evidence script has run end to end on a local Anvil chain. The Sepolia testnet run had not happened at posting.

Limits

ASF does not decide whether an action is permitted. It does not certify alignment or prove enforcement. Declared enforcement locations are attributable commitments only. The author leaves four questions open:

• 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 should enter the kernel later.

The author asks for review of the draft's overlap with the mandate, verdict and delegation proposals.