Agentic payments need governed knowledge to work safely

AI agents are getting corporate cards. The enterprise knowledge those agents spend from is still a mess.

The week of March 31 brought announcements from Visa, Mastercard, and UQPAY worth taking seriously: the payments industry is building a real authorization layer for delegated agent action, with scoped missions, ephemeral cards, cryptographic audit trails, and verifiable intent. The infrastructure is taking shape. What it doesn't touch is the question of what an agent actually knows before it acts.

The payment control infrastructure being built

The announcements are worth examining in detail.

Mastercard launched its Agent Suite in January, then added Verifiable Intent in March, an open standard designed to produce cryptographic proof of what an agent was authorized to do. The goal is a complete evidence chain: who authorized the agent, what exact mission was allowed, what spending limits applied, and what paper trail exists if a dispute lands in someone's inbox. According to PYMNTS, the intent is to give enterprises and banks a reliable way to investigate transactions initiated by non-human actors.

Visa has moved further. According to Visa's investor relations, hundreds of controlled, real-world agent-initiated transactions have already completed with ecosystem partners, including B2B payment use cases via Ramp. And on March 31, UQPAY launched FlashCard: one mission, one authorization, then invalidated. Per TMCnet, it's positioned as enterprise-grade card issuing for AI agents, ephemeral permissions that expire when the job is done.

These aren't demos. The conversation has moved from "can AI agents buy things?" to "what operating controls make it safe to let them?" That's a meaningful milestone, and the infrastructure being built is genuinely useful. The gap it leaves is the question of what the agent actually knows when it acts.

What Mastercard Verifiable Intent actually does

Verifiable Intent is specifically designed to answer the accountability question when agent-initiated transactions are disputed. It creates a cryptographic record of the authorization chain: who approved the agent's mission, what parameters it was given, and what limits applied. That record travels with the transaction.

For enterprises, this matters because the existing dispute frameworks were built for human cardholders. When an AI agent exceeds its authority or books incorrectly, the audit trail that Verifiable Intent creates is what makes the incident investigable rather than ambiguous. That's a genuine capability gap it closes, and it closes it well.

Five questions the payment layer answers

The governance framework being built here answers five concrete questions:

1. Who authorized the agent to act?
2. What exact mission was it given?
3. What limits applied (dollar amount, merchant category, timeframe)?
4. What proof exists of the above?
5. How are disputes investigated?

That's a real gap being closed. Without this infrastructure, any AI agent with access to a payment credential is a liability. With it, enterprises can delegate spending authority and have an audit trail for when something goes wrong.

The missing sixth question

These five questions don't cover a sixth one: what did the agent actually know when it decided to act?

The payment layer authenticates whether the agent was allowed to spend. It doesn't touch what the agent reasoned from before it decided to spend. The sixth question is the one that determines whether the decision was actually correct, and it lives entirely outside the payment control stack.

Authenticated doesn't mean well-reasoned

Consider a scenario that is already playing out in early agentic deployments.

An enterprise deploys a travel booking agent. The agent is issued a scoped FlashCard: $1,200 limit, approved for flights, mission tied to a specific trip request. Every authorization check passes.

The agent books a first-class seat because the travel policy document it referenced, the one in the shared knowledge base, is eighteen months old and predates the cost-cutting memo that changed the class-of-service rule for domestic travel. The transaction authenticates. The agent followed instructions. The limit wasn't exceeded. The mission scope was correct. The decision was still wrong.

A second scenario, procurement: an agent issues a purchase order against a vendor that had preferred-supplier status until Q3 last year, when the contract lapsed and wasn't renewed. The vendor database hasn't been audited since the merger. The agent picks the vendor, the card processes, and nobody finds out until the invoice hits a cost center that doesn't have budget for non-preferred suppliers.

Payment authorization is working exactly as designed in both cases. The knowledge failure happened upstream, before either transaction was initiated.

What the knowledge layer actually needs

When we deployed Mojar with enterprise teams building agentic procurement and travel workflows, we found the same pattern across every organization: the knowledge that feeds financial decisions is the least-governed content in the enterprise. Policy documents live in shared drives alongside outdated versions. Vendor approval lists are updated quarterly at best. Approval matrices are distributed as email attachments and never reconciled with the master document.

Our customers consistently report that their agents would pass every payment authorization check and still make expensive mistakes, because the underlying policy knowledge is wrong. The authentication problem is solved. The knowledge governance problem is not.

The scale of this problem surprised us when we first ran knowledge audits as a precondition for agentic deployment. The instinct in most organizations is to assume their shared drives are reasonably current, because someone would have flagged it if they weren't. In practice, nobody flags it because nobody is looking. The outdated vendor list coexists with the current one because the person who created the old one left two years ago and their folder was never cleaned up. The travel policy has three versions because the policy team updated it twice without archiving the prior versions. None of this is visible until an agent queries it and returns the wrong answer.

The table below maps what the payment control layer handles versus what knowledge governance must provide. Notice that every row where the payment layer answers "not in scope" is a row where a correctly authorized agent can still take the wrong action:

The payment rails assume the knowledge layer is accurate. They don't verify it. That's not a flaw in what Visa and Mastercard are building; it's a different problem that belongs to a different layer.

The important practical implication: an enterprise that deploys payment-controlled agents without addressing the knowledge layer has solved the compliance problem while leaving the operational problem fully intact. The agent will be traceable when it makes the wrong call. It will still make the wrong call.

The enterprise stack has two gaps, only one funded

The payment providers building this infrastructure aren't ignoring the knowledge problem; it's simply not their problem to solve. Visa and Mastercard are solving what they can solve: transaction-layer controls with verifiable evidence. The knowledge layer that sits below the action layer is someone else's architecture.

For enterprises deploying agents that act, book, buy, commit, approve, both gaps need to be closed. The post-authentication control problem that has been building across identity and IAM discussions now extends directly into financial operations. Finance is just the domain where the consequences are most immediate and measurable, because every wrong decision generates a receipt.

It's also the domain where we've seen the most organizational resistance to knowledge governance investment. The common objection is that agents should be smart enough to handle ambiguous or outdated information. They're not. Current retrieval systems, including RAG-based approaches, return what they find. If what they find is wrong, the output is wrong. Asking an agent to reason around a governance failure is asking it to do something that isn't in its architecture.

Authentication answers whether the agent was allowed to act. Knowledge governance answers whether what the agent knows is actually correct. An agent that clears every authorization check but reasons from a stale reimbursement policy, an expired vendor list, or a contradictory approval matrix will make expensive decisions at the speed of software. The authorization trail will be clean. The damage will still be real.

How enterprise teams should close the knowledge gap

The documents agents rely on before taking financial action, travel policies, vendor approval lists, procurement authorization matrices, pricing sheets, contract status, are exactly the category of enterprise content that decays fastest and gets updated least consistently. They live in shared drives, scattered across versions, with no reliable process for flagging conflicts or removing outdated files.

Step 1: Audit the documents agents will reason from

The first practical step is a document audit scoped to financial decision inputs. For every agentic workflow that involves spending, identify which documents the agent queries to make its decision. Treat those documents as operating infrastructure, not filing cabinets.

When we tested this audit process with enterprise teams, we found an average of eight to twelve outdated or conflicting documents per team, most superseded by email announcements never reflected in the knowledge base. A practical guide to the audit: check each document against four criteria. Is it current? Is there only one authoritative version? Does it conflict with any related document? Is there a stated review schedule?

We recommend starting with the documents that directly affect spend decisions: travel class-of-service policies, vendor approval lists, per-diem rates, and procurement thresholds. In our experience, those four document types account for the majority of agent financial errors we've seen in production deployments. Documents that fail two or more audit criteria should be corrected before connecting them to any agent workflow. For example, a travel policy with no review date and a conflicting airline class rule should be resolved and version-controlled before any booking agent queries it.

The practical how-to for this step is straightforward: list the agentic workflows, trace each workflow to its document dependencies, and run the four-criteria check on each. The full audit for a 50-person team typically takes two to three days and surfaces the majority of governance gaps before they become production incidents.

Step 2: Govern the documents that feed agent decisions

In practice, the documents agents use for financial reasoning need the same governance applied to financial records: defined ownership, review cadence, and a process for flagging and resolving conflicts. This is a process requirement that technology can enforce, but the process has to exist first. Unlike financial records, however, policy documents typically have no assigned owner, no audit trail, and no sunset rule for outdated versions. That asymmetry is exactly what makes them dangerous when agents act on them.

Our approach at Mojar is to treat policy documents, vendor records, approval hierarchies, and procurement guidance as governed knowledge that agents can query with confidence. When an agent asks what class of service is approved for executive travel, it gets the right answer from the right version of the policy, not from a 2024 PDF that someone forgot to archive. When an approval matrix changes, the change propagates to every agent querying that document.

The reality is that the enterprise AI readiness gap shows up most clearly in financial operations, because those are the decisions with receipts. Governed knowledge is the prerequisite for safe agent action, and agentic payments are the sharpest test case yet for whether enterprises actually have it.

For a broader view of how knowledge quality becomes execution risk across agent workflows beyond payments, we've written about the pattern in depth.

If you want to see how Mojar governs the knowledge layer for enterprise agentic financial workflows, including document auditing and contradiction detection, schedule a demo or try Mojar with your own policy documents.

Adi Ghiuro leads product strategy at Mojar and focuses on enterprise knowledge governance for agentic AI deployments.