The Hidden Policy Choices Inside AI Agent Authorization

In June, an AI agent developed by Mexican housing fintech Neivor initiated and completed a payment on behalf of its platform: authenticated, processed, settled. The banks and payment networks involved described it as the first real-world agent-initiated payment in Latin America, after an earlier controlled transaction in Europe. The rails it ran on, Mastercard’s Agent Pay, promise transactions that are “secure, authenticated and with verified intent.”

Take that promise seriously, because it is technically credible. The infrastructure can prove that the agent was authenticated and that an intent was verified. What the cited authorization mechanism does not itself answer is a different set of questions: verified by whom, against which policy, and contestable where? Who supplied the authority the agent exercised? Who decided that this proof was sufficient for money to move? Who can challenge either decision, and with what effect?

Those questions are being answered, often inside technical documents most policymakers will never read.

The vocabulary being written now

Over the past year, proposals at internet standards bodies, alongside shipped commercial products, have begun to define how AI agents get authorized to act. The drafts are serious work, and their details reveal how much judgment is involved.

One individual draft defines verifier-side acceptance as a fail-closed composition of authority grant, holder-of-key proof, session binding, freshness, attestation and local policy. A separate proposal makes delegation monotonically restrictive, so downstream holders can narrow authority but cannot expand it. Another uses a live session trust score that decays on anomaly detection, tightens decision thresholds as trust degrades and suspends the session below a configurable floor. Drafts from China Mobile map requirements for contextual consent and task-level revocation across multi-step delegation chains. Experian, meanwhile, has launched a Know Your Agent framework binding verified consumers to the agents acting for them, with a real-time trust token and dynamic trust scoring¹.

Read those mechanisms again. Who defined what “accepted” means, and for whom? Who decided that this user could delegate that power? When a trust score suspends an agent mid-task, who hears the appeal? Some vocabulary is emerging through formal standards processes; some through vendor-led draft campaigns. Both routes can embed political assumptions before policymakers notice them.

The boundary nobody declares

When architecture does not declare where technical decision ends and policy begins, institutional choices become operational settings. Protocols can prove that a policy chain treated an action as authorized. They do not establish, by cryptography alone, who constituted that authority, who defines when its proof suffices, or before whom it can be contested.

Two examples make the conversion concrete.

One recent individual draft maps the EU AI Act’s Article 50 transparency duties into machine-verifiable receipts². It includes a deployer-set field asserting whether content concerns a matter of public interest, while a separate human-review receipt is intended to support Article 50(4)’s editorial-review exception. The classification is made by the regulated party at issuance time. The same draft instructs verifiers to treat a receipt lacking the recommended generation_type field as having reduced evidentiary weight. A legal classification and an evidentiary recommendation have become executable properties of a privately authored profile. None of this is concealed. It is written where policy debate rarely looks.

The second example concerns who appears in these systems at all. A rigorous proposal on batch issuance of identity credentials for AI agents is explicit about its limits: the credential proves what the issuing authority declared, not what the agent later did. Its cast of characters is just as telling. Witness, holder and relying party appear throughout; in the body, “natural person,” “user” and “affected” do not. That may be defensible as a scope decision at the credential layer. But layers compose into infrastructure, and in the materials examined here the composition exposes no dedicated role for the person affected by the authorized action. Issuers, approvers, agents, verifiers and operators are explicit. The affected person generally is not.

The stakes are practical. An April Cloud Security Alliance report on a survey commissioned by Zenity found that 53 percent of organizations had experienced agents exceeding their intended permissions. Separate Zenity research identifies the inverse problem: agents can remain within their authorized permission set while acting outside their declared purpose. Permission and purpose have come apart; who defines each is exactly what the vocabulary leaves undeclared.

Vocabulary also confers an advantage on whoever writes it first. The first actors to define a receipt, valid delegation or acceptable authorization narrow the choices later systems treat as imaginable. An agent-naming scheme that began as an individual draft now underpins a production registry at GoDaddy. Its implementation adds a Registration Authority, attestation badge, certificate policy and transparency machinery, company choices that can begin to look like properties of the infrastructure itself. José Marichal has argued in these pages that the algorithmic contract needs renegotiating. Agent authorization is where part of that contract becomes executable.

Why this is urgent now

Europe has delayed the principal Chapter III high-risk obligations to December 2, 2027 and August 2, 2028, while Article 50’s transparency duties generally took effect on August 2, 2026. Private specifications are already interpreting those duties in machine terms.

Meanwhile the infrastructure accelerates. Mastercard has extended Agent Pay to machine-to-machine payments with more than 30 industry participants³. July alone brought multiple new or revised individual Internet-Drafts addressing agent identity, verifier-side acceptance, authorization and revocation. When an OpenAI agent recently escaped its sandbox during an internal cyber-capability evaluation, Konstantinos Komaitis argued in these pages that today’s internet can answer who is connecting, but will increasingly need to answer what is acting. He is right. The systems being built to answer that question are where the undeclared choices documented above are accumulating.

The race has visible symptoms. At least one individual draft submitted this year cites a named companion Internet-Draft for which, as of July 28, 2026, I could find no separate Datatracker record or public IETF archive copy⁴. Nothing about an individual submission is irregular. But the visual authority and distribution machinery of the Internet-Draft format can outrun the maturity and review status of the submission it carries.

What to require: three disclosures

The argument is not that engineers are doing something wrong, or that standardization should slow down. Much of the infrastructure is well built. Its political content should simply be declarable, and therefore debatable, before it hardens into defaults.

Authority disclosure. Any deployed authorization profile should state where the authority it enforces comes from: who granted it, under what instrument, and who controls the policy that makes it valid. “Verified intent” is a fine engineering property; the disclosure question is whose policy defined verification and who can change it.

Acceptance disclosure. Someone decides that a given proof is sufficient for an action to proceed. That decision rule, the line between verified and accepted that careful drafts already acknowledge, should be stated, along with who owns it. A public-interest determination made by the deployer at issuance time is such a rule. It should say so where regulators and courts can read it.

Contestability disclosure. Every authorization architecture should state who can contest an authorization decision or outcome, before which body, and with what effect: whether a challenge suspends execution, reverses an outcome, triggers compensation or has no operative effect. If the answer is “no one, nowhere, none,” that should be written down rather than discovered later by the people these systems omit.

These are disclosure duties, not design mandates. They belong in deployment profiles, procurement requirements and conformity documentation, in machine-readable and human-readable form. It is right that a protocol does not determine who is politically legitimate; that is not its job. The problem begins when a system does not declare which inputs are inherited political decisions and who retains power over them. Internal verifiability is not external legitimacy.

The default is a decision

Protocols do not have to resolve legitimacy. They have to declare where it entered the system and who still controls it. The payment that opened this piece is poised to be repeated at scale, across purchases, filings and approvals that people never see.

An intent can be verified by a platform. But the authorization artifacts examined here do not consistently expose who constituted the authority behind it, who decided the proof sufficed, or who can contest either decision. Until disclosure is required, those questions will not remain unanswered. They will be answered by default.

Notes

1. Announced June 2026. The framework issues a trust signal at the point of interaction and adjusts it dynamically, which places the acceptance decision inside a score whose thresholds are set by the issuer rather than declared to the parties relying on it. ↩
2. The determination is described in Section 2 of that draft as being "made by the deployer at issuance time and recorded in the receipt." The same document defines a tier it calls an "Article 50 Defensible Receipt," described as suitable for evidentiary use in adversarial proceedings, and recommends that a verifier treat a receipt lacking the generation_type field as having "reduced evidentiary weight." The recommendation is expressed as a SHOULD: a private specification proposing, in the vocabulary of standards documents, how much weight a piece of evidence deserves. ↩
3. The count is Mastercard's own, from its announcement of the extension in June 2026. Participant counts in launch material describe stated intent rather than deployment, and are cited here as an indication of scale, not of adoption. ↩
4. The draft is draft-dawkins-scitt-ai-article50-00 and the companion it names is draft-dawkins-scitt-lpr-00. Searches of the IETF Datatracker and of the public IETF archive on that date returned no separate record for that name. A name may be reserved for work not yet submitted, and an individual submission carries no IETF endorsement in any case; the observation concerns the distance between the visual authority of the Internet-Draft format and the review status of what it carries. The Datatracker itself states this on every such document: not endorsed by the IETF, no formal standing in the standards process. ↩

Sources

1. Santander, "Getnet develops infrastructure that enables businesses to accept AI agent-initiated payments" (June 2026).
2. Mastercard, "Mastercard launches Agent Pay for Machines" (June 2026).
3. Cloud Security Alliance, "More Than Half of Organizations Experience AI Agent Scope Violations", survey commissioned by Zenity (April 2026).
4. GoDaddy, "Building the Agent Name Service using a one-system approach" (2026).
5. draft-burls-mtac and draft-dawkins-scitt-ai-article50, individual Internet-Drafts (2026). Neither is endorsed by the IETF.
6. Konstantinos Komaitis, "The Real Lesson of OpenAI's Rogue Agent Isn't Alignment", Tech Policy Press (22 July 2026); José Marichal, "We Must Renegotiate the Algorithmic Contract", Tech Policy Press (May 2025).
7. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 50; Regulation (EU) 2026/1744 (Digital Omnibus on AI), in force 27 July 2026.

The Verifiable Trust Stack described in my earlier work, The AI-Blockchain Symbiosis (2026), has an agents layer; this essay is an account of the political content that layer carries, in any such architecture, including mine. The disclosure duties proposed here would apply to it too. Written in an independent capacity; my day job is unrelated to the work described here and had no role in it.