Summary

  • A 31 October individual Internet-Draft proposes Selo, an architecture for agents to negotiate typed access agreements between legal entities. It is a discussion document, not an adopted protocol.
  • The agents can negotiate. A deterministic checker under the owner's signed mandate controls signatures, and both sides must test the agreement before production access begins.
  • A change to payment details needs a new signed version, finance-role approval, notice that bypasses both agents, a cancellation window and the paying side's human confirmation before the first payment to the new details.

The account number is where the agent's mandate ends

The supplier's agent sends a tidy amendment: use this new account for future payments. In an ordinary connector, the field might look like just another update. In Selo's proposal, it is a change to the commercial deal. The old details stay in effect while the parties have time to object. A person with a finance role must approve the new version; people on the paying side must hear through a route that neither agent controls. Before the first payment goes to the new details, a person on that side must confirm them.

The draft offers 72 hours as an example of the waiting period. It sets no universal 72-hour timer. That detail matters: a good headline about a clock would become a bad contract if it quietly turned an example into a rule.

Selo's wider design explains why the payment change is special. Agents owned by verified legal entities can negotiate a structured agreement, but an isolated checker decides whether the owner's signed limits permit a signature. Both entities sign; replacing an agent does not replace a contracting party. After signatures, the runtimes test every exchange. Production credentials appear only after both sides confirm those tests.

The provider's gateway then checks a short-lived, key-bound token against the agreement version, active status, endpoint, operation, fields and limits. These controls can stop an unauthorized API call. They cannot settle a disputed bank instruction on their own. The protected payment path therefore crosses out of agent dialogue and into named human responsibility.

The supplier-bank-detail scenario is the draft's example, not a reported fraud. Selo itself moves no money. Its author submitted requirements and architecture for discussion of possible IETF work, and the Datatracker identifies the text as an individual draft with no formal standards standing. The issue on the table is concrete all the same: whether future agent-to-agent plumbing can leave the payee field inside the same automatic change channel as a data endpoint.

Official sources