How it relates to AgenID
AgenID answers the first question. An agent presents its identifier, and the merchant resolves it at /verify or as JSON and re-checks the operator's signature. The tire-buying scenario and the financial transaction scenario show the flow.
A merchant can also fetch the operator key from the operator's own domain and compare it with the registry's copy, so a substitution on either side would show up as a mismatch.
AgenID is not a payment rail and holds no payment credential. Other approaches to agent payments are covered in comparisons.
Why it matters
Merchants handle disputes, fraud and returns. When the buyer is an agent, a stable operator identity gives those processes a party to hold accountable across every store the agent visits. Because the identifier is the same everywhere, a merchant can recognize an operator it has dealt with before instead of treating each visit as new.
The reference deployment at agenid.com issues nothing above L1_REGISTERED today. L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet.
What it does not mean
An identity is not payment authority. Whether the agent is allowed to spend a given amount is a permission question that AgenID v1.1.1 does not answer; see agent delegation.
It also does not tell a merchant whether the customer approved this specific cart. That confirmation sits between the merchant, the payment provider and the customer.