The agent gets a slot, not a button

THE OPERATOR'S MAP · Chapter: Ship AI · GFF 2026 Special · 11 September 2026. The five chapters advance together: agent controls (Ship AI), the open-source stack (Sovereign Stack), governance (The AI Boardroom), evaluation (Beyond the Benchmark), physical AI (Twin & Machine). This edition steps outside the episode numbering for the Global Fintech Fest; the four sibling chapters, this lane's live predecessor and the two downloadable artifacts are linked at the foot of the piece.

Your agent gets an allowance, not your PIN.

The Operator's Map is a series for the people who have to run AI rather than admire it: five chapters, one per domain, advancing together. This chapter teaches agent controls: what actually governs what an AI agent can do inside your company, and how you would prove it. This edition sits outside the episode numbering. It is the special written against the record of the week's festival, and it reads only the record: the regulator's speeches, the rail's circulars and product pages, the protocol texts the card networks and platforms published about themselves.

The Global Fintech Fest ran on three pillars this year, and the organizer's own text for the first of them promises, in its words, "autonomous orchestration of complex financial workflows, personalised services at scale, and continuous risk monitoring with minimal human intervention", while the government's release for the same festival says the same pillar acts "within strong governance frameworks". This chapter takes the agentic AI pillar, and it takes it at the altitude of a single payment: one delegated transaction, traced hop by hop, with a stopwatch on the windows the texts publish and a ledger for the record each hop leaves. The other four chapters of this special take the token and the ledger it settles on, the director's question of which record shows the authority for an agent's act, the denominators behind the week's percentages, and the cryptographic key inside a machine that will still be in the field when its algorithm is retired. Each is linked at the close.

Why this reaches your desk. Somewhere in your organization an agent is about to be given the ability to spend. Not a person with a corporate card; a program with a wallet, a mandate, a token or an allowance. The vendor deck calls it agentic commerce. The procurement question is what that program can actually do with money, and the only honest answer is the one the payment rail enforces, not the one the model was told. This chapter reads the rulebooks: the Reserve Bank's own definition of a delegated payment, seven operating circulars from the operator of the rail that carried 24,509 million transactions in August 2026, and the protocol texts from Google, OpenAI and Stripe, Visa and Mastercard. It follows one payment through all of them. At the end you will have two things you can hand to the person who signs the vendor contract: a matrix of what each published design permits and forbids, and a record you can require of any agent before it gets a slot.

Terms that matter this edition

One payment, four hops, a stopwatch and a ledger

Here is the transaction I am going to follow. A household has linked a grocery agent to the family's UPI account and asked it to keep the kitchen stocked. On a Tuesday evening it decides the household needs ₹1,240 of groceries and sets about paying. I will run the same order twice: once on the rail India has today, and once on the protocol Google published a year ago and has since handed to the FIDO Alliance's working groups. At each hop I ask two questions. What does the stopwatch read, meaning which window or ordering constraint the text publishes for that hop. And what does the ledger hold, meaning which record that hop leaves and who wrote it.

The stopwatch needs a caveat before it starts. None of the texts read for this chapter publishes a hop time. What they publish are windows and orderings: a 24-hour cooling period, a 90-day block, a six-month auto-revoke, a key that may be pruned after a day, a credential that may not be released until a final mandate is verified. The stopwatch reads those. It is the honest instrument, and the one that matters, because the failure this chapter is about is not a slow hop but a hop that runs twice.

The four hops are propose, authorize, settle and reconcile. The limit belongs outside the model at the authorize hop. The seam between recommending and settling runs between the second and third hops, and it is a property of records, not of companies. Retry safety belongs to the settle hop and is the half nobody presents at a conference. And before the first hop there is a record that has to exist, or the slot is a slot for anybody. The grocery order does not change. What changes at each hop is who is holding what.

Hop two, the authorize hop: the limit belongs outside the model, or it is not a limit

Start with the sentence the rail's regulator wrote two years before anyone at this festival said the word agent. On 8 August 2024 the Reserve Bank of India announced delegated payments in its Statement on Developmental and Regulatory Policies, item 4, in one paragraph:

""Delegated Payments" would allow an individual (primary user) to set a UPI transaction limit for another individual (secondary user) on the primary user's bank account."

Read the grammar. The limit is set by the primary user. It is set on the primary user's account. It is set for the secondary user, who does not carry it. The number is a property of the relationship between two parties and a bank, and the party doing the spending is not the party holding the number. That is the entire design principle of this chapter, stated by a central bank in one sentence about people, and the instrument says "individual". It does not say program. Keep that in view; it will matter at the fourth hop.

Five days later the rail's operator issued the instrument. NPCI's Operating Circular OC 201 of 13 August 2024 defines the two modes, and they are the slot and the button in the rail's own grammar:

"Full Delegation – Primary user authorizes a secondary user to initiate and complete UPI transactions as per defined spend limits"

"Partial Delegation – Primary user authorizes initiation of payment requests from secondary users, Primary user shall complete UPI transaction with UPI PIN"

Then the numbers, and the party obliged to enforce them. The same circular says "Members shall ensure limits control to be available for the primary to set usage controls over their secondary users", and "For full delegation, Members shall ensure a maximum monthly limit of ₹15,000/- per delegation and maximum per transaction limit of ₹5000", and for the first day after linking, "during the cooling period – first 24 hours, a daily transaction limit of ₹5000 shall be prescribed". A primary may have "up to 5 secondary users and a secondary user can accept delegation from only one primary user". The secondary authenticates with its own device: "UPI Apps shall ensure App passcode/ biometrics (finger/face), etc. mandatory for all secondary users". The primary's PIN is never in the secondary's hands. The stopwatch's first reading is the 24-hour cooling window. The ledger's first entry is the limit itself, written by the primary, held by the member bank.

Now the part the brief for this chapter did not know existed until the rail's own pages were read. On 8 October 2025 NPCI extended the slot to software. Operating Circular OC 201B reads, in its opening paragraph:

"UPI Circle is now extended to IoT (Internet of Things) devices & software profiles wherein a UPI user can link and delegate payments to their IoTs Devices & Software profiles like Smart glasses, watch, TV, AI Profiles (initially for limited users in CUG), etc. under the 'Full Delegation' framework as per defined monthly limits and security guidelines. It may be noted that debit transactions using IoT shall be only initiated by explicit user action."

Every clause of that paragraph is load-bearing. The slot for software already exists on the rail, under the same framework: "a maximum monthly limit of INR 15,000 per delegation and maximum per transaction limit of INR 5000 for IoT device app/software", a "24 hours cooling period with cumulative transaction limit of INR 5,000/-", five profiles per primary, one primary per profile, "Only domestic P2M transactions shall be permitted", and the enforcement point named to the party and the moment: "Issuer Banks shall validate device id/user id and requisite authorization details for every transaction before debiting the account for payment." NPCI's product page says the pilot's scope in its own words, "Currently AI/Software driven IoT Payments are under pilot with limited users as a part of Closed User Group", and names the use case this chapter's grocery order is drawn from: "buy groceries/goods from AI chatbots, etc."

The last sentence of that opening paragraph is the one to read twice. "It may be noted that debit transactions using IoT shall be only initiated by explicit user action." On the rail today, a software profile can hold the allowance, but a person still starts each payment; the circular does not say which person, and it does not say the primary, only that the debit is not the software's to start. The slot exists. The button has not been removed. So my grocery agent, on the rail India has, assembles the ₹1,240 order and hands it to a person, who presses. The title of this chapter is a design argument about where the limit lives, not a claim that the rail runs unattended agents; the rail's own instrument says it does not.

One thing the rail's pages do that a chapter must not repair silently. The product page prints "₹2,000 limit for the first 24 hours after linking a new device". The circular that governs it prints "INR 5,000/-" for the same window. Two NPCI documents, two numbers. I print both, attribute each, and choose neither.

Reserve Pay is the other shape a limit can take on the rail, and it is the form a model can reason about least. NPCI's product page says "UPI Reserve Pay lets you reserve money in your account once and use it for multiple payments later", with "Maximum amount you can reserve: ₹10,000 per block" and "Maximum duration for the reserve: 90 days", confirmed once "with your UPI PIN". The circulars make it arithmetic on the bank's ledger: OC 200 says "The fund shall be blocked in the account till the time mandate is expired, revoked or the mandate amount is exhausted", and OC 228 sets "maximum of Rs.10,000 of block limit and up to 90 days" and says "The current block limits (unutilised) are always checked before initiating a debit." A payment service provider's documentation renders the invariant as an equation, attributing the cap to NPCI: "approved mandate amount = utilized amount + remaining balance". The same page carries a coverage line I will not soften, SBMD being the rail's name for the block, Single Block Multiple Debit: "SBMD mandates currently work only with ICICI Bank and Axis Bank savings accounts."

That is a limit outside the model at its purest. Not a rule the agent has been told. A blocked balance the agent cannot overdraw, because the money it would need is not there to be moved.

Now the foreign protocols, on the same question. Google's Agent Payments Protocol says the thing about models that every operator should have printed on the wall. Its security considerations open: "Given the current state of agent security, AP2 assumes that preventing prompt injection attacks is infeasible. Therefore, all LLMs and Agents MUST be considered potential attackers and are explicitly included in the threat model." Having said that, it puts the limit where an attacker cannot reach it: "Even if the LLM fails to make the optimal choice, constraint enforcement during closed Mandate verification ensures that the worst-case financial and logical impacts are strictly bounded." The payment mandate page lists the constraints, Amount Range, Budget, Agent Recurrence, Allowed Payee, Allowed Payment Instrument, Execution Date, and describes the Budget as a running total kept by the verifier: "the requested amount plus the total sum of amounts from previously closed Payment Mandates MUST be less than or equal to max. After approval, the amount MUST be added to the accumulated total for future evaluation." The page's example constraint names "UPI" as an instrument type, and the home page says "Standardization of the specification will continue within the Agentic Authentication Technical and Payments Technical Working Groups in FIDO." So the ₹1,240 order on the AP2 path is checked against a Budget the household signed once and the agent does not keep.

The OpenAI and Stripe protocol does the same with fewer words. The Delegated Payment Spec says the delegated payment "is single-use and set with allowances" and that the token "is restricted by the delegated payment's max amount and expiry"; the Allowance object has a reason field whose only value is "one_time", a max_amount, a currency and an expires_at. Visa's developer page puts the control at the network, at authorization time: "When authorization requests are received by VisaNet, controls will be enforce to ensure that the request originates from the intended merchant for the correct amount", spelling as printed. Mastercard's release and product page name no limit; its developer tutorial describes "a one-time or limited-use credential" and "budget constraints" carried as intent data. A class with no number, and that describes two pages, not a company.

The regulator's framing of the class arrived on 9 September. The Deputy Governor's keynote put speed first: "At machine speed, resilience cannot depend only on preventing every error. Institutions must also be able to detect problems early, contain their effects and intervene before a small mistake becomes a much larger one." And the sentence in the three RBI festival speeches that most directly describes the class of system this chapter is about: "A tool used to summarise an internal document cannot be treated in the same way as a system that autonomously approves credit or executes financial transactions. The greater the consequence of the use case, the stronger the expectations should be around governance, validation, oversight and intervention." A limit the rail enforces before settlement is what intervening before a small mistake becomes a larger one looks like as engineering. A limit the model has been told about is a hope that it will.

The government's cyber body had already written the rule it wants. The Digital Threat Report 2025-26, hosted by CERT-In and dated 13 July 2026 on the agency's listing, recommends to policymakers: "Mandate human-in-the-loop controls for agentic AI actions above defined financial thresholds, with full audit trails". A threshold above which the slot becomes a button. A recommendation in a report co-authored with a private firm is not a direction, and I do not present it as one; but the rail published exactly such a threshold on 10 September, for one product. NPCI's release on Tap & Pay at point-of-sale terminals says: "Users can make UPI PIN-less transactions of up to ₹5,000, above which the user needs to enter their UPI PIN on the POS terminal." The instrument behind it, Operating Circular OC-186A of 10 September 2026, writes the line as an obligation on members, "per transaction limit is capped at ₹5000, up to which additional factor of authentication shall not be required", and adds that members "shall be consulted to provide option to Users to set their own transaction limits within the aforesaid ceiling of ₹5000." A ceiling written by the rail, and a lower number the user may one day write beneath it, once the consultation the circular promises has happened. Neither is written by the thing that taps.

Between hops two and three, authorize to settle: recommend/settle is the only seam that survives an audit

The grocery agent has its ₹1,240 order and an allowance that covers it. Now it has to get the money moved. The question at this hop is not whether the agent may pay; the allowance answered that. The question is which record the agent could have written, and which it could not.

AP2 makes the seam normative, and it makes it in the vocabulary of determinism rather than of companies. The specification defines the two kinds of role: "A role is Agentic when: Communication to or from the Role is handled by a non-deterministic LLM. A role is considered Non-Agentic if: Communication to and from the Role is handled using deterministic code that verifies the authenticity and correctness." Then it assigns them: "The following role MUST be non-agentic: Trusted Surface. The following role is expected to be agentic: Shopping Agent." And it closes the door on the obvious shortcut: "When this document refers to validation or processing for a particular role, it MUST happen in deterministic code regardless of whether the role is agentic or not." The threat model states why in one clause: "when either role is agentic, then the Agent itself is a potential attacker."

The two modes follow. "Human Present (Direct): The User directly sees the closed Checkout and approves it and its payment explicitly. Human Not Present (Autonomous): The User sees and approves a set of constraints over what closed Checkout and Payment would meet their intent. The Shopping Agent then assembles and approves a closed Checkout and Payment Mandate on their behalf using these open Mandates." In autonomous mode the open mandates "MUST include the agent's public key as a cnf claim" (the confirmation-key claim, the field that binds the agent's key to the mandate), with an expiry set "to the smallest value that will allow the Shopping Agent to complete the assigned task." Then settlement: "Merchant Payment Processor MUST verify the Payment Credential is appropriately scoped to the Checkout", and the security page binds the credential to the transaction: "The Payment Credential/Token MUST ONLY be released to the Merchant upon the receipt and verification of a final Payment Mandate." The authorization framework names the two steps, Mandate Delegation on "a Trusted Surface" and Action Authorization, where "a Verifier challenges an Agent to provide proof that it is authorized to perform an action on behalf of a User" and "Upon completion, the Verifier returns the Agent a Receipt." Propose, authorize, settle, and a receipt: the four hops are the protocol's own shape.

So on the AP2 path the stopwatch reads: no credential until a final payment mandate is verified; the open mandate's expiry as small as the task allows. The ledger reads: the household's signature on the open mandate, made on a surface that is not a model; the agent's signature on the closed mandate, with its own key; and a receipt the agent did not write.

The OpenAI and Stripe protocol draws the same seam between organizations rather than between roles, which is the version an operator with a merchant payment service provider meets first. The checkout spec tells the merchant "Payments on your rails. You process payment with your existing PSP; if using Delegated Payments, accept the token and apply your normal authorization/capture flow." The payment spec says "OpenAI is not the merchant of record" and "Settlement, refunds, chargebacks, and compliance remain with the merchant and their PSP." The conversation happens on the platform; the money never does.

On the rail India has, the seam is written into the instrument as the two modes already quoted, and this week it was written into a second instrument about an AI system. OC 227A of 10 September 2026 describes MyUPI as "an AI-powered, multilingual support platform" and, for its Transaction Replay feature, says: "Users can re-initiate past UPI transactions directly from MyUPI. This shall be facilitated via secure intent redirection to the relevant UPI application through which MyUPI was accessed, for transaction authorisation." The AI system proposes; the UPI application authorizes. The same circular ends its automated chargeback path with a human: the system converts eligible complaints "while also providing structured information to the beneficiary/payee PSP to support informed 'human in loop' decision-making by the relevant bank." NPCI's release the same day says MyUPI is "powered by NPCI's Small Language Model (FiMI)"; the circular names no model, which is a difference in what the two documents carry, not a disagreement between them. And the rail's operator, describing its own internal agent tooling on 9 September, chose the audit record this chapter would choose: the AtOM release says the platform "will also strengthen compliance and audit readiness through machine-readable, digitally signed interactions", in "a single auditable workflow."

The rail's chairman said the seam in public, as MediaNama reported on 10 September: "Decision making and execution must remain separate," and "AI may recommend, but authentication and final settlement must follow deterministic auditable rules." I cite that as reported by MediaNama, which also notes that NPCI had not responded to its request for comment. It is the operator of the rail saying move two aloud, and it is not an instrument.

Now the reconcile hop, the one nobody demos. On UPI Circle the rail names the record in OC 201: "A new purpose code in the existing UPI raw file and a new line item in the Net settlement report shall be introduced to identify the UPI circle transaction and settlement, respectively. Additional raw file shall be provided for UPI Circle payments with secondary user details, shared to primary PSP, secondary PSP and remitter bank". For software profiles OC 201B gives the code: "A new purpose code 'BH' is introduced in the existing UPI raw file". The primary sees it too, "on their UPI App and bank account statement", rendered by one PSP as a statement section titled "Delegated Payments". Reserve Pay's OC 228 requires "Display of original block value, remaining balance, expiry date and transaction history (including creation, debits, modification)". And this week's MyUPI release adds a view across banks: "a single view of UPI transactions and AutoPay mandates across banks and UPI apps."

On the AP2 path the reconcile record is the receipt, and the payment mandate page publishes its fields: status, iss, iat, a reference that is "The hash of the closed Mandate that this receipt is binding to", a payment_id, a psp_confirmation_id and a network_confirmation_id, the last two "Present only if status is Success." The specification says what they are for: "In the case of a dispute, the Checkout Mandate and Receipt, and Payment Mandate and Receipt can be brought together to provide a non-repudiable picture of the transaction." Visa's page says the agent's commerce signals, "along with the user instructions can be used to resolve any disputes that may arise." Pine Labs' P3P documentation says "Every completed transaction returns a cryptographically verifiable receipt."

Here is why the seam is a property of records and not of companies. The AP2 security page says receipts "MUST be integrity protected from the Shopping Agent's LLM." A settlement record the model can edit is on the wrong side of the seam even if a payment company produced it. Draw the vertical rule through your own stack at that sentence: everything left of it is a record the agent could have written; everything right of it is a record produced by deterministic code the agent cannot touch. The reconciliation between the two sides is the evidence. The Governor's line about trust being built transaction by transaction, which the AI Boardroom chapter of this special takes as its second move, is the same sentence read as an engineering requirement: per-transaction evidence, on the right side of the rule. My ledger for the grocery order therefore has four entries and two authors. The proposal and the closed mandate are the agent's. The debit and the receipt are not.

The hop that runs twice: idempotency is the unglamorous half

At 20:41 the grocery agent sends the payment request. At 20:41 and some seconds the connection drops. The agent does not know whether the ₹1,240 went. Nothing in the first two hops helps it, because the allowance was ₹15,000 for the month and a second ₹1,240 is well inside it. A delegated slot without retry-safe execution is a duplicate-payment machine, and the limit will not save you, because the limit was never designed to.

The mechanism, in the words of the reference many teams copy. Stripe's idempotent requests page, version 2026-08-26 at fetch: "A client generates an idempotency key, which is a unique key that the server uses to recognize subsequent retries of the same request." "Stripe's idempotency works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeds or fails. Subsequent requests with the same key return the same result, including 500 errors." "You can remove keys from the system automatically after they're at least 24 hours old. We generate a new request if a key is reused after the original is pruned. The idempotency layer compares incoming parameters to those of the original request and errors if they're not the same to prevent accidental misuse." And the honest gap: "We save results only after the execution of an endpoint begins. If incoming parameters fail validation, or the request conflicts with another request that's executing concurrently, we don't save the idempotent result because no API endpoint initiates the execution. You can retry these requests."

Four facts a delegated slot depends on, each with an owner. The key is generated by the client, and in our transaction the client is the agent. The stored result includes failures, so a retry of a failed charge returns the failure rather than a second attempt. The key may be pruned after a day, so the retry that is safe at 20:42 is a fresh payment at 20:42 tomorrow. And a retry with a changed amount is refused, which is protection against exactly what a non-deterministic client does: re-plan, re-price, resend.

The OpenAI and Stripe protocol makes all of this a requirement on the merchant. The checkout spec lists "Security and robustness. Authenticate every request, verify signatures, enforce idempotency, validate inputs, and support safe retries." Every call carries an Idempotency-Key header and the response echoes it back; the spec defines the error request_not_idempotent, and the payment spec defines the conflict: "idempotency_conflict — Same idempotency key but different parameters; returns 409." The ledger entry for this hop is the key and the echo.

The stopwatch here is the shaded window on figure 5: from the first send to the moment the key is pruned, a retry is safe; past it, the same retry is a duplicate. That window is published as "at least 24 hours". Nothing in any fetched text says what the agent does when it restarts inside the window and has lost the key.

AP2 has the protocol-layer version of this problem, and its security page gives it a heading, Double Spend: "A prompt injected, or otherwise malicious Shopping Agent attempts to approve multiple valid Checkouts using the same open Mandate." The mitigation: "The non-deterministic portion of the Shopping Agent MUST avoid signing multiple, overlapping closed Mandates for the same open Mandate without receiving Receipts rejecting the previously released Mandates. These Receipts MUST be integrity protected from the Shopping Agent's LLM. Credential Provider, Networks or MPPs MAY reject multiple overlapping Mandates, or invalidate previously issued payment tokens." The specification states the agent's duty again: "Shopping Agents MUST NOT present any subsequent open Payment or Checkout Mandates without receiving a rejection receipt from the previous one."

Read the two verbs. The MUST is on the agent, the party the same document calls a potential attacker. The MAY is on the verifier, the deterministic party. That is an observation about the text and not a defect in it; a specification may reasonably state the agent's obligation and leave the verifier's enforcement to implementations. But an operator should notice which side the "must" sits on, and should not assume the "may" has been exercised by anyone until they have seen it.

The rail has a third design, and it is the one I did not expect to find. Reserve Pay's OC 228 tells acquiring entities: "The block created shall not be treated as the guarantee of payment, only the successful debit response received by the merchant (for the debit initiated by the customer action on merchant's platform) shall be considered for payment." Then the retry rule: "the timeout on the debit transaction with Issuer/ Payer PSP shall be treated as a decline transaction and will be reversed in real-time and shall not be settled (not to be treated as deemed debit). Only for afore-mentioned scenarios, acquiring entities may retry maximum 3 times in 24 hours (no retries for any other declines)." No key at all. The ambiguous case is resolved by refusing to treat it as paid; the retry sits with the merchant's bank, capped at three in 24 hours, and nothing is keyed. It says nothing about what the customer's own software does when its request to the merchant times out, and neither will I.

Pine Labs gives the firm's answer on its P3P page: "Payment tokens are tied to a specific resource, amount, and expiry. They cannot be replayed, redirected, or reused." And the Digital Threat Report is the only Indian public-body document read for this chapter that uses the word: "Define protocol-level invariants for instant payment infrastructure to detect OTP race conditions and idempotency violations at network level". At network level, not at the agent.

One thing the stopwatch must keep apart. NPCI's MyUPI release describes "Transaction Replay, which enables users to recall and repeat past transactions using any UPI app." That is a person choosing to pay again, the opposite of an idempotent retry, and the figure keeps it off the timeline.

Before hop one: Know Your Agent before Know Your Customer for agents

Go back to the beginning of the transaction, before the grocery agent proposed anything, and ask what had to be true for the slot to be a slot for this agent and not for anybody. Identity, consent scope and an audit trail are the precondition. The slot is the second step.

The card networks say so in their own words. Mastercard's product page carries the phrase as a heading: "Know your agent", and under it, "Only registered agents can transact — governed and traceable with Mastercard network tokens — setting new standards for trust and accountability." Its developer site describes the mechanism: "Only registered agents can transact through the network. Each agent goes through a security review before being certified. Once certified, agents are added to trusted agent lists. These lists are maintained by the payment networks." The April 2025 release had put it as "The program will require trusted AI agents to be registered and verified". Visa's developer page: "Agents are onboarded onto the Visa Intelligent Commerce platform in order to access the integrated services", with provisioning that includes "step up verification of the cardholder as well as setting up a Passkey that will be used by the agent to authenticate future instructions." The order is register first, transact second.

The rail has the same order for people, and something close to it for software. OC 201A of 8 July 2025 requires, before full delegation to a person: "Issuer Bank of the Primary User shall identify the Secondary User at the time of delegation by way of name, mobile number and ID number of an Officially Valid Document as defined under Master Direction Know Your Customer (KYC) Direction, 2016". KYC of the secondary, at the issuer, before the slot opens. For software, OC 201B says "Secondary PSPs shall capture device/ user ID details from secondary device/software during registration and validate during payment request", "In case of software, user profile id shall be captured, and it shall be ensured that only paid software profiles be allowed on this functionality", and "Secondary PSP Bank shall onboard the IoT device app/ software after completing the necessary due diligence and app security evaluation." The identity record precedes the slot on the rail already. It is a record about a device or a profile, bound to a person's account, and it never uses the word agent.

The protocol binds identity cryptographically. AP2's open mandates "MUST include the agent's public key as a cnf claim", and its authorization framework says the verifier trusts "the Issuer of the User Credential" to "ensure that the Trusted Surface constructs Mandates only after obtaining appropriate user consent and authorization." Consent scope is the field the regulator named this week: the Governor's keynote says customer data must be "collected with clear purpose, used strictly within the consent given". The cyber body frames the agent as an identity: the Digital Threat Report recommends to "Extend identity governance to non-human identities - service accounts, machine identities, agentic AI - on the same attestation and rotation perimeter as human identities". And an Indian firm lists identity first in its own description: Pine Labs' P3P release says its companion protocol "provides verifiable identity, delegated authorization, spend controls, and auditability".

And the banker's echo, as reported. ANI's copy in The Tribune on 10 September quotes the chairman of the State Bank of India: "Banks have spent decades building robust processes about know your customer. As agents begin to participate in financial transactions, we will increasingly need to think about know your agent." A phrase in a speech, as reported by ANI. Not a framework, not a policy, and I do not make it one.

That last sentence is the answer to the objection that "know your agent" is a metaphor: KYC exists because a customer is a legal person who can be liable, and an agent cannot be. True, and none of the designs read here try. They bind the agent's key to a user's signed mandate and make the user's consent the thing verified; the networks register the agent's provider, not the agent's conscience. Know Your Agent is the record that lets liability find the human, and it has to exist before the slot does, or the slot is a slot for whoever holds the key.

Now the absence, stated plainly, because it frames the whole move. Across the three RBI speeches delivered at the festival on 8, 9 and 10 September, the strings agent, agentic and delegat occur zero times: the welcome remarks, the Deputy Governor's keynote and the Governor's keynote, machine-checked over the saved text of each. The Deputy Governor described the class of system this chapter is about without once using the word. The RBI's press-release index, re-read at 15:54 IST on 11 September 2026, carries no row dated 8 to 11 September naming UPI, delegated payments or agents; its one fintech item is the recognition of a self-regulatory organization. NPCI's press-release listing, read through the site's own API on 11 September, shows six releases in the festival window, and none announces an agent-payment protocol: the two agent-facing releases that describe a product are a training environment in which "conversational assistants evolve into tool-using agents capable of resolving customer requests within defined rules" and a model that is "designed to complete complex, long-context tasks within a bank's defined rules and infrastructure". The protocol reported before the festival as due to launch there, as Inc42 reported citing Reuters on 1 September, appears in no NPCI release or circular; the chairman said on 10 September, as MediaNama reported, that NPCI "is also examining the protocols that may be required to identify and authorise digital agents within the Unified Payments Interface (UPI) ecosystem while preserving interoperability, auditability and settlement finality." Examining. Present tense.

So nobody handed anyone a Know Your Agent rule this week. What exists is an October 2025 circular for a small pilot that requires a device or profile id, NPCI-permitted software, paid profiles and one primary per profile, which is a KYA record in everything but name, and what the card networks and protocol authors published about their own designs. The precondition is being built by the rail's product team, by firms and by protocol authors, not by a regulator, which is the argument for writing the record now, before someone writes it for you, and why this chapter's second artifact is a schema rather than a policy.

One count from the predecessor chapter, because it belongs here and nowhere else. The Episode 3 incident's tokens were self-minted by an agent from a harvested key; every protocol in this chapter answers that exact failure by binding a payment credential to one transaction. And Episode 3's finding, that the Model Context Protocol's authorization surface contains no revocation operation, rhymes with this run's count: across the five AP2 pages fetched, the strings revok and revoc occur zero times; across the two ACP specifications, zero; on Visa's developer page, zero; on Mastercard's release, product page and developer tutorial, zero. The nearest verb in AP2 is that verifiers "MAY reject multiple overlapping Mandates, or invalidate previously issued payment tokens", which is invalidation of a token at the verifier's option, not revocation of a mandate by the user. The only texts that say "revoke" are the rail's and the Indian firms': OC 201B's "shall auto-revoke the authorization for the IoT device app/ software if delegation is inactive for a period of 6 months or in case of any security concerns", OC 228's "Easy access to revoke the block", MyUPI's Safety Switch, which OC 227A says "shall operate on a reasonable-efforts basis", and the P3P release's "The consumer can revoke or update the mandate at any time." None of that is a defect in the protocols; canceling a mandate is the rail's job, not the specification's. It does mean the cancel button is on a different page from the rule, and the predecessor chapter was about how rarely anyone times that button.

The two artifacts: the permit matrix and the record

The first artifact is the slot-permit matrix, a CSV you can download and put in front of whoever is comparing vendors. Nine published designs as rows, five questions as columns: where the limit lives, who authenticates, what settles, what the audit record contains, whether revocation is specified. Every cell quotes the publisher where it wrote the answer, summarizes in plain words where it did not, or reads "not specified in the fetched page" with the string count, because a page can be silent without a product being absent. Three rules make it a permit matrix rather than a feature list. A cell never reads "none". The "who authenticates" cell names the party, never the technology alone. And the status column is a live field: Stripe's agent side reads "Private preview", Visa's page reads "in the process of development and deployment", Mastercard's product page is live while its developer site's own index lists no Agent Pay service, and NPCI's software slot reads "initially for limited users in CUG". A tenth row for the NPCI agent protocol has no cells filled: stated as reported, with the software-profile row above it as the nearest published instrument.

The second artifact is the Know Your Agent record: a field schema, as JSON and as Markdown, that inventories what the published designs already ask for and assembles it into one record. Nothing in it is doctrine. Every field points at a fetched text that requires, records or names it, from agent_id at Mastercard's registration and OC 201B's profile id, through allowance, idempotency and receipts, to revocation with a tested_at field that is the bridge to the predecessor chapter, and record_boundary, which marks for every field which side of figure 4's rule it sits on. Figure 7 prints the pointer beside each field.

The one-question version, for a reader who will not fill in a schema. For the agent you are about to give a slot, name the party that holds the number, the party that holds the PIN, the party that writes the receipt, and the party that can take the slot away, and show the four records. If two of them are the same process as the model, that is the chapter.

The strongest counterargument

Here it is, put as well as I can put it. Rail-enforced caps are blunt. A ₹5,000 per-transaction cap stops a ₹5,001 grocery order and waves through forty ₹300 fraudulent ones. The intelligence to tell a legitimate order from a drained account lives in the model, which can see the cart, the merchant, the household's pattern and the time of night. If the limit is only ever the blunt number in the bank's book, you have thrown away the one component that could actually tell the difference, and you have called that governance. So the model must hold some of the limit, or the limit is not worth much.

Concede the bluntness. It is real, and the protocols already concede it in their structure: AP2 lets the agent reason freely inside the open mandate and lets the verifier refuse anything outside it, so the model's judgment governs the expected case and the rail's cap governs the worst case. Only one of them is a control, and the reason is the reader, not the model. The number a regulator, an examiner, a customer or a fraud investigator can check is the blunt one: it is written in a ledger, it has a date and a party, and it will read the same next month. The model's judgment about tonight's order is not checkable by anyone after the fact, is not stable across a version change, and, per the protocol's own threat model, may have been written by an attacker. So let the model hold the judgment. Let the rail hold the limit. When the two disagree, the rail wins, and that is the property an audit can see. Everything else is a hope with a good average.

What to ask your team

For every agent that can spend, which system holds the number: the model's prompt, the orchestrator's configuration, or a ledger the model cannot write to? Show the row, not the policy.

When the agent's payment is authenticated, whose credential is presented and who typed it: the agent's key bound to a user-signed mandate, or a secret the agent carries in its environment?

Which record could the agent have written, and which could it not? Draw figure 4's vertical rule through your own stack and list what sits on the left.

Who generates the idempotency key, where is it stored across an agent restart, and what does the agent do with a 409? If the answer is "the framework handles it", ask which framework and read the page.

What is your human-in-the-loop threshold, in rupees or dollars, and where is it enforced? Above it the slot must become a button; if the threshold lives in a prompt it is not a threshold.

Who can revoke the slot, through what channel, and when was it last tested? The Indian instruments say the customer, through the app or the merchant, or the rail after six months; the protocols do not say. Your answer should not be "the protocol".

Does the agent have a registered identity that a verifier trusts, a provider, a key, a record, before it has an allowance? If the allowance came first, the order is backward.

Can you reconcile approved equals utilized plus remaining for every agent every day, and who reads the exception list?

Cut in verification, and why

The NPCI "Unified Agent Protocol" as a launched product, and any rupee cap "of the protocol". Reported before the festival, via unnamed sources; the chairman used the word "examining" during the festival, and NPCI's own 2026 release and circular listings carry no such instrument. It appears in this chapter as reported and never as a number; the rupee caps in the figures are UPI Circle and Reserve Pay caps from NPCI's own instruments.

The paraphrase "agents may recommend UPI payments, but authentication and final settlement must remain deterministic and auditable" as a quotation. A working file's wording, not the outlet's; the outlet's is used, as reported.

"Know Your Agent" as an SBI policy, product or framework. ANI reports a sentence in a speech. It is used as the phrase it is, and credited to ANI; the phrase's first citation is Mastercard's own product heading.

Amazon Pay's reported "Smart Wallet" launch and Pine Labs' festival-week announcement with a lender. Neither firm has published a release that could be found by 11 September; both are named only as an outlet reported them, and the fetch routes are logged under "Did not resolve".

The launch claims of the week's other firms. Beyond the Benchmark's lane; none is a firm-published primary in this run, and none is needed for any of the four moves.

MediaNama's August 2026 UPI value figure, and the aggregators of the Reuters report. The first is not in the PIB release; the second were used only to trace the rupee figures to the existing product caps. Neither is a source of fact.

Visa's Trusted Agent Protocol page, Google Pay and bank UPI Circle help pages, and the organizer's site counters, which animate client-side and render as zero. Adjacent or unreadable; not cited.

Political speeches at the festival. Excluded by the edition's rule that regulators and operators speak and politicians do not, unless they announce an instrument with a document.

The Model Context Protocol authorization pages and any Episode 3 regional anchor, including the RBI's draft model risk management framework. Not re-fetched this run; not cited. The predecessor's finding is stated, not re-argued; the Governor names the draft framework in his 10 September speech, and the AI Boardroom chapter of this special owns that thread.

"SR 11-7". Never cited. It was superseded on 17 April 2026 by OCC Bulletin 2026-13 and Fed SR 26-2, and no US model-risk anchor is needed in this chapter.

Did not resolve

The Reuters report of 1 September 2026 on the NPCI agent protocol. reuters.com refuses both the fetcher and the search agent; the URL and its exact wording are not on file, and the aggregators disagree on its date, 1 or 3 September. Moot for every number in this chapter; open only for the wording. RE-VERIFY: browser read.

An SBI primary for "know your agent". The bank's press-release route returns 404 and its "in the news" listing carries no September 2026 item. RE-VERIFY: sbi.bank.in listing.

Pine Labs' festival-week release: newsroom routes 404, media listing script-rendered. Amazon Pay's Smart Wallet: no item on aboutamazon.in. A second PSP statement of the UPI Circle caps and a second Reserve Pay integration page: both routes 404, moot because NPCI's own instruments carry the caps. RE-VERIFY: pinelabs.com media listing in a browser.

Two NPCI documents disagree on the first-24-hours cap for a linked device or software profile: the product page prints ₹2,000, the governing circular prints INR 5,000. Not a fetch gap; a disagreement between two documents from the same publisher. Printed as such, unreconciled. RE-VERIFY: both pages on publish morning.

The Governor's 10 September speech still calls the RBI's model-risk framework a draft. A live status; it still read that way at re-fetch on 11 September. RE-VERIFY before publish; if finalized, the AI Boardroom chapter's still-a-draft sentences change and this chapter's cut list changes with them.

The NPCI product pages, press-release API and Mastercard product page do not render to a fetcher and were read in a browser at the issuing body's own URL. RE-VERIFY: re-render on publish morning; a changed cap moves a rung on figure 3 and a row in the matrix.

Next in the series

Next in the series for this lane: "Revocation assumes a door you are watching. The specification draws another one on purpose."

The series

This is the Ship AI chapter of The Operator's Map, GFF 2026 Special, dated 11 September 2026. Its four siblings take the festival's other pillars at their own altitude. The Sovereign Stack: "A token settles where the ledger is sovereign". The AI Boardroom: "The model said so" is not an answer. Beyond the Benchmark: "Ninety-five percent is a projection". Twin & Machine: "The key inside the machine that moves".

This lane's live predecessor, on timing a revocation tier by tier: "Nobody timed the revocation. Here is the stopwatch, tier by tier."

Drafted with AI assistance; written, edited and approved by me.