Gary Yang opened an Ethereum ERC pull request on October 25 proposing registries that record which account accepted a particular version of an agent’s operating requirements. The Agent Safety and Security Framework, or ASF, remains a Draft proposal in open, unmerged PR 2113. Its document uses 9999 as a placeholder, not an assigned ERC number.
The design separates a reusable Safety Specification from a Safety Binding. A specification is a content-addressed document with immutable versions. A binding identifies the adopting account, subject, scope, chosen version, validity window and declared enforcement locations. Publishing version two would not silently rewrite an account’s acceptance of version one. Each binding would pin the specification’s content hash; changing a document’s locator would leave that hash and existing adoption unchanged.
A registry check would return Satisfied, NotSatisfied or Unknown, with reasons. Consumers could require all listed clauses, any clause or a specified number. These results concern the registered adoption relationship. They do not decide whether an action is permitted or demonstrate that a declared control actually operates.
The filing includes Solidity reference interfaces and consumer examples. In the proposed account example, an operator’s execute call would consult the binding registry before forwarding a call. For a pending submission on the task adapter’s judged path, Satisfied leads to acceptance, NotSatisfied to rejection, while Unknown reverts and leaves the task’s existing judgment clock in force. These are code examples in the proposal, not executed demonstrations or evidence of a live integration.
Applications would still have to verify that an adopter can represent the named subject, fetch and verify referenced documents, and apply their own permission rules. The record identifies who made a commitment and the version they chose; it does not certify an agent.
A separate draft ERC-8419 KYA model covers assertions about agents, a related registry question.