Agentic Fraud Glossary

Commerce in which the buying party is software acting under authority delegated by a human or an organization. The agent selects, negotiates, checks out and pays, while the person who authorized it may be asleep, offline, or unaware that the specific purchase happened at all. The economic decision and the human intent behind it are separated in time and often in form.

Every control in card fraud practice assumes a person is somewhere in the loop, either at the moment of purchase or reachable for a challenge. Once the buyer is software, device fingerprints describe a data center rather than a household, behavioral biometrics describe a runtime loop, and one-time passcodes go to an inbox no one is reading. The operator's question changes from whether a human is present to whether this agent was authorized, by whom, and within what limits. Controls have to move from the session to the authority, and the evidence of that authority has to travel with the transaction rather than sit in the buyer's own logs.

The aggregate risk surface created when agents shop, pay, subscribe and manage accounts on behalf of others. It spans authorization risk, meaning whether the agent had the right to act, and settlement risk, meaning who bears the loss when the action was wrong. Unlike classic card fraud, the loss can arise without any attacker at all, from an agent that behaved exactly as coded against a mandate it misread.

The hard part for a risk team is attribution. A disputed agent purchase can be genuine fraud, a compromised agent, a prompt injection, a misconfigured spending limit, a hallucinated product match, or a customer with buyer's remorse who now claims the agent went rogue. Existing dispute rules were not written to distinguish those cases, and chargeback reason codes have no field for delegated machine authority. Operators should assume that until network rules and contracts catch up, the party holding the best contemporaneous evidence of authorization will win the argument. That makes capturing and retaining verification evidence at transaction time a commercial decision, not just a compliance one.

Software that pursues a goal across multiple steps, choosing its own intermediate actions, calling tools and external services, and adapting to results without a human approving each step. The defining property is not the model behind it but the delegated latitude, meaning it decides how to reach an outcome rather than executing a fixed script. A checkout bot following hardcoded instructions is automation, while a system that reads a merchant page, picks a substitute product and pays for it is an agent.

That latitude is what makes agents a distinct risk object. Two agents built on the same model can behave differently because their instructions, memory and context differ, so identifying the model or the vendor tells an operator very little. What matters is the specific deployed instance, who controls it, what it was permitted to do, and whether its instructions have been altered since it was authorized. Anything a risk team builds for agents has to bind to that instance rather than to the software category.

A population of agents running under a single principal, platform or operator, often numbering in the thousands and often spun up and destroyed continuously. Fleets appear wherever agent work is parallelized, in procurement, in data acquisition, in customer service, and in any workflow where one orchestrator delegates to many workers.

Fleet scale breaks single-entity controls in two directions. Downward, per-agent limits become meaningless if a principal can instantiate a thousand agents each staying just under the threshold, which is a structuring problem in everything but name. Upward, containment becomes the hard operation, because discovering that one agent is compromised tells you nothing useful unless you can enumerate its siblings, determine which share the same credentials, wallet or instruction template, and stop them together within seconds. Operators should treat fleet membership as a first-class attribute captured at issuance rather than inferred later from traffic patterns, and should require that a freeze can be applied at the principal or template level, not only per agent. Very few merchant fraud stacks can express that today.

A transaction in which both counterparties are software acting under delegated authority, such as a buying agent purchasing from a selling agent, or one agent paying another for compute, data or task execution. No human is present on either side at the moment of the exchange, and in many cases neither side's principal will review it individually.

The absence of a human on the receiving side is the part operators underestimate. Classic controls assume that even if the buyer is automated, the merchant is an institution with staff, a compliance function and an address. When the seller is also an agent, there is no one to answer a step-up challenge and often no clear legal entity behind the endpoint until you go looking. Sanctions screening and counterparty due diligence both need a resolvable entity, so A2A flows push the identity problem onto whatever infrastructure sits between the two agents. Both sides need portable, verifiable claims about the other, and a record of the exchange that survives the agents themselves being torn down.

A framing, popularized by Gartner, of software as a genuine economic buyer rather than a channel through which a human buys. It covers connected devices that reorder supplies, procurement systems that source autonomously, and agents that shop on behalf of consumers or businesses. The term predates the current agent wave and is useful because it lands with commercial and merchandising audiences who do not think in fraud vocabulary.

For a risk function, the usefulness is in the framing, since it forces the question of what a customer record means when the customer is not a person. Loyalty programs, marketing consent, KYC obligations and dispute rights were all designed around a natural person or a registered business. A machine customer sits between the two, with a principal behind it who holds the legal relationship and an agent in front that does the actual buying. Merchants adopting the term should be explicit about which of those two the customer record is really about, because getting it wrong contaminates both the risk models and the regulatory posture.

The final purchase step completed by an agent, whether through a merchant's normal web flow, a dedicated agent API, or a protocol-mediated handshake. The agent supplies payment credentials, shipping details and any required consent, and receives an order confirmation on behalf of its principal.

Almost every checkout control assumes human presence and degrades badly without it. CAPTCHA either blocks legitimate agents or trains merchants to weaken it. 3-D Secure challenges route to a cardholder who is not watching. Device intelligence sees a headless browser in a cloud region and cannot distinguish a customer's authorized agent from a card-testing script. Velocity rules built for human shopping cadence fire on ordinary agent behavior. The practical response is to stop treating agent traffic as failed human traffic and instead give it a declared path where the agent identifies itself, presents evidence of its authority, and accepts a verdict, so that a step-up can be routed to the human principal out of band rather than dropped into a session no person will ever see.

An open standard, introduced by Anthropic, for connecting agents to external tools, data sources and services through a common interface. An MCP server exposes capabilities, an agent connects and can then call them, which is what lets a general purpose agent acquire the ability to search a database, file a ticket, or move money.

Tool acquisition is an authority expansion path, and it is largely unmonitored. An agent that was authorized to research suppliers becomes an agent that can pay them the moment a payments server is added to its configuration, and nothing in the original delegation from the principal necessarily changed. Servers can be added by the operator, by the platform, or in some deployments by the agent's own instructions, and the connection is typically made once and trusted thereafter. Risk teams should treat the set of connected tools as part of an agent's risk profile, expect it to drift after issuance, and require that any capability touching funds be reflected in the agent's authorization scope rather than granted silently at the tool layer.

A revival of the long dormant HTTP 402 Payment Required status code as a machine-native payment scheme. A server responds to an unpaid request with 402 and payment terms, the client pays, typically in stablecoin, and retries with proof of payment attached, so the payment is carried inside the request cycle rather than through a separate checkout.

The design collapses the payment into a handshake measured in hundreds of milliseconds, which removes every place a conventional risk stack normally does its work. There is no cart, no order page, no email confirmation, no batch settlement window and no reasonable point to insert an out-of-band challenge. Verification has to happen inside the handshake, driven by whatever the client presents at request time, or it does not happen at all. Operators exposing paid endpoints this way should assume they will be probed continuously and should decide up front what evidence they require from a caller, what they log for each paid call, and how a decision is reached fast enough not to defeat the purpose of the protocol.

A Google-led open protocol for agent-initiated payments, built around signed mandates that record what a user authorized. Its structure separates a broader statement of intent from a specific cart or transaction, with both expressed as verifiable credentials that can be presented to a merchant or payment provider as proof of authorization.

Putting the mandate at the center is the important move, because it makes authority an explicit, inspectable object rather than something inferred from a session. It also relocates the failure modes. A mandate can be scoped too widely by a well-meaning user, can be reused beyond the intent that produced it, or can be signed by an agent that was already compromised at the moment of signing, and a cryptographically valid mandate says nothing about any of those. Operators should read a mandate as a strong statement of what was permitted and a weak statement about whether the presenter deserves it. The remaining work is establishing that the agent holding the mandate is the agent the principal meant to authorize and is still uncompromised.

An open protocol developed by OpenAI with Stripe for agent-initiated purchasing, defining how an agent discovers products, builds an order and completes checkout with a merchant, including a delegated payment mechanism so the agent can pay without holding raw card credentials. It gives merchants a structured path for agent traffic instead of leaving agents to scrape and fill human checkout forms.

Protocols of this kind carry identity assertions, meaning the agent and its platform state who they are and what they were asked to do. What they generally do not carry is independent verification of those assertions, since the party making the claim and the party vouching for it are the same. For a merchant that is a real improvement in structure and a limited one in assurance. The open questions are who is liable when an assertion is wrong and what evidence survives for a dispute months later. Merchants adopting these rails should treat protocol conformance as the transport layer and put their own verification decision on top of it.

A token designed to hold a fixed value against a reference currency, usually the dollar, and settle on a public or permissioned ledger in seconds with practical finality. Settlement is push-based and irreversible, there is no issuer-side chargeback, and transfer works identically at $0.03 and $30,000.

For agent payments this makes stablecoins the natural default, since machine transactions need to be small, fast, programmable and available without a banking relationship per counterparty. The same properties make the cash-out layer the least defended part of the stack. Ledger transparency helps trace flows after the fact but does nothing to stop one in flight, and irreversibility means recovery depends entirely on the counterparty's cooperation. Controls therefore have to sit before the transfer is signed, in the decision about whether the agent is authorized to move these funds to this destination, because there is no meaningful control after. Operators should also expect their AML monitoring, built for reversible rails and batch review, to fit poorly against continuous machine-initiated settlement.

Machine-initiated payments below a dollar, frequently far below, made at high frequency as agents pay per API call, per inference, per document, or per unit of compute. Each payment is economically trivial in isolation, which is the point of the design, and each is a real value transfer.

Threshold-based monitoring cannot see this flow. Reporting regimes, velocity rules and transaction monitoring scenarios all assume a floor beneath which activity does not matter, an assumption that held while a human had to initiate each payment. An agent fleet making millions of sub-cent transfers can move material value while every individual event sits under every threshold in the system, and the aggregate may never be assembled because nothing in the pipeline is grouped by principal or purpose. Operators should monitor aggregated flow per principal, per agent and per destination over time rather than per transaction. Whether existing reporting rules apply to aggregated machine micropayments is unresolved and will need regulator guidance.

The emerging model in which APIs, content, data and compute are priced and sold per request to machine consumers rather than through human-signed subscriptions. Access is granted call by call, billing is continuous, and the buyer is an agent deciding in the moment whether a given resource is worth its price.

The commercial shift removes the account opening moment that most controls hang from. A subscription implies onboarding, a contract, a named customer and a periodic invoice a human eventually reads, which together provide the identity anchor and the review cadence. Per-call access has none of that, so the seller may transact thousands of times with a counterparty it has never onboarded and cannot name. Sellers need to decide what they require from a caller before the first paid request rather than at signup, since there is no signup, and to reconstruct afterward who was behind a given stream of calls. Buyers need the reciprocal ability to prove their agent's spending was authorized.

Transaction and decision rates set by software rather than by human tempo, where an agent can evaluate an offer, commit and settle in well under a second, and can repeat that continuously. The decision window is a property of the system design, not a target to be optimized toward.

Human review is excluded by construction, which is a structural point rather than a staffing complaint. A manual review queue that resolves in hours is meaningless against a flow that completes in milliseconds and will have made thousands more decisions before an analyst opens the first case. The same applies to any control whose response path runs through a person, including callback verification and most step-up flows as currently built. Risk decisions must be made inline and automatically, so the inputs have to be available at request time and precomputed or cheaply retrievable. Human judgment moves upstream into policy, scope and limits set before the agent starts working, and downstream into review of what already happened.

A machine-readable document published at a predictable, well-known path that states who a party is, what agent-related capabilities it supports, and how counterparties can verify claims it makes. It follows the pattern of existing web declarations such as robots and security files, where discoverability is the whole design and no negotiation is required to read it.

Its value in agent commerce is that it gives an agent a way to learn the rules before acting rather than by failing. An agent can determine whether a counterparty accepts agent traffic, what evidence it expects and where to send a verification request, all without a human integration project. The obvious limitation is that a manifest is a self-declaration, so it establishes intent and interface but not honesty, and anyone can publish one. It is a discovery layer that has to be paired with actual verification of the claims it points to. Treat what a manifest asserts as a starting position to be checked, and log which version was in force at the time of a transaction.

A merchant-published declaration of which agents it will transact with and on what terms, covering accepted protocols, required credentials, permitted categories, spending limits, and the conditions under which an agent purchase will be honored. It is the merchant side of the discovery problem, telling agents what the door requires before they knock.

For fraud and risk teams this is where informal policy becomes enforceable and auditable. Most merchants today have an implicit agent policy expressed only in whatever their bot mitigation happens to block, which means the policy is unknown to legitimate agents, inconsistent across surfaces, and impossible to cite in a dispute. Writing it down changes three things. It lets well-behaved agents comply rather than evade, it gives the merchant a documented basis for refusing a transaction, and it creates a version history showing what was required at the time an order was placed. The risk is publishing terms the merchant cannot actually enforce at transaction time, which converts a control into a claim a counterparty can rely on and later point to.

The practical state of being able to identify agent traffic, decide whether to accept it, apply the right limits, and produce evidence about what was accepted, as opposed to being able only to detect and block it. A merchant or API seller is agent-ready when agent activity is a known, measured category in its systems rather than an unlabeled fraction of the traffic it calls suspicious.

Most organizations do not know their current agent volume, which is the first symptom. Agent purchases arrive disguised as ordinary sessions, get scored by models trained on human behavior, and land in approval and decline rates that no one attributes correctly, so the business cannot tell whether it is losing good agent revenue or absorbing bad agent losses. Getting ready is mostly unglamorous work. Instrument and label agent traffic, define an accepted-agent policy and publish it, give agents a declared path with a verification requirement, route step-ups to the human principal out of band, and retain the decision evidence in a form a dispute or an examiner can read.

Established by evidence rather than by assertion, agent identity answers which software actor is transacting and under whose authority. It is not the identity of the human or company behind the agent, and it is not the API key the agent happens to present at the payment step. A workable definition covers a durable identifier, the party that vouched for it, and the claims bound to it.

Most systems today infer agent identity from whatever the calling code sends, which makes the identity only as strong as the secret in the header. When an agent is spawned per task, lives for seconds and shares infrastructure with thousands of siblings, the identifier has to survive that lifecycle without becoming meaningless. Operators should decide early whether they are identifying the software build, the running instance or the account that funds it, since each choice supports a different control. Identity that a counterparty cannot check without help from the issuer is not identity for commerce purposes, it is a local session label.

KYA takes the shape of KYC and KYB and applies it to non-human actors. It covers establishing that an agent is known, that a responsible party stands behind it, that it holds authority for the action in front of it, and that the action falls inside the scope granted. Unlike onboarding diligence, it has to be meaningful at transaction time.

The classic split between onboarding and monitoring collapses, because an agent's authority can be narrowed, widened or revoked between one call and the next. A merchant that verified an agent at integration time learns nothing about whether the mandate behind today's purchase is still live. Practical KYA therefore has to resolve the controller, the wallet funding the payment, the scope of the current instruction and the execution environment, and do it inside the latency budget of a checkout. No regulator has yet stated whether KYA satisfies an existing customer due diligence obligation, so firms treating it as a compliance control are ahead of the rulebook.

A portable credential that binds an agent to a controller, a wallet and a mandate, issued by a party willing to stand behind those bindings. The passport carries identity and authority claims rather than payment instructions, which is the point of the phrase "the passport signs identity, not spend". It is presented at transaction time and checked by the counterparty rather than trusted on sight.

A passport is only useful if the receiving side can validate it without a prior relationship with the issuer and without asking the agent's own infrastructure. Binding to a wallet is what stops a valid agent identity from being reused to fund a payment from an unrelated source. Binding to a mandate is what lets a merchant separate an in-scope purchase from scope drift. Revocation and expiry have to be first-class, since a long-lived passport attached to a compromised agent is worse than no passport at all. Presenting a passport identifier alone grants no authority credit, and a passport is useful at decision time without being required for a verification to happen. FLINT issues passports of this kind and returns a verdict plus a signed record on each check.

FLINT's term for carrying agent attestations across trust domains, so that a credential issued in one environment still means something in another. A trust domain here is any boundary where the verifying party did not issue the credential and holds no relationship with whoever did, for example a merchant checking an agent built by an unrelated developer.

Inside a single platform an agent's identity resolves against an internal registry. Across a boundary that registry is invisible, so the credential has to be self-contained, signed by an issuer the verifier can resolve, and checkable against a revocation source without a bilateral integration. Two problems dominate. Issuer trust is one, since a valid signature helps only if the verifier has a reason to accept the signer. Replay is the other, since a portable credential sent over an open network can be captured and reused unless it is bound to the specific transaction. Portability is what turns agent identity from a platform feature into evidence a counterparty can rely on.

A credential in which the agent asserts its own identity and signs that assertion with a key it controls. Nothing outside the agent vouches for the claim, so the credential proves possession of a key and says nothing about whether the attributes attached to it are true.

Inside one platform this can be adequate, because the platform provisioned the key, knows which account holds it and can revoke it. Across a trust boundary the same artifact reduces to a stranger's word about itself. A merchant receiving a self-signed credential learns that the caller holds a key, which tells it nothing about whether a real controller exists, whether the wallet being debited belongs to that controller, or whether the purchase sits inside any mandate. Key theft is the second failure, since there is no issuer to revoke and no status endpoint to consult. Treat self-signed material as a session identifier, useful for correlation and rate limiting, and refuse to let it carry authorization weight at the payment step.

A signed claim made by an issuer about an agent, for example that a named controller operates it, that it is bound to a specific wallet, or that its code was built from a particular source. What separates an attestation from an assertion is the presence of a third party willing to put its signature and its reputation behind the statement.

Attestations let a verifier reason about an agent it has never seen before, provided the issuer resolves and the claim is scoped and time-bound. Operators should read closely what each attestation actually covers, because an attestation of code identity says nothing about spending authority, and an attestation of the controller says nothing about whether the current instruction genuinely came from that controller. Freshness matters more here than in human identity work, since an agent's authority can change on the timescale of a single task. Two questions remain unresolved, who is qualified to issue attestations about agents, and what liability an issuer accepts when a signed claim proves false.

DIDs are identifiers that resolve to a document of public keys and service endpoints without depending on a central registrar, specified by W3C. The controller holds the keys, can rotate them, and the resolution method is encoded in the identifier string itself.

For agent identity the appeal is that no verifier has to join the same registry as the issuer, which matters when a merchant and an agent developer share no infrastructure. The unresolved part is control. If the agent holds the DID's keys, then compromise of the agent is compromise of the identity, and the controller has no fast way to intervene. If the principal holds them, the agent has to reach back for every signature, which is impractical at machine timescales. The designs that work in practice anchor the DID at the controller level and issue short-lived delegated credentials to each agent underneath it. Resolution latency also matters, since a checkout decision cannot wait on a slow resolver or a stale status list.

A W3C data model for claims that an issuer signs, a holder stores and presents, and a verifier checks without contacting the issuer. Selective disclosure lets the holder reveal only part of the claim set, with the signature still covering what was revealed.

The issuer, holder and verifier model fits agent commerce more cleanly than most human use cases, because the holder is software and can present a credential on every request without introducing user friction. Agent credentials are converging on this format for that reason. Two adaptations are needed. Lifetimes must be short or paired with a fast status check, since agent authority changes far quicker than a professional license does, and the presentation must be bound to the transaction so a captured one cannot be replayed against a different merchant. Verifiers also have to decide in advance what to do with a credential that is well-formed and correctly signed by an issuer they have never heard of, which in open agent commerce is the normal case.

SSI holds that the subject of an identity should control its own identifiers and credentials rather than rent them from a platform. The idea comes out of human digital identity work and underpins much of the tooling now being pointed at agents.

Applied to agents, the model runs into a question about who the subject actually is. An agent is not a legal person, holds no rights and has no interest of its own to protect, so sovereignty over its identity has to sit with the principal that deployed it. Treating the agent as the sovereign subject means an autonomous process holds keys that no human can pull quickly, which is precisely the wrong failure mode when that process is compromised or diverted. The defensible reading is that the principal is sovereign and the agent holds delegated, revocable credentials whose lifetime the principal sets. Anyone evaluating SSI-flavored agent identity should ask where revocation authority sits, because that answer determines whether an agent takeover can be contained.

Workload identity gives a running process a cryptographic identity derived from its deployment context rather than from a shared secret, with SPIFFE and its verifiable identity documents the most common implementation. It answers what code is executing, in what environment and under which service account.

This is genuine, checkable evidence and it maps directly onto the environment layer of an agent identity picture. What it does not carry is authorization. A workload identity confirms that a particular build is running in a particular cluster and says nothing about which customer's mandate the current request serves or whether the wallet being debited belongs to that customer. It also stops at the edge of the trust domain that issued it, so a merchant receiving traffic from an agent hosted elsewhere usually cannot validate it. Use it for what it is good at, detecting that a request came from an expected build in an expected environment, and pair it with a controller-level credential for the authority question.

IDV covers the methods used to confirm a person is who they claim to be, including document capture, database checks, biometric comparison and knowledge-based questions. It is the operational core of onboarding for regulated financial services.

Every method in that stack assumes a body, a document or a face, and none of them survives contact with a software actor. An agent has no passport to photograph and no face to compare, so the productive move is to stop trying to verify the agent and instead verify the human or company behind it once, then bind the agent to that verified principal with a credential the agent can present on every transaction. The binding, not the agent, is the object worth checking. Routing agent traffic through human IDV pipelines produces either mass false declines or a review queue with nothing in it to review. Whether an agent-initiated transaction inherits the principal's completed verification for compliance purposes is untested, and firms are currently deciding that for themselves.

Identity proofing establishes that a claimed identity exists, that the evidence supporting it is genuine, and that the party presenting it is its rightful holder. NIST frames the work as resolution, validation and verification, with assurance levels attached to how rigorously each step is performed.

The third step has no analogue for agents, because there is no presenter to bind evidence to. Software can hold and present anything it has been handed, so possession demonstrates nothing about entitlement. Proofing therefore has to run one level up, against the controller, after which the real problem becomes proving the link between that proofed controller and the specific agent instance in front of you. That link is the entire job, and it is carried by a signed binding rather than by any inspection of the agent itself. Expect the binding to need re-proofing when the controller changes, when the agent is redeployed under a different operator, or when the funding wallet is replaced, since each of those breaks the chain proofing established.

Entity resolution decides when separate records describe the same actor, using deterministic keys where they exist and probabilistic matching on names, addresses, devices and behavior where they do not. It sits underneath deduplication, linked-account detection and most fraud ring analysis.

Agents break the assumption that one actor equals one entity. A single template can spawn thousands of near-identical instances, each with its own ephemeral identifier and a near-identical fingerprint, so naive matching either collapses them all into one entity or treats every one as a stranger. Neither result is usable. The resolution key has to move to whichever layer is stable, normally the controller and the funding wallet, with the instance kept as a child record so per-instance behavior stays visible. The reverse case deserves equal attention, since one shared instance may serve many unrelated end customers, and collapsing on the agent identifier would merge those principals and pollute every downstream signal. Choosing which layer carries the entity is a design decision, not a matching threshold to tune.

A fabricated agent persona assembled from a mix of real and invented attributes so that it passes whatever verification a counterparty applies. It parallels synthetic identity fraud in consumer lending, where genuine identifiers are combined with invented details to create an entity that no real person stands behind.

The agent version is cheaper to manufacture, because the attribute set is smaller and most of it is self-reported. A plausible name, a developer account, a wallet with some transaction history and a self-signed credential can be sufficient anywhere verification stops at what the agent claims about itself. The usual pattern is to accumulate standing through small, uncontested transactions and then convert it in a short burst, which makes cross-merchant reputation both the main defense and the main target. Detection has to rest on the layers a fabricator cannot easily invent, principally a proofed controller with real-world existence and a wallet whose funding provenance can be traced. Any trust score built only on observed behavior is attackable, since behavior is the part the attacker chooses.

Claiming to be a known, trusted agent in order to inherit the access, limits or reputation attached to it. It is the agentic analogue of impersonating a trusted merchant or partner, except that the identity being borrowed belongs to software and is usually asserted rather than proven.

Where agent identity travels in a user agent string or a self-declared header, impersonation costs nothing beyond copying the string. Reputation systems raise the payoff, since a trusted agent name is worth stealing precisely because merchants treat it more loosely. The defense is to require a signature over the current request from a key bound to an issued credential, so that knowing the name is not sufficient to use it. Watch for the same agent identifier appearing from unrelated environments, wallets or controllers inside a short window, which is the clearest observable trace of a copied credential. Separating impersonation from agent takeover matters for response, since one calls for revoking a credential and the other for stopping a legitimate but compromised agent.

Liveness detection establishes that a real, present human produced a biometric sample rather than a photograph, a mask, a replay or a generated face. It is what keeps remote face and document verification meaningful.

No equivalent exists for software, and the gap is structural rather than a product that has not been built yet. There is no property of a running process corresponding to being alive, and any challenge a legitimate agent can answer a malicious one can answer too, since both are programs executing instructions. What can be checked instead is freshness and binding, meaning that the credential presented is current, that the request carries a signature made now by the key that credential names, and that the execution environment matches what was attested. Those substitutes defend against replay, not against a program pretending to be present. Stop looking for an agent liveness check and specify instead what evidence must accompany each transaction, because the anti-replay property is achievable and the presence property is not.

Under agency law and in payments practice, the principal is the party on whose behalf another party acts and who is bound by the result. In fraud and AML work the principal is usually obvious, being the cardholder, the account holder or the corporate customer whose credentials are in use.

When software transacts, the principal stops being visible at the point of sale. A merchant sees an API call, a wallet address and a session, none of which names the person who will be charged back, reported or asked to explain the payment. Reaching that party from a machine-generated request only works if the principal was bound to the agent at issuance rather than inferred at checkout. Where that binding does not exist, every downstream control degrades into judging behavior alone, which is exactly the evidence an attacker can shape. Treat any transaction where no accountable party can be named as unattributable rather than merely unusual.

The evidence question sitting behind every delegated action, which is whether the accountable human or organization at the root of an agent's authority can be named, verified and carried forward to the moment of payment. It is distinct from verifying the agent, because an agent can be cryptographically authentic and still trace back to nobody.

Establishing principal identity once at credential issuance and referencing it at every transaction is more reliable than reconstructing it under dispute pressure weeks later. The common failure is an identity that exists in an onboarding record but never travels with the request, leaving the merchant holding the loss with no route back to a person. Operators should require the principal to be resolvable from the transaction itself, through a verifiable link to identity evidence rather than a claimed name in a header. Watch for a single principal identifier reused across unrelated agent fleets, which usually means a service account is standing in for many real customers.

Day to day, some party configures an agent, holds its keys, deploys its code and decides what it does next. That party is the controller, and it is frequently a platform, a vendor or an employee rather than the principal who carries the liability.

The split between the two roles is normal and mostly benign, since a consumer using a shopping agent is the principal while the agent's developer is the controller. Risk appears when the split is hidden, or when the controller changes without the principal noticing, which is the ordinary shape of agent takeover. Record controller and principal as separate fields and alert on controller change, key rotation outside a declared process, or a controller that suddenly operates agents for thousands of unrelated principals. A control that reaches only the controller can be switched off by the controller, so revocation, kill switches and consent prompts have to terminate at the principal. Nominee arrangements live precisely in this gap.

Permission granted by a principal to another party to act on its behalf, bounded by what it covers, how much it may commit and how long it lasts. Payments practitioners know the pattern from powers of attorney, authorized users and stored credentials with agreed limits.

Agent delegation differs in being machine-readable, issued at scale and frequently broader than the principal understood at the time. A mandate written as unrestricted shopping is not a bounded grant, and a grant with no expiry becomes a standing key that outlives the intent behind it. Require authority to be expressed as explicit scope, value ceiling and validity window, and require the transaction to present the grant rather than assert one. The harder case is the agent holding valid authority that it uses for something adjacent, which reads as legitimate at every checkpoint while drifting away from what was actually approved. Authority that cannot be revoked within seconds cannot be priced by anyone accepting it.

The ordered record of grants running from the accountable principal, through every intermediary, to the agent making the current request. Each link states who authorized whom, for what, and under what limits.

A verification system that inspects only the last hop can be satisfied by a well-formed token issued by an intermediary that had no authority to issue it. Authority is a property of the whole chain, so a break, a gap or an unverifiable link anywhere invalidates everything below it no matter how clean the final credential looks. Require the chain to be presented and checked end to end, with each grant cryptographically bound to the one above it and no link permitted to widen the scope it received. Practical failure modes include chains that loop, chains terminating at a service account rather than a person, and chains reconstructed after the fact from application logs. A chain that cannot be replayed at dispute time will not function as evidence.

Authority that passes through one or more intermediaries before reaching the agent that acts, as when a consumer authorizes a platform, the platform authorizes an orchestrator, and the orchestrator authorizes a purchasing agent. Each transfer is a separate grant with its own scope, expiry and issuer.

Every hop is a place where accountability can be diluted or deliberately laundered. Intermediaries commonly re-issue authority under their own identity, which replaces a consumer principal with a corporate one and erases the original limits in the process. Watch for scope that grows across hops, for grants whose stated purpose changes between links, and for intermediaries that aggregate many principals into a single downstream credential so the merchant sees only the aggregator. The control point is the rule that no hop may grant more than it holds, enforced at verification rather than trusted at issuance. Firms should also decide in advance which hop they will pursue when a loss occurs, because that decision is difficult to make afterward.

A count of how many grants separate the acting agent from the accountable human or organization. Depth of one describes a person authorizing their own agent, while depth of five describes an agent several organizational boundaries away from anyone who can answer for it.

Depth is a usable risk feature because it correlates with attenuated oversight rather than with intent. Each additional hop increases the chance that limits were re-interpreted, that an intermediary's compromise goes unnoticed, and that no single party retains a full view of what was approved. Set explicit depth limits per transaction type, treat unexpected increases in depth for an established agent as a signal in its own right, and require stronger evidence as depth grows rather than accepting the same credential quality at every level. Depth alone should not block a payment, since legitimate enterprise architectures are genuinely deep, but depth combined with a new counterparty or an unusual amount deserves step-up or review.

An agent created by another agent to carry out part of a task, usually at runtime and often without any human being told it exists. Orchestration frameworks spawn them freely, which means the population of acting entities is dynamic rather than enumerable.

Capability propagates downward far more reliably than accountability does. A sub-agent typically inherits tools, credentials and network reach immediately, while the record of who authorized it, for what purpose and until when is frequently never written down. Operators should require sub-agents to carry a derived credential naming the parent grant and the same terminal principal, with scope that is a strict subset of the parent's, and should reject any request from an agent that cannot show its parentage. The signals worth alerting on are sub-agents that outlive the task that created them, sub-agents holding scope the parent never had, and sudden fan-out where one agent produces many spending children. A spawned agent with no traceable parent should be treated as an unknown party.

The condition where an action is verifiably authorized at every individual hop and yet no party will accept ownership of the outcome. It is a governance failure rather than a cryptographic one, since the signatures all validate and the loss still has no home.

Agent commerce produces this outcome routinely. The merchant points at the agent developer, the developer points at the model provider or the user's instruction, the user says they never approved this specific purchase, and the platform in the middle says it only passed a message along. Existing card and transfer rules were written for a human on one end and do not clearly assign responsibility for an autonomous purchase made within technically valid limits. Firms cannot wait for that to be settled by regulators or by litigation, so contracts and terms should state now who absorbs an unauthorized agent transaction, and verification records should capture enough to make that determination cheap rather than contested.

A design in which some class of action requires explicit human approval before it proceeds. In fraud operations the pattern is familiar from manual review queues, out-of-band confirmations and dual authorization on high-value payments.

The control is only worth what the human actually sees and understands at the moment of approval. Agent workflows tend toward high-volume, low-context prompts, and a person approving their fortieth confirmation of the day is providing consent in form rather than substance. Approval fatigue is exploitable, and an attacker who controls the agent also controls the summary the human is shown, which makes the approval screen part of the attack surface. Reserve human approval for decisions where the amount, the counterparty and the deviation from the mandate can be stated in one screen, and let scope and limits handle the routine cases automatically. Log what was displayed alongside what was approved, because a consent record without the presented facts is weak evidence later.

The regulated process of identifying and verifying a customer at onboarding and periodically afterward, with document, data and risk assessment steps proportional to the relationship. Sanctions screening, transaction monitoring and reporting all rest on the identity established here.

Nothing about KYC breaks when agents arrive, but its output stops describing the party that transacts. A verified customer can stand up a dozen agents in an afternoon, none of which was assessed, while the institution's file still shows one low-risk individual. The workable response is to treat KYC as the anchor for the principal and add separate verification of the agent covering who controls it, what it may spend and where its funds originate. Watch for customers whose volume, counterparty count or geographic spread changes sharply while their profile stays static, since that is what agent deployment looks like from inside a monitoring stack built for people. Refreshing the human's file more often says nothing about the software acting in their name.

Verification of a legal entity rather than an individual, covering registration, trading status, ownership, control persons and expected activity. It is the standard gate for merchant acquiring, business banking and platform seller onboarding.

For agent fleets, KYB becomes the practical route to an accountable party, because a company can be served, sanctioned, suspended and sued in ways that an autonomous process cannot. Expected activity descriptions should now cover whether the business deploys agents at all, roughly how many, what they are permitted to spend and which named humans hold the ability to revoke them. The failure to watch for is an entity onboarded as a small operator whose agent traffic quickly resembles a payment facilitator's, since that is a change in business model rather than a change in volume. Where a business operates agents on behalf of its own customers, KYB alone leaves you one layer short of the people actually spending.

Diligence extended one layer beyond the party you contract with, to the customers of that party. Correspondent banking, payment facilitation and marketplace models have long required it, usually as an exception applied to higher-risk relationships.

Delegation makes this the normal shape of agent traffic rather than an edge case. A platform's purchasing agent is nearly always acting for someone further back, so the counterparty you verified is rarely the party whose money and intent are at stake. Operators should ask their agent-operating customers to demonstrate that they can identify the principal behind each agent and produce that identification on demand, and should treat inability to do so as a limit on the volume and value they will accept. The signal that matters is the intermediary presenting itself as the principal, which flattens the chain and hides exactly the layer KYCC exists to see. Contractual pass-through of diligence duties works only if it is tested.

Assessment of the payment itself rather than the party, using amount, counterparty, timing, funding source and pattern to judge risk. Crypto and instant-payment programs lean on it heavily because the counterparty is often thinly known.

Its weight increases when the acting party is short-lived. An agent may exist for one session, hold a wallet funded minutes earlier and never be seen again, so behavioral history is thin and the transaction has to carry more of the assessment. Transaction evidence still cannot establish authority, which is why funds provenance and mandate checks belong alongside it rather than after it. Two agent-specific distortions matter operationally, the first being very high frequency at very low value, which slips beneath thresholds tuned for human spending, and the second being machine-regular timing that defeats velocity rules assuming human rhythms. Rebuild baselines per agent rather than per account, since one account can contain many agents with entirely different normal behavior.

The baseline set of measures a regulated firm applies to understand who its customer is, what the relationship is for and what activity to expect, refreshed on a schedule set by risk. Everything from monitoring thresholds to reporting quality depends on the quality of this profile.

Each element assumes a durable relationship, and agents often do not provide one. Purpose of relationship is unstable when an agent's task changes with each instruction, expected activity is unstable when capability can be extended by installing a tool, and the notion of a customer identity that persists between visits fails for agents created per session. The workable adaptation is to run diligence on the durable layer, being the principal and the controller, and to bind each ephemeral agent to that profile through a credential rather than profiling the agent independently. Where a firm cannot describe expected agent activity in its file, it should say so internally instead of recording an inherited human profile as though it still applies.

The deeper set of measures applied where risk is elevated, typically involving source of funds and wealth evidence, senior approval, tighter limits and closer ongoing monitoring. Triggers are usually defined by jurisdiction, product, customer type and politically exposed status.

What triggers EDD for a non-human actor is largely undefined, and no supervisor has published a settled expectation for it. That is a live gap rather than a stylistic one, and firms have to write their own triggers now and defend them later. Reasonable candidates include delegation depth beyond a stated limit, an agent whose controller and principal sit in different jurisdictions, wallet funding that cannot be traced to the principal, and any agent operating for a customer base rather than a single principal. Where EDD is applied, note that source of funds for an agent means tracing back to the principal's funding, since the wallet balance itself explains nothing. Document the reasoning, because the standard is untested and examiners will ask how it was set.

Identification of the real people who own or control a legal entity, as distinct from the directors, nominees or corporate layers appearing on the register. It exists because entities can be stacked to obscure the humans who actually benefit.

Agent structures repeat the problem in a different medium. Layers of orchestrators, service accounts and platform intermediaries can be assembled quickly and cheaply, and the resulting arrangement hides who benefits from a purchase just as effectively as a chain of holding companies. The direct analogue for an agent is the accountable principal, and the same discipline applies, which is that you resolve through the layers until you reach a natural person or an entity with its own verified owners. Watch for structures whose only apparent function is to add distance, and for agents whose stated principal has no plausible interest in the goods being bought. Ownership registers do not cover software, so this resolution has to be produced by the parties operating the agents.

The natural person sitting at the end of an ownership or control chain, identified by tracing through intermediate entities until no further legal person remains. Regulators require a terminal answer, not a nearest-layer answer.

Delegation chains need the same terminal answer, and for the same reason, since a chain that stops at another piece of software has told you nothing about accountability. The useful discipline borrowed from UBO work is refusal to accept an intermediate layer as the answer, and willingness to record that the chain could not be resolved rather than filling the field with the closest available name. In agent commerce the terminal party may be a consumer or a business, and where it is a business the two chains connect, because resolving the agent's principal leads into that entity's own beneficial ownership. Operators should build for the case where resolution fails, since an unresolvable chain is a decision point rather than a data quality issue.

An agent presented as operated by one party while in practice being directed by another, mirroring the nominee director or nominee shareholder used to keep a real controller off the record. The registered principal is real, verifiable and not the party making the decisions.

This is a cheap structure to build in agent commerce, because the visible identity layer can be entirely legitimate while control sits behind an API key held by someone else. A cooperative or compensated principal passes verification, holds the passport and absorbs the reputational history, while the actual operator stays outside every record. Detection depends on separating principal from controller and looking for mismatches between them, such as infrastructure, timing patterns or funding sources inconsistent with the declared principal, or one controller operating agents across many unrelated principals. Reputation systems are vulnerable here, since a nominee arrangement can be rotated once its history sours. Treat sudden principal changes on an established agent identity with the same suspicion as a change of registered director.

A purchaser who buys in their own name for the benefit of someone who cannot or will not buy directly, familiar from firearms, vehicle, property and card-not-present fraud. The defining feature is a real, verifiable identity used as cover for another party's transaction.

Agents make near-perfect straw buyers because they have no independent interest to protect, no reluctance to develop and no memory of being asked to do something questionable. They can be created in volume, each with a plausible principal and a clean history, and directed to buy on behalf of a party that would fail screening on its own. The controls that historically worked relied on human tells, hesitation, inconsistent stories and repeat appearances, none of which survive automation. What remains is structural, meaning verified linkage between the buying agent, its principal and the funding source, plus attention to delivery destinations and beneficiaries that do not match the declared principal. Where the beneficiary of a purchase cannot be reconciled with the principal, the transaction deserves review.

The gate through which a new customer, merchant or counterparty passes before activity is permitted, combining identity verification, screening, risk scoring and limit setting. Most fraud and AML controls assume this gate did meaningful work.

Agent onboarding has no branch visit, no document to inspect and no person on the other end, which removes the evidence classic onboarding was built around. What can be established instead is issuance-time binding, meaning that at the point a credential is created the agent is tied to a verified principal, a declared controller, a funding source and an explicit mandate. That binding is the only durable artifact, because everything after it is a request in flight. The operational risk is asymmetry, since an agent can be created in milliseconds while the diligence behind it takes days, so firms should decide what an agent may do before its principal's verification completes rather than discovering the answer under load. Onboarding also has to include revocation, which classic onboarding rarely treats as a first-class step.

Continuous refresh of customer diligence driven by events and data changes rather than by a fixed periodic review cycle. Firms adopting it replaced calendar-based refresh with triggers on ownership change, adverse media, behavior shift and sanctions updates.

For agents this stops being an efficiency improvement and becomes the only coherent model, because the subject can change materially between two requests. Code updates, tool additions, key rotations, mandate edits and controller changes all alter what an agent can do, and none of them announce themselves on an annual review schedule. The triggers worth wiring in are change of controller, expansion of authorization scope, new funding source, unexplained change in delegation depth and any sign of takeover. Verification then happens per transaction against current state rather than against a stored assessment, which is a heavier engineering requirement and a lighter operational one. A firm still refreshing agent records quarterly is describing a subject that no longer exists.

Verification performed once by a trusted party and presented repeatedly to others, sparing each relying party from repeating the work. Digital identity schemes and some regulated reliance arrangements already operate this way, with liability allocated by contract or by rule.

This is the direct precedent for a portable agent credential, where the checks establishing principal, controller, mandate and funding are done at issuance and carried into every subsequent transaction. The economics are compelling, since no merchant wants to run diligence on an agent it will see once, and the risks are the familiar ones, meaning stale attestations, unclear liability when a relying party trusts a credential that turns out to be wrong, and concentration risk in whoever issues at scale. Agents add a freshness problem that human reusable KYC does not have, because an agent's capabilities and controller can change after issuance. A reusable agent credential therefore has to be checked against live state at use rather than accepted on its face.

A mandate is the machine-readable declaration of what an agent may do on behalf of its principal. It enumerates permitted actions, value ceilings, acceptable counterparties, bound wallets and a validity window, and it is the object a verifier evaluates when the agent presents itself at transaction time. The nearest classic analogue is a corporate signing authority, which sits inside one institution rather than traveling with the payer.

What changes with agents is that authority now has to be legible to a counterparty that never onboarded the agent. A merchant receiving an agent-initiated order is otherwise left inferring intent from the order itself, which is exactly what an attacker wants. Mandates should be evaluated at the moment of the transaction rather than at session start, because an agent can run for hours and its task can be redirected midway. Operators should treat the mandate as the primary risk artifact and keep it narrow, since verification verdicts and later dispute evidence both resolve back to what the mandate actually said.

Identity and authority are separable properties. A mutable mandate is authority that can be amended, tightened or withdrawn at any time without reissuing the signed identity credential underneath it, so the agent stays the same agent while what it is allowed to do changes.

Binding the two together is a common design error in early agent systems, and it is expensive. If permissions live inside the signed identity, every policy change forces a new credential, which breaks reputation continuity and invalidates cached copies at counterparties. Separating them lets the signature stay stable while the mandate is read live at decision time. Freshness then matters, because a mandate is only as good as the copy the verifier consulted, so state has to be fetched or pushed rather than trusted from a long-lived cache. Mutability is also an attack surface, since whoever can widen a mandate can authorize spend, which makes controller authentication and an append-only change log part of the control rather than an extra.

Scope is the bounded set of actions an agent is permitted to take at a given moment. In access control terms it is the intersection of what the principal granted, what the platform permits and what the current context allows, resolved into a specific list of honored actions.

For human users scope stays largely implicit, bounded by what a person could plausibly do in a session and by interfaces that only expose so much. Agents have no such natural limit and will attempt anything their tooling exposes, including paths nobody expected to be combined. Scope for agents therefore has to be enumerated positively, as a list of permitted verbs, because the space of possible agent actions is not knowable in advance and exclusion lists will always be incomplete. The common failure is scope declared at the API layer but never enforced at the payment layer, so an agent refused a call can still move money through a different route. Evaluate scope per action, not per session.

Drift describes an agent's real behavior moving outside its declared scope while no permission was ever explicitly changed. It shows up either as new action types the agent was not meant to perform, or as familiar actions aimed at counterparties, amounts or frequencies that nobody intended when the grant was written.

Because nothing in the grant changed, this is a detection problem rather than a policy problem, and static mandate review will not find it. Causes are mundane as often as malicious, including prompt injection from a scraped page or invoice, task chaining where a sub-task inherits the parent's authority, and a model retrying in a way it did not last week. Operators should baseline each agent's observed action distribution and counterparty set, then compare live behavior against the declared scope rather than trusting the declaration alone. Drift is usually the right trigger for a review verdict rather than an outright block, since the controller may simply have moved the goalposts without updating the mandate.

Where scope drift is behavioral, authorization drift is structural. It is the slow accumulation of granted permission across time and across delegation hops, where every individual grant was defensible at the moment it was made and the aggregate is indefensible. Privilege creep in employee access is the same phenomenon at human speed.

Agent systems compound it faster for structural reasons that reduce to a lack of review. Grants are made programmatically, so no person sees them one at a time. Sub-agents inherit or are handed authority derived from a parent, so a chain can end up holding a superset of what any single mandate described. Temporary exceptions granted to unblock a workflow are rarely rescinded because nothing forces the question. The countermeasure is expiry by default, so authority decays unless reaffirmed, plus periodic re-derivation of scope from the task at hand rather than from the history of past grants. Operators should audit the effective permission of a delegation chain, not the permission of each hop.

Granting an agent broader authority than its task requires, usually because narrow scoping demands knowing the task in advance and reissuing authority whenever it changes. The operator trades blast radius for convenience, often without naming the trade.

In agentic commerce this shows up as generic purchase authority over a funded wallet, because nobody can predict which merchant a shopping agent will land on, and as a single mandate shared across a fleet, because per-agent mandates are administrative work. Both turn any single compromise into an unbounded loss, and both make post-incident attribution guesswork, since every agent in the fleet had the same authority. The fix is not exhortation to scope tightly, it is making tight scoping cheap. Mandates that can be amended in flight, per-agent rather than per-fleet, let an operator start narrow and widen on demand instead of provisioning for the worst case up front. Operators should look at what a compromised agent could spend today, not at what it normally spends.

A long-standing security concept describing a privileged component induced to exercise its authority on behalf of a caller who does not hold that authority. The original example was a compiler with write access to a billing file, tricked by a user into overwriting it. The deputy is not compromised, it simply acts for the wrong requester.

Agents are close to an ideal deputy. They hold credentials and wallet access, they act on natural language instruction, and they cannot reliably distinguish an instruction from data they were asked to read. A line of text in a product page, an invoice PDF or an inbound email becomes an authorization event. Identity verification does nothing to stop this, because the agent really is the agent and the signature really is valid. The control has to move to whether the requested action fits the mandate the agent was operating under, so an injected instruction to pay an unfamiliar wallet fails on counterparty and action checks regardless of how the agent was persuaded.

Manipulating the sequence and framing of grants so that an action which would be refused if requested directly gets approved as a downstream consequence of earlier, innocuous-looking approvals. Each step passes its own check, and no check ever runs against the real intent.

Multi-agent stacks are unusually exposed because every hop re-expresses the request in its own terms, and by the third hop the original constraint has been paraphrased away. A practical version looks like getting a quote from an unfamiliar counterparty approved as a read-only action, having that counterparty treated as known because it appears in prior activity, then having payment approved on the basis of a relationship manufactured minutes earlier. Defenses have to evaluate the terminal money-moving action against the original mandate rather than against the approval immediately preceding it, and the delegation chain has to travel with the request so a verifier can see the whole path. Systems that pass approval along as a bare boolean rather than as a signed statement about a specific action are the vulnerable pattern.

A ceiling on the value an agent may move, expressed per transaction, per time window, or in aggregate across the life of the mandate. Commercial card programs have used the same structure for decades.

Per-transaction ceilings are close to useless on their own once the payer transacts at machine frequency. An agent buying API calls, data or compute can execute thousands of individually trivial payments and exhaust a budget that a human would have taken months to spend, which makes aggregate and rolling-window limits the meaningful controls. Two implementation details decide whether the limit is real. It must be enforced by a party that can actually decline, not by logic inside the agent's own runtime that a compromised or manipulated agent will simply skip. And it must account for rails with no issuer able to reverse a settled transfer, which is where stablecoin payments differ sharply from card payments. Attach the limit to the mandate and check it at authorization time.

Constraining who an agent is permitted to pay, expressed as specific merchants, wallet addresses, domains or verified categories rather than as amounts or actions. It is a destination control rather than a behavior control.

Almost every fraud outcome requires value to reach a destination the attacker controls, so restricting destination defeats a large share of agent-side compromise regardless of how the agent was manipulated into wanting to pay. It stays underused because operators cannot enumerate merchants ahead of time, and an agent whose value is discovering new suppliers is crippled by a fixed list. The workable middle ground is a tiered one, with named counterparties permitted at full limits, verified or categorized counterparties permitted under lower ceilings, and a step-up to the controller on first payment to anything new. One implementation warning matters more than the rest. Restrictions written against display names or merchant strings are worthless against an agent reading a page, since names are trivially spoofed, so bind the restriction to cryptographic or account-level identifiers.

The time bounds on an authorization, covering when it starts, when it expires and whether it recurs. Absent an expiry, a grant is permanent, and permanent grants accumulate into authority nobody remembers issuing.

Human credentials pick up implicit expiry for free through session timeouts, devices locking and people going home. Agents run continuously and never log off, so nothing retires their authority unless it was designed to retire. Short windows bound the damage from a replayed or stolen mandate and force the controller to periodically reaffirm that this agent should still be doing this thing, which is the only routine moment when over-authorization gets noticed. Two operational points deserve attention. Clock handling across issuer, agent and verifier is an exploitable gap when parties disagree about the current time or about how expiry is interpreted at the boundary. And expiry is not a substitute for revocation, because an expiry hours away is hours of spending an operator cannot stop.

The enumerated verbs an agent may perform, named at the level of what actually happens rather than at the level of resources touched. Typical examples are checkout purchase, invoice payment, subscription renewal, refund request and quote retrieval, each granted separately.

The distinction between retrieving a price and paying an invoice is the distinction between reconnaissance and loss, which is why verbs rather than resources are the right unit of grant. Coarse permissions such as commerce access or wallet access recreate the exact problem enumeration was meant to solve, since they cover both. Two failure modes recur. Verb names that do not map cleanly to what settles, for instance a renewal permission that silently allows an amount change, leave a gap that looks closed on paper. And verbs enforced only in the agent framework, with no corresponding check where value moves, are documentation rather than control. Enumerated verbs also give the receiving merchant something concrete to compare against the order type it was actually presented with.

A positive control naming the parties, values or destinations that are approved, with everything not named refused by default. Payment operations and sanctions screening have used the pattern for a long time, and it is the strongest control available when the permitted set is knowable.

Agent commerce makes allow lists simultaneously more attractive and harder to run. More attractive because agent behavior is otherwise unbounded and a positive list is the only control that fails closed. Harder because a large part of an agent's value is finding counterparties the operator did not already know about, so a static list removes the reason for deploying the agent. The practical resolution is to allow-list high value flows only, permit discovery below a low ceiling, and require a step-up on first use of anything newly encountered. Whatever the policy, the list has to be carried in the authorization itself as machine-checkable identifiers, so the check runs at the point of payment rather than in a policy document nobody consults.

An enumerated set of prohibited parties, addresses or values, enforced at decision time. Sanctions lists, known-fraud merchant lists and blocked wallet addresses are the familiar forms, and unlike an allow list a deny list fails open against anything it has not yet heard about.

That gap widens with agents, which can be directed at a counterparty or a wallet address created minutes ago and will transact without the hesitation a person might feel about an unfamiliar destination. Deny lists still carry real weight for sanctions obligations, which attach to the transaction regardless of whether a machine or a person initiated it, and no agentic framing changes that duty. The common architectural mistake is screening at settlement, after the agent has already committed on behalf of the principal, when the decision needed to happen before authorization. Operators should also define what a deny hit does to the rest of that agent's activity, since an agent caught paying a prohibited destination should have its other in-flight actions frozen rather than left running.

A single control that halts an agent or an entire fleet immediately, independent of credential expiry, cache refresh or normal policy evaluation. It exists because the ordinary remediation path of rotating credentials and waiting for propagation is far too slow when the incident is unfolding at machine speed.

The design question is where the switch lands. A control that only stops the agent's own runtime is worthless against a compromised agent, since that is precisely the component that will not honor a request to stop. An effective kill switch reaches the point where transactions are authorized, which means an authoritative status that verifiers check before releasing value. Three operational details are routinely missed. Behavior for in-flight and authorized-but-unsettled transactions has to be defined in advance. The blast radius must distinguish stopping one agent from stopping every agent bound to the same wallet. And someone has to be able to pull it at three in the morning, which makes it an on-call procedure rather than a feature.

A reversible suspension of an agent's authority. The identity credential stays valid and the agent remains recognizable, while the mandate stops authorizing anything until the freeze is lifted. The closest classic analogue is a card block placed pending contact with the cardholder.

Agents throw off ambiguous signals constantly, including retry storms, a sudden change in merchant mix and volume spikes that turn out to be a legitimate batch job, and permanent revocation is a disproportionate answer to all of them. Reissuing identity breaks reputation continuity, invalidates wallet bindings and forces every counterparty to relearn the agent, which is why operators avoid it and end up doing nothing instead. Freeze gives them a proportionate response that preserves the ability to investigate, and it is the correct automated reaction to a suspected takeover because a false positive is recoverable in minutes. For it to mean anything, the frozen state must be what a verifier returns at transaction time, producing a block, rather than an internal flag that no counterparty ever sees.

Permanently withdrawing an agent's authority, together with the harder half of the problem, which is ensuring every party that might rely on the credential learns that it is void. Public key infrastructure has wrestled with the same distribution question for decades through revocation lists and status checking protocols.

Agent commerce sharpens it because the relying parties are merchants and payment providers outside the issuer's control, each free to cache status on its own schedule. A counterparty that refreshes agent status daily gives a revoked agent a full day of spending, and the operator will believe the agent was stopped. The design answer is verification against live status at transaction time rather than periodic list distribution. Revocation should also be clearly distinct from freeze, so that reputation history and dispute records are not ambiguous about whether authority ended or was paused. One gap worth checking is revocation that removes an agent from a directory but leaves its wallet bindings intact, which lets the same funds move under a freshly issued identity.

A crypto-native scam in which the victim is induced to sign a token approval granting a malicious contract standing permission to move assets from their wallet, with the drain executed later, sometimes much later. The signature is genuine and the transaction is valid, so on-chain controls see nothing anomalous at the moment of authorization.

Agents make this materially worse. They sign what they are instructed to sign, they do not experience the hesitation that approval prompts were designed to provoke, and an agent told to complete a swap will grant an unlimited allowance because it is the path with fewest steps. The gap to close is that a mandate permitting purchases frequently sits over a wallet permitting arbitrary contract interaction, so the authority actually exercised bears no relation to the authority granted. Granting standing permission should be its own enumerated action requiring separate authorization, approvals should be bounded to a specific amount and counterparty, and anything unbounded should step up to the human controller rather than resolving inside the agent.

Demanding additional proof when risk rises above a threshold, rather than applying the same friction to every transaction. Card payments have used the pattern for years through challenge flows, one-time codes and biometric re-authentication, built on the assumption that a person is present and reachable.

That assumption collapses when the payer is autonomous. A push notification to a phone at two in the morning fails, and a legitimate sale is lost. The opposite failure is quieter and worse, where the agent can satisfy the challenge itself by reading the controller's inbox, in which case the step-up proves nothing an attacker could not also produce. Agentic step-up has to be something an authorized agent can generate and an unauthorized one cannot, which in practice means a fresh signature over the specific transaction from the key bound to the passport, a controller co-signature, or an explicit mandate amendment. Operators should separate step-ups meant to confirm identity, which the agent can answer, from step-ups meant to expand scope, which must reach the human.

The European requirement under PSD2 that most electronic payments be authenticated with at least two independent elements drawn from knowledge, possession and inherence, subject to exemptions such as low value, recurring and trusted beneficiary payments. The rule was drafted around a human payer present at the moment of payment.

An autonomous agent does not fit that model, and current practice papers over the gap in two unsatisfying ways. Either the agent transacts on stored credentials under a merchant-initiated or recurring exemption, which stretches the exemption past its purpose, or the human is pulled in to complete a challenge, which removes the reason the agent existed. Whether an agent acting under a documented, verifiable mandate satisfies SCA, or whether the mandate itself should count as the authentication event, is unresolved, and it will be settled by regulators and card schemes, not by individual merchants. Until then, operators should record which exemption they relied on and retain evidence of the agent's authority, because that evidence is what a later dispute will turn on.

Authentication using two or more independent elements drawn from different categories, conventionally something the user knows, something the user has and something the user is. Independence between categories is what gives the scheme its strength.

Applied to agents, the taxonomy falls apart. There is no inherence, because there is no body and no biometric to measure. Possession degrades too, since the device is a process that can be duplicated and the secret is a file. Knowledge factors are strings in the agent's context, readable by anything that can inject into it. An agent given access to all of the principal's factors so it can act unattended destroys the independence the scheme depends on, and holding three factors in one process is single-factor authentication with extra steps. What survives is cryptographic possession of a key the agent cannot export, which makes key custody effectively the whole of agent authentication. The useful questions become whether the signature came from the key bound to the passport and whether the action sits inside the mandate.

A single-use code delivered over a separate channel, typically SMS or email, which the user returns to prove they control that channel at that moment. It is treated as a possession factor and remains one of the most widely deployed authentication mechanisms in payments despite known weaknesses.

Where an agent holds the channel, the proof becomes circular. An agent with inbox or messaging access retrieves the code and demonstrates that it controls the inbox, which was already true and says nothing about whether this particular payment was authorized. The problem is compounded by design, since agents are frequently built to fetch codes deliberately so they can operate unattended, which makes the fraudulent path and the intended path byte-for-byte identical and leaves no signal to separate them. Any takeover of that agent inherits the same access and the same code-retrieval capability. Operators should treat a successful OTP from an agent as evidence of channel control only, and require a mandate check plus a signature bound to the specific transaction before releasing value.

Provenance is the accumulated history behind a payment instrument, covering the sources that funded it, the counterparties it has settled with, and the risk exposure it has picked up. On-chain it means tracing a wallet address backward through its inbound transfers; on card and bank rails it means the funding chain behind a token or account. It reads as a graded signal rather than a pass or fail.

An agent wallet usually has almost no history, funded minutes ago and spending immediately, so address age and transaction count carry no information. Provenance for agents has to answer who funded this instrument and under what authority, not merely where the value originated. Because stablecoin settlement is final, it must be evaluated before the transaction is signed, since nothing useful can be done with the answer afterward. Freshly created wallets are the normal state for an agent fleet rather than an anomaly, so scoring has to lean on the funding parent and the principal behind it instead of on address age.

A wallet, balance or credential an autonomous agent can draw on to pay for goods, services or API calls without a human approving each spend. It may be a self-custodied key held in the agent's runtime, a custodial balance in a platform account, a network token issued to the agent, or a spending handle exposed through a tool interface.

Where the key lives and how the balance is funded determine the blast radius of a compromise. An agent holding a hot key with an unlimited balance loses everything on one bad signature; the same agent with a just-in-time funded balance and a per-merchant ceiling loses the cost of one order. Funding policy is therefore a fraud control, and should be sized to the worst plausible outcome of a prompt injection. Watch for keys sitting in model context where retrieved content can reach them, wallets shared across many agents so that attribution collapses, and standing token approvals that outlive the task that justified them.

Checking a wallet address against sanctions designations, known-illicit clusters and risk-scored attribution data to decide whether to accept, hold or reject a transfer. It runs pre-transaction at onboarding or quotation, at transaction time in the authorization path, or retrospectively in transaction monitoring.

Agent payments compress the usable window to nothing. Human checkout leaves seconds or minutes for a hold-and-review pattern, while agent-to-agent settlement on stablecoin rails completes in a single call with no recovery afterward. Screening therefore has to sit inline with a latency budget in the low hundreds of milliseconds and return a verdict the orchestrator can act on rather than a score for an analyst to read later. It also has to run on both sides, the counterparty address and the agent's own funding wallet, because an agent spending tainted funds is the receiving merchant's problem too. Cached results go stale fast when addresses are generated per task, so cache lifetimes tuned for stable human accounts will quietly stop protecting anything.

Heuristic and behavioral grouping of on-chain addresses believed to sit under one controlling entity, inferred from co-spend patterns, funding relationships, change-address behavior and timing. It exists to turn thousands of addresses into a handful of actors an investigator can reason about.

Agent fleets generate address sprawl at machine rate, which is exactly the problem clustering was built for, but they also break the heuristics it depends on. Addresses created fresh per task, per merchant or per session have no co-spend history to cluster on, while orchestration platforms that pool many unrelated customers behind one funding wallet cause over-clustering that merges distinct principals into a single false actor. The durable identifier for agent activity is not the address, it is the principal and the mandate the spend was issued under. Operators should expect clustering output on agent traffic to be either sparse or misleadingly dense, and should join it to off-chain agent identity evidence instead of treating cluster membership as ground truth.

An address designated by a sanctions authority, most commonly OFAC, which publishes specific virtual currency addresses alongside named persons and entities. Dealing with a designated address is prohibited regardless of transaction value or the sender's intent, and liability does not require knowledge.

An agent has no instinct for this. It will pay a designated address as readily as any other if that is what the invoice, the tool response or an injected instruction supplied, and it will do so within a fraction of a second. Because on-chain settlement is final, a violation cannot be undone by reversing the payment, only disclosed and remediated. That makes the sanctions check a gate before signing rather than a rule in overnight monitoring. Operators should watch specifically for destination addresses that arrive through payment metadata the agent did not itself originate, and for near-miss addresses introduced by poisoning. Who carries liability for an agent-initiated violation, the principal or the platform that ran the agent, is untested.

A graded measure of how close a wallet sits to known criminal activity, distinguishing direct exposure, where funds arrive straight from a designated or criminal source, from indirect exposure several hops away through mixers, bridges and intermediaries. Vendors express it as a score or as a share of tainted value rather than as a binary answer.

Graded scores assume a human analyst weighing context before acting. An agent needs a decision, which means the operator must convert exposure bands into concrete verdicts, allow, step up to a human, or block, and must fix those thresholds before the agent runs rather than during an incident. Indirect exposure is common and noisy for agent wallets funded through exchanges and bridges, so a strict indirect threshold will reject a large share of ordinary traffic while a loose one accepts nearly everything. A more useful signal for agent flows is whether exposure appeared after the mandate was issued, which suggests the agent has been steered toward a counterparty nobody authorized.

The regulated point where fiat becomes crypto, typically an exchange, broker or embedded provider that accepts a card payment or bank transfer and credits a digital asset balance. Identity verification, sanctions screening and source of funds checks concentrate here because it is one of the few boundaries the regulated system genuinely controls.

Ramp controls are built on the assumption that a person is opening the account and can be identity-proofed, liveness-checked and challenged when something looks wrong. Agents do not open ramp accounts, their principals do, and the agent inherits the resulting balance without inheriting any of the identity evidence attached to it. The result is a gap between a verified human at the ramp and unverified software spending downstream hours or months later. Operators should treat the ramp's due diligence record as evidence about the principal only, and require separate proof of which agent is authorized to spend that balance, up to what value, and with which counterparties.

Conversion of digital assets back into fiat, through an exchange withdrawal, a payout provider, a crypto-funded card, or a merchant settling proceeds to a bank account. Laundering typologies aim here, because value that cannot be spent in the ordinary economy has limited use.

Agent-driven flows reach the off-ramp faster and in more fragments than human ones. A fraudulent agent spend settles on-chain in seconds, passes through a merchant or payout provider, and exits before anyone reviews the authorization that produced it. Institutions on the receiving side increasingly take in funds moved by software under delegated authority, with nothing in the payment telling them who authorized the spend or whether the authorization was still valid. The practical control sits upstream, in evidence captured at authorization that the agent was acting inside its scope, carried forward as a signed record the receiving institution can actually read. Detection at the off-ramp still matters, but by then the question is reporting rather than prevention.

Evidence explaining where a specific pool of money came from, distinct from source of wealth, which explains how a customer accumulated assets overall. AML programs require it at onboarding and at trigger events, and expect support that can be documented, payroll, proceeds from an asset sale, a corporate treasury transfer.

For an agent wallet the honest answer is usually one hop deep and then stops. The wallet was funded by a treasury account or a platform balance, and unless someone deliberately bound that funding event to a principal, the trail ends at an internal transfer that explains nothing. Anyone downstream sees a fresh address with a recent inbound transfer and no narrative. Making agent source of funds meaningful requires the funding event itself to carry a principal identity and a mandate reference, and requires that binding to travel with the payment rather than living in the funder's private ledger. Without it, every agent wallet presents as an unexplained new account.

An attacker sends a tiny or zero-value transfer from an address crafted so that its first and last characters match one the victim regularly uses, placing the lookalike into the victim's transaction history. The victim later copies the wrong address out of that history and sends real funds to the attacker.

The attack exploits the habit of selecting a payee from recent activity instead of re-verifying it, which is precisely what an agent does when it resolves a destination from context. An agent reading history, an email, an invoice or a tool response has no visual sense that two strings differ in the middle, and truncated display formats hide the difference entirely. The defenses are structural rather than perceptual, never resolving a payee from history, pinning destinations to a verified counterparty identity or registry entry, and comparing the full string at signing time. Because the resulting transfer is final, discovering the substitution afterward produces a report and nothing else.

Malicious code, usually delivered through a spoofed site or a crafted signature prompt, that obtains a token approval or permit signature and then empties the wallet of everything that approval covers. The theft occurs later, on the attacker's schedule, using permission the victim granted voluntarily.

Drainers depend on someone approving a request they did not read carefully. Agents do not read in that sense at all, they evaluate whether an action advances the assigned task, and an approval request framed as a required step to complete a purchase will be signed without hesitation. Unlimited approvals are the specific hazard, because one signature converts into standing access to the entire balance for as long as it remains unrevoked. Operators should cap approvals to the exact amount and counterparty, expire them with the task, and treat any request for an unbounded allowance as grounds for a human step-up. A drained agent wallet is also hard to spot in monitoring, since transacting at odd hours at machine speed is what agents normally do.

FATF Recommendation 16 requires originator and beneficiary information to accompany qualifying transfers between regulated institutions, extended to virtual asset transfers so that both ends of a crypto payment carry identifying data. Jurisdictions differ on thresholds, required fields and the messaging protocols used to exchange them.

The rule assumes a natural or legal person at each end of the transfer. It offers no representation for software acting under delegated authority, and no agreed field for the agent that initiated the payment or the mandate it was operating under. In practice the principal's details are transmitted and the agent vanishes from the record, which defeats the purpose when an investigator later asks who actually moved the money. Whether an agent must be named, and whether an orchestration platform is itself a covered institution, is unresolved and will be settled by regulators and standards bodies rather than by vendors. Firms building now should capture agent and mandate identifiers alongside their Travel Rule payloads so the data exists when the requirement lands.

FATF defines a virtual asset as a digital representation of value that can be digitally traded or transferred and used for payment or investment, excluding digital representations of fiat currency, securities and other assets already covered by existing standards. Stablecoins fall inside the definition in most jurisdictions that have addressed them.

This is the layer where agent value actually settles. Card rails require a merchant account, a dispute process and an identity model shaped around a human cardholder, while a stablecoin transfer requires an address and a signature, which is exactly what an agent can produce unaided. The consequences follow directly, settlement is final, there is no chargeback, and no issuer sits in the middle to absorb loss when something goes wrong. Controls built for reversible rails, dispute rights, retrieval requests, representment, have no counterpart here at all. Risk decisions therefore have to move ahead of the signature, because after it there is no decision left to make.

FATF's category for businesses that exchange, transfer, safekeep or administer virtual assets on behalf of others, covering exchanges, custodians, many wallet providers and certain brokers. Classification as a VASP triggers licensing, customer due diligence, sanctions screening, Travel Rule and transaction monitoring obligations.

VASPs are now onboarding accounts that will be operated by software, in some cases as an advertised product feature. The customer of record remains a person or a company, but the entity generating transactions is an agent, and existing due diligence has no field in which to record it. Nothing in current frameworks obliges a VASP to identify the agent behind an account, so practice varies widely, and closing that gap is a job for regulators rather than something individual firms can standardize alone. The operational risk arrives sooner than the regulatory one, because behavioral monitoring calibrated on human transaction rhythms either fires continuously on agent traffic or gets tuned down until it fires on nothing.

Moving value across blockchains through bridges, swap services or exchange deposit and withdrawal pairs in order to break the continuity of on-chain tracing. Each hop forces an investigator to re-acquire the trail on a different ledger, often with different tooling and a different data provider.

Manual chain hopping took hours or days and left human-paced gaps that investigators could work inside. An agent holding bridge and swap tools performs the same sequence in a handful of calls, and can run several routes in parallel, so funds have crossed multiple ledgers before the first alert is triaged. Deterministic tracing degrades into probabilistic attribution very quickly under those conditions. The workable answer is not faster tracing, it is declining to release value to an unverified counterparty in the first place. Operators should also expect legitimate agents to hop chains routinely for gas cost or liquidity reasons, which means benign and evasive behavior are close to indistinguishable from on-chain data alone.

A laundering structure in which a large balance moves along a sequence of transactions, each one peeling off a small amount toward a cash-out point while the remainder continues forward. Every individual peel stays below reporting and alerting thresholds even though the aggregate is substantial.

Peeling is tedious for a person and effortless for software. An agent can maintain the schedule indefinitely, vary amounts and intervals to defeat periodicity detection, and rotate the destination address on every peel without error or fatigue. Agentic nanopayments make the pattern harder still, because paying fractions of a cent for API calls is ordinary agent behavior that gives small-value transfers a plausible cover story. Threshold-based detection is the wrong instrument against an adversary that can pick any amount it likes; what surfaces the pattern is aggregation across a controller rather than across a transaction. That in turn depends on being able to attribute many addresses to one agent or one principal, which is the harder problem underneath.

A transfer the payer initiates and the payer's institution executes on the payer's instruction, moving funds outward. Wires, instant bank transfers and on-chain transactions are push payments, and once sent they carry no chargeback right and no automatic route to recovery.

Nearly every agent payment is a push. The agent decides to pay, constructs the transaction and signs it, with no issuer authorizing on the payer's behalf and no dispute process sitting behind the transfer. That places the entire loss on the paying side and makes the authorization moment the only genuine control point in the flow. Recipients get the mirror-image benefit, funds that cannot be pulled back, which is much of why merchants and API sellers find agent payments attractive in the first place. Operators running paying agents should assume every spend the agent executes is permanent, and should size mandates, balances and per-transaction ceilings on that assumption rather than on an expectation of remediation.

A transfer the payee initiates against permission the payer granted at an earlier point, such as a card charge on file, a direct debit, or a token-based recurring bill. Separating the grant of permission from its exercise is what makes standing authority useful and what makes it dangerous.

An agent mandate is a pull permission in structure, since a merchant, platform or downstream service draws against a scope the principal granted earlier and may not remember granting. The discipline that grew up around direct debits, mandate references, advance notice, cancellation rights, indemnity schemes, has no equivalent for agent authorizations. Scopes are commonly granted broadly, stored indefinitely and never re-consented, so an authorization issued for one purchase can remain exercisable for months. Operators should give every agent authorization an explicit expiry, a value ceiling and a named counterparty, and should hold a revocation path that works centrally rather than requiring the principal to cancel merchant by merchant.

Fraud in which the victim is deceived into sending the money themselves to an account the fraudster controls. Because the payment is genuinely authorized, controls looking for unauthorized credential use see nothing wrong, and liability regimes have been rewritten around who bears the loss when consent was real but induced.

When the deceived party is an agent, the consent is cryptographically perfect and substantively empty. A prompt injection, a poisoned tool response or a spoofed invoice redirects the destination, and the agent signs with valid credentials inside its granted scope. Signature checks, credential checks and scope checks all pass, and nothing in the payment records that the instruction came from retrieved content rather than the principal's intent. What remains detectable is contextual, whether this counterparty is one the mandate contemplated and whether the payee came from the plan or from data the agent read along the way. Reimbursement frameworks written for deceived consumers do not obviously extend to a business whose software was deceived, and that gap is unresolved.

Fraud on rails that clear and settle within seconds and are irrevocable once settled, including instant bank schemes and on-chain settlement. The detection window collapses onto the authorization moment, and any recovery depends on the receiving institution freezing funds before they move again.

Agent commerce runs almost entirely on rails of this kind. Two speeds compound, because the rail settles instantly and the agent decides instantly, leaving no human pause between intent and irreversible action. Batch review queues, next-day analyst triage and post-transaction rule packs will still produce findings, but findings are not recoveries when the funds have already been bridged and cashed out. Anything that actually protects value has to execute inline before authorization, inside a latency budget the agent will tolerate, and has to return a verdict the orchestrator can act on rather than a score for someone to read later. Operators should measure their control coverage by the share of decisions made pre-settlement, not by aggregate detection rate.

Fraud on transactions where the card is not physically presented, covering e-commerce, telephone orders and in-app purchases. Liability generally rests with the merchant unless the transaction was authenticated, and the available controls are all inferential, device data, address verification, velocity limits and behavioral signals.

An agent is the limiting case of card-not-present. There is no card, no shopper device, no browser fingerprint that means what it used to, and no typing cadence or cursor movement to model. Signals that carried most of the weight in CNP scoring either disappear or turn actively misleading, because datacenter addresses, headless runtimes and identical device profiles across a fleet all resemble classic fraud patterns. Merchants have to choose between scoring agent traffic on evidence that no longer describes it and requiring a different class of evidence, namely proof of which agent is transacting and under whose authority. Blocking on legacy signals rejects legitimate agent business, while ignoring them accepts everything that arrives.

EMV 3-D Secure lets the card issuer authenticate the cardholder during an online purchase, either silently using risk data supplied by the merchant or by challenging the shopper with a one-time code or in-app approval. A successful authentication shifts chargeback liability from merchant to issuer, which is the main commercial reason merchants adopt it.

The whole model assumes a shopper who is present and can be interrupted. An agent transacting on the principal's behalf has nobody to prompt, and a challenge routed to the principal's phone in the middle of an unattended task either times out or trains the principal to approve without looking, which hollows out the control. The frictionless path is no better, since it depends on device and browser telemetry that agent traffic cannot supply honestly. What earns the liability shift when there is no shopper to authenticate is an open question the networks will have to answer. Until they do, merchants accepting agent traffic carry CNP liability with the main mitigation unavailable.

Running large volumes of small or zero-value authorizations against a merchant to discover which stolen card numbers are still live, often on checkout endpoints chosen for their low friction. The merchant absorbs authorization costs, decline-rate damage and eventually chargebacks on the cards that get used elsewhere.

Agent infrastructure industrializes the pattern. Frameworks built to let agents shop, with session handling, form completion and retry logic already solved, are directly reusable for high-volume testing, and machine-readable checkout designed for agent access removes the friction that CAPTCHAs and behavioral interstitials used to add. Separating a testing bot from a legitimate agent making many small purchases cannot be done on velocity or automation signals, because both are fast and both are software by design. The separator is identity and authority, whether the requests carry a verifiable agent credential bound to a principal with a real mandate and a plausible reason to be buying. Any merchant opening a machine-readable checkout should assume it will be probed.

Replacing a sensitive credential, typically a primary account number, with a substitute value that is useless outside a defined domain. Network tokens can be restricted to a merchant, a channel or a device, and can be re-issued or revoked without disturbing the underlying account.

Card networks have begun issuing agent-specific credentials so that an agent transacts with its own token rather than with the principal's card number, which is structurally the right move. The unfinished parts are scope and revocation. A token issued to an agent needs a value ceiling, a merchant or category restriction, an expiry tied to the task rather than to the card's expiration date, and a revocation path the principal can trigger in one place the moment the agent misbehaves. Without those properties an agent token is a card number with better breach hygiene and nothing more. Operators should also insist the token carries agent identity into the authorization message, because otherwise the issuer approves a transaction with no way to tell which agent made it.

Environment identity covers what a risk system can learn about where and how a request is executing rather than who is making it. In human channels that meant the device, the browser, the network path and the app build. For agents it means the workload, the container image, the orchestration layer and the credentials the runtime itself holds.

The shift is that environment stops being a proxy for a person and becomes evidence about a process. A stolen credential replayed from a different workload is the agentic equivalent of a device change, but the classic stack does not notice, because containers are built to be interchangeable. Workload identity standards such as SPIFFE give the execution context its own attestable name, which lets a counterparty ask whether this is the context the principal delegated to. Capture environment at authorization and again at settlement, since agents can be rescheduled onto new infrastructure mid-task. Who attests an environment the merchant cannot see is unresolved, and agent platforms have to answer it.

A runtime identity names the process that is actually executing, cryptographically and independently of any token that process presents. Workload identity systems in the SPIFFE mold issue such names to running instances and rotate them automatically, so the identity belongs to the process rather than to a secret someone can copy. Bearer credentials answer what was presented, not what is running.

For agents the gap between credential and runtime is the main attack surface. An agent's API key, mandate reference or wallet credential can be exfiltrated and replayed from anywhere, and downstream systems will treat the replay as the agent. Binding the credential to an attested runtime means a stolen token presented from an unattested process fails on evidence rather than on rate limits. Record the runtime identity alongside the authorization decision, so a later dispute can show which process spent the money. Coverage is incomplete today, because many agent frameworks run on hosts that expose no attestation at all, and the merchant has to decide how to treat that absence.

Continuity asks whether the process acting now is the same process that acted a moment ago, across a task that may run for hours. Classic sessions answered this with a cookie, a token and an idle timeout. None of that survives an execution model where work is suspended, checkpointed and resumed on different infrastructure.

Agents break the assumption that a session maps to one continuous process. A long-running task can legitimately migrate between workers, and an attacker who captures state mid-task can resume it with the same credentials and the same conversation history. What an operator wants is a chain of attested runtime identities across the task, so a resumption from an unexpected workload reads as a discontinuity rather than a normal reconnect. Payment steps are the right place to enforce it, because the cost of a wrong continuity call is highest when funds move. Where the agent platform provides no attestation, continuity has to be inferred from weaker evidence and should be scored rather than asserted.

Consistency of an agent's operating pattern over time, held as a baseline of what that agent normally does. Merchants visited, request cadence, typical order value, tool call sequences and error handling all contribute to the profile. Deviation from it is the software analogue of the anomaly checks run against human accounts.

The value is in detecting substitution. An agent that has spent months buying office supplies from three suppliers, and now opens accounts at unfamiliar merchants and pushes value toward stored-value products, probably still holds a valid credential and is no longer doing the principal's work. Because agents are far more repeatable than people, baselines converge faster and tighter, which makes small deviations meaningful earlier than they would be in a human channel. The risk runs the other way too. A model or prompt update can shift behavior legitimately overnight, so operators need to tell a released change from a compromise, which in practice means tying the baseline to a declared model and tool version.

Observable characteristics that indicate which model is driving an agent, inferred from latency distributions, token usage, output formatting habits, tool call structure and whatever provider metadata is exposed. It is not a cryptographic identifier and should not be treated as one. At best it yields a probabilistic view of model family and version.

Model choice matters to risk because it changes how an agent behaves under adversarial input. A swap from a hardened frontier model to a cheap self-hosted one raises injection susceptibility and error rates without touching any credential or scope, so nothing in the authorization layer moves. Providers do not generally sign an attestation of which model produced a given output, so fingerprinting fills the gap imperfectly, and its value as a production control is untested at scale. Treat an unexplained model change the way a device change is treated, as a reason to re-verify rather than to block. The durable fix is a signed declaration of model identity from the agent platform, which is not yet standardized.

A hash over the set of tools and connectors an agent is able to call, captured at a point in time. The manifest describes capability rather than intent, but capability sets the outer bound on what any instruction can cause the agent to do. Comparing fingerprints across sessions shows whether that bound moved.

A change in the tool manifest is a change in effective authority, which is why it belongs in the evidence set rather than in engineering telemetry. An agent granted a payments connector it did not have last week can now do things its original mandate never contemplated, even though the mandate text is unchanged. Injection attacks often work by getting an agent to reach for a tool that was always present but never used, so record use as well as possession. For merchants the control is to require the manifest fingerprint in the authorization evidence and treat expansion before settlement as a scope event. Nothing obliges an operator to disclose the manifest today, so this starts as a contractual ask.

Instructions smuggled into content a language model processes, written so the model treats them as directives from its operator. The classic framing is a control-flow attack against a system that cannot reliably separate data from instructions. No credential is stolen and no network boundary is crossed.

What makes this a fraud problem rather than a security curiosity is that the agent keeps acting under valid authority throughout. Every signature checks out, the mandate is real, the wallet is the right wallet, and the money still reaches the attacker's chosen destination. Detection cannot live at the credential layer and has to compare what the principal authorized against what the agent is now trying to do. A transaction whose beneficiary, amount or merchant is not derivable from the original instruction is a step-up candidate, regardless of how clean the credentials look. Because the injection arrives in content the agent read, retrieval evidence matters as much as the payment payload, particularly which sources the agent consumed before it changed course.

Injection delivered through third-party content an agent fetches during a task, such as a product page, a review, a PDF or an email body, rather than through anything the operator typed. The attacker needs no access to the agent or its principal. They only need to control something the agent will read.

This is the more realistic attack against commerce agents, because shopping and procurement workflows read untrusted merchant-controlled content by design. A hostile listing can instruct an agent to change the shipping address, add an item, or check out at a different merchant, and the agent does all of it with legitimate credentials. Merchants sit on both sides of it, since their own user-generated content can be the vector against someone else's agent. Retrieval provenance is the signal worth capturing, meaning which domains the agent read and whether the eventual counterparty appears anywhere in the original instruction. Liability for an injected transaction is unsettled and will be decided by network rules and contracts, not by existing chargeback reason codes.

Continuous scoring of an active session rather than a single verdict at login or checkout, updated as events accumulate. In human channels a session has natural edges, opened by an authentication and closed by a logout or a timeout, and risk is recomputed as the user moves between pages and actions.

Agents dissolve those edges. A procurement agent may hold credentials and act for a principal for months with no authentication event in between, so the session is effectively the whole relationship. Scoring has to run against a baseline built from that relationship, and the meaningful triggers become mandate changes, tool manifest changes, model changes and new counterparties rather than login anomalies. The consequence for operators is that the decision has to be recomputed per transaction with full relationship history attached, never cached from the last verification. Scoring also has to survive an agent going quiet for weeks, which classic decay models handle badly because they read inactivity as abandonment rather than as a task that has not come due.

Constructing a stable identifier for a device from exposed attributes such as screen dimensions, installed fonts, GPU characteristics, timezone and browser and OS versions. The value comes from persistence. The same device recurring across unrelated accounts links them, and a new device on a known account is a signal worth acting on.

Agents break the premise in both directions. Execution happens in containers built from identical images, run for the length of a task and destroyed, so thousands of unrelated agents produce indistinguishable fingerprints while a single agent produces a fresh one on every run. One failure collapses distinct actors into a single identity, the other fragments one actor across many, and both corrupt any linkage analysis built on top. Operators who keep device fingerprinting in agent channels should expect it to work only as a coarse infrastructure indicator, useful for spotting residential proxies and unusual client stacks. The replacement signal is attested workload identity, which is deliberately stable across restarts and deliberately unique per workload.

Tying a credential to specific hardware so that possession of the secret alone is not enough, usually through a key held in a secure element and released by a local biometric. Passkeys and mobile banking app registrations are the familiar implementations. The recovery path, where a customer moves to a new phone, is the known weak point and is heavily targeted.

Agent credentials have no phone to bind to, so the equivalent is binding to an attested runtime or to a key held in an HSM or KMS that the agent can use but never export. The rebinding problem transfers directly and gets worse. Agents are redeployed constantly, and any flow that lets a redeployed agent re-register itself becomes the enrollment attack of the agentic era, with no human present to notice an unexpected approval prompt. Require the principal rather than the agent to approve rebinding, and treat each rebinding as a high-risk event deserving its own verification rather than as an operational formality.

The consolidated view a risk platform builds from device signals, combining fingerprint stability, tampering indicators, emulator and rooting checks, network context and historical association with accounts and confirmed fraud. It functions as a single answer to whether the endpoint is what it claims to be.

Reframed for agents, the discipline points at the execution environment instead of the endpoint, and most of the questions survive the translation. Whether the runtime is attested, whether the environment matches previous runs by this agent, whether the infrastructure carries prior abuse, and whether the reported signals can be trusted at all are all still worth asking. What does not survive is the inference that a consistent device implies a consistent person, because the human is absent by design. Keep environment evidence separate from principal identity in the evidence model rather than folding one into the other, since an environment that checks out says nothing about whether the human behind the agent authorized this particular purchase.

Risk carried forward by a specific piece of hardware, so a device implicated in confirmed fraud raises the score on every account and transaction that touches it afterward. Precision is what makes it work. The unit of reputation is one physical object with, in the normal case, one owner.

Agents have no such unit. The nearest equivalents are IP ranges, ASNs, container image digests and cloud account identifiers, and every one of them is shared by large numbers of unrelated tenants. Penalizing a cloud range for one bad actor sweeps in legitimate agents by the thousand, which makes infrastructure reputation a weak primary control and a defensible secondary one. Reputation for agents has to attach to the agent identity and its principal, accumulated across merchants and carried with a verifiable identifier rather than inferred from where the packets came from. That is a different data model, requiring shared identifiers and a way for merchants to contribute outcomes without exposing their own customers.

Techniques for separating automated traffic from human traffic, spanning header and TLS fingerprinting, challenge pages, mouse movement analysis and honeypot fields. The operating assumption for two decades has been that automation on a consumer surface is unwanted, or at minimum suspicious enough to warrant friction.

That assumption is now wrong on the surfaces that matter most. When a customer deliberately sends an agent to buy something, blocking the automation blocks the customer, and a merchant that cannot separate an authorized agent from a scraper will either lose the sale or admit both. The useful question changes from whether this is a bot to whether this bot acts for someone who authorized it and within what limits. Answering it requires the agent to present verifiable identity and authority rather than to hide, which inverts the incentive that drove a generation of evasion tooling. Expect a long period where both problems coexist, with unauthorized scraping and authorized agent commerce arriving over the same infrastructure and needing opposite treatment.

A challenge designed to be easy for a person and hard for software, placed in front of account creation, login or checkout. Modern implementations lean more on passive risk scoring than on puzzles, but the premise is unchanged. The visitor is asked to prove human presence.

The premise now fails from both directions. Vision-capable models solve image and text challenges well enough to make them a speed bump, and human solver services have priced the remainder low enough that the challenge mostly taxes honest traffic. Meanwhile a legitimate agent sent by a paying customer hits the same wall, so a control built to stop abuse now blocks revenue it was never aimed at. Merchants building for agent traffic need an authorization gate instead of a presence gate, checking who delegated the action and within what scope. Where a human decision genuinely is required, route that decision back to the principal out of band rather than asking the agent to imitate a person at the keyboard.

Risk signals derived from how a person physically interacts with a device, including typing rhythm, touch pressure, swipe curvature, hesitation before entering a value the account holder should know by heart, and the order in which a form is filled. It is among the stronger controls for detecting a coached victim in authorized push payment fraud.

None of it exists when software is the actor. An agent has no motor variability, no hesitation and no muscle memory, so the whole signal class returns nothing rather than a low-confidence answer. That is a real loss, because this was one of the few controls that caught social engineering while it was happening, and the agentic equivalent, catching an agent manipulated by injected content, is unsolved. Behavioral continuity at the task level covers part of the gap. Do not let a null behavioral score resolve to low risk, which is a common misconfiguration when human-channel models are pointed at agent traffic.

Checks that identify whether an app is running inside a simulator, virtual machine or instrumented environment rather than on genuine consumer hardware. In mobile fraud this has been dependable, because ordinary customers do not run banking apps in emulators and fraud farms do.

Applied to agents the signal inverts. Nearly every agent runs inside a container or virtual machine, and that is the correct deployment, so a positive emulator finding carries no adverse information whatsoever. Left in place, the rule produces a uniformly elevated score across all legitimate agent traffic and buries whatever real signal exists underneath it. The question worth asking is not whether the environment is virtualized but whether it is the virtualized environment the principal's agent is supposed to occupy, which calls for attestation rather than detection. Operators migrating an existing ruleset should audit specifically for emulator, rooting and jailbreak checks, because these fire quietly and their contribution to a composite score is easy to miss in aggregate.

Establishing where a session originates, using IP geolocation, GPS where permitted and declared addresses, then testing that location against account history, shipping address and restricted jurisdictions. Distance rules and impossible travel checks are the standard applications.

An agent's location is a datacenter region chosen for latency or cost, and it says nothing about the principal. A customer in one country routinely acts through an agent hosted in another, so mismatch rules written for human sessions fire constantly on good traffic. The compliance consequence is heavier than the false positive rate. Sanctions screening and licensing obligations attach to the principal, so the jurisdiction that matters has to come from the delegation record rather than the network path, and inferring it from egress is simply incorrect. Whether regulators will accept a principal's jurisdiction carried in an agent's credentials in place of observed session location is untested, so firms should document the reasoning behind whatever they adopt instead of assuming the old evidence still discharges the obligation.

Scoring the network path of a request using ASN ownership, proxy and VPN detection, hosting versus residential classification, Tor exit membership and abuse history tied to the address. Hosting ranges have long been treated as elevated risk on consumer surfaces, because real customers rarely shop from them.

Agent traffic originates almost entirely in those same cloud ranges, so a model tuned on human behavior scores the legitimate case as hostile by construction. Inverting the rule is worse, since identical infrastructure carries credential stuffing, scraping and card testing, and a cloud IP therefore discriminates between almost nothing. The residual signals are narrower and still useful, covering residential proxy use by an agent with no reason to hide, sudden egress changes mid-task, and mismatches between network origin and the workload identity the agent presents. Treat network origin as context that adjusts a decision built on identity and authorization evidence, not as an input that can carry a decision on its own.

Falsification of the signals a risk system depends on, including spoofed device attributes, replayed sensor data, forged headers and edited SDK payloads. Any signal collected on a client the attacker controls can be rewritten, which is why mature device stacks pair collection with server-side corroboration.

Agents extend the problem into self-reporting. Most of what a merchant wants to know about an agent, its model, its tool manifest, its mandate and its runtime, is easiest to obtain by asking the agent, and an agent under injection or under an attacker's control answers however it has been told to. Self-declared attributes are claims rather than evidence and should be scored as claims unless they arrive signed by a party with something to lose. The line worth drawing runs between attributes attested by an independent issuer and attributes asserted by the agent in band. Record which side of that line each signal fell on at decision time, because a dispute will turn on whether the merchant relied on evidence or on the counterparty's word.

The record of how an agent has behaved across the counterparties it has already transacted with, rather than at the single merchant making the current decision. It spans completed and reversed payments, dispute outcomes, step-up results and scope violations, keyed to a durable agent identity rather than to a card, cookie or session.

Any one merchant sees a slice, often a handful of transactions in a narrow category, which is too little to separate a well-behaved buying agent from one running the same script against fifty stores. Agents spread thinly and move fast, so the volume that would trip velocity rules at a single seller never accumulates there. A pattern of disputes across unrelated sellers, or of abandonment immediately after authorization, becomes visible only when outcomes are reported back against a shared identifier. Reputation of this kind needs provenance attached, recording who asserted each outcome and when, because unattributed reputation is cheap for a competitor or for the agent's own operator to poison.

A linked structure in which principals, agents, organizations, wallets, runtimes, credentials and counterparties are nodes, and observed relationships between them are edges. Risk propagates along those edges, so confirmed evidence about one node changes the assessment of its neighbors.

Classic fraud graphs link people to devices, cards and addresses. An agentic graph adds layers with no human equivalent, including the runtime an agent executes in, the framework and version behind it, the mandate that authorized it, and the delegation chain running from a principal down through intermediary agents. The practical consequence is that compromise is inherited. A wallet found funding confirmed fraud should depress every agent that has drawn on it, and a runtime hosting a taken-over agent should raise the score of its siblings. Operators have to decide explicitly how far propagation travels and how fast it decays, because an unbounded graph turns one bad actor into a mass false positive event across thousands of legitimate agents that merely share an ordinary cloud host.

A bounded value expressing how confident a relying party can be that an agent is the identity it claims, holds a valid mandate, and is operating inside its granted authority. It compresses evidence from identity, provenance, authorization and reputation into something a decision engine can threshold.

Unlike a consumer risk score, an agent score has to be readable at machine speed and defensible afterward, because the losing side of an agentic dispute will ask what the number was made of. Scores that fuse identity confidence with behavioral risk into a single value are hard to act on, since a verified agent doing something unusual and an unverified agent doing something ordinary call for different responses. Keeping the components separate and mapping them to explicit outcomes such as ALLOW, STEP-UP, REVIEW or BLOCK gives an operator something to tune. Freshness also matters more than in the human case, since a principal can revoke authority in seconds and a score computed an hour ago may describe a credential that no longer holds.

Whether standing earned in one context travels to another, and on what terms the receiving party should accept it. In classic practice this is the difference between a seller rating locked inside one marketplace and a credit file that follows a person between lenders.

For agents the pull toward portability is strong, since an agent that has completed thousands of clean purchases elsewhere is genuinely lower risk, and forcing it to start cold discards the only useful signal available. The hazard is that portable reputation becomes a target. Standing asserted by the agent or its operator, rather than by the counterparties that observed the behavior, can be fabricated outright, and standing bound to a credential that can be sold detaches from the entity that earned it. Workable portability requires reputation bound to a verifiable identity, claims sourced from the party that experienced the outcome, and signatures a receiver can check. Whether regulators will treat portable agent reputation as a regulated data asset is untested.

Past this line, a party's own assertions stop counting as evidence and independent verification is required. Inside the boundary a system can rely on its own logs, sessions and issued credentials, and outside it every claim has to be checked against something the relying party did not produce.

Agentic commerce puts the boundary in an awkward place. The agent arriving at checkout was built, configured and instrumented by someone else, so its claims about who it serves, what it may spend and whether it has been tampered with all originate on the far side of the line. Self-attestation is the default in most current agent protocols, which asks merchants to accept the counterparty's word about the counterparty. The control has to move to artifacts that survive the crossing, meaning signed statements from an issuer the merchant can identify independently, with revocation the merchant can check. Wherever the boundary is crossed without such an artifact is where liability lands when the transaction is disputed.

The exchange in which two parties disclose and verify enough about each other to proceed, before terms or payment enter the conversation. Between businesses it is compressed into onboarding, diligence and contract, and it happens once per relationship.

Between agents it happens per interaction and must complete inside the time budget of a request. Each side needs to establish what the other is, who stands behind it, what authority it holds and what evidence it will accept, and neither side wants to reveal everything up front, so disclosure is staged and each round is conditional on what the other party produced. The failure modes are specific. An agent that over-discloses leaks its principal's identity, mandate limits and wallet details to any counterparty that asks, while one that under-discloses is blocked or pushed to step-up on every attempt. Define minimum viable disclosure per transaction class rather than one blanket policy, and log the negotiation, because the record of what was asked and what was produced is what a dispute turns on.

A new and legitimate participant arrives with no history, and any system that treats absent history as risk penalizes it. Familiar from new-account fraud controls, where genuine first-time customers get the same friction as fabricated ones.

Agent populations make this acute because the population churns constantly. Agents are created, rebuilt, redeployed and rotated far faster than people open accounts, and a version bump can reset whatever behavioral record existed. If no history maps to block, the honest majority carries the cost and the merchant loses volume it should have taken. The way through is to lean on evidence that exists at birth rather than evidence that accrues over time, including who the principal is, which organization issued the agent, whether the wallet has provenance, and whether the authorization scope is signed and narrow. A brand new agent with a verified principal and a tight mandate is a better risk than an aged credential with an unverifiable owner, and a scoring system should be able to express that.

Multiple agents working toward a shared objective while each individual session looks independent and unremarkable. The classic analogue is the bust-out ring, where the pattern lives in the relationships between accounts rather than in any single account's activity.

Agents raise the ceiling on this because coordination is native to how they are built. One operator can run hundreds of instances from a single script, each with its own credential, wallet and runtime, each staying inside per-merchant limits and each leaving a clean record on its own. Detection has to move from per-transaction scoring to structure, looking for common funding sources, template-identical mandates, synchronized timing and repeated tool-call sequences across supposedly unrelated agents. A merchant rarely sees enough to do this alone, since the fleet is spread across many sellers by design. Coordination is not inherently abusive either, because legitimate fleets also share infrastructure, so the discriminator is what the coordinated behavior converges on rather than the fact of coordination.

Fraudsters create agent identities in bulk with no immediate use, holding them in inventory to be aged, sold or activated later. It mirrors account farming, where registrations are stockpiled so a supply of aged, unflagged identities is on hand when an opportunity appears.

Creating an agent is far cheaper than creating a plausible human account. There is no document to forge, no selfie to spoof and no phone number to rent, and in most current frameworks registration is a function call, which collapses the cost side of the economics farming depends on. Any registry that issues agent identifiers without binding them to a verified principal or organization becomes a farm by default. Detection at the point of creation is structural rather than behavioral, keying on registration bursts from one source, shared infrastructure fingerprints, template-identical mandates and clustered identifier issuance. The control that actually bites is making issuance expensive in the only currency that matters, which is an accountable principal attached to every agent.

Deliberately holding an agent credential and letting it accumulate ordinary, low-value activity so its tenure and clean record read as trustworthiness. The same play as aging a mule account or a shopper profile before a bust-out.

Time-based trust is one of the weakest signals to carry into agentic commerce, because an agent can manufacture months of plausible history for the price of API calls. Small purchases, successful deliveries, an absence of disputes and a steady weekly cadence are all cheap to synthesize, and a model that rewards credential age or transaction count without weighing what those transactions were is being farmed deliberately. Look at what the history is made of rather than how long it runs, checking whether transaction values are consistent, whether counterparties are genuine or affiliated with the operator, and whether the mandate quietly widened during the aging period. A shift from small repetitive purchases to a single large novel one is the classic tell, and it is the point where scoring should tighten rather than relax.

An agent provisioned, verified where verification is available, then kept dormant or minimally active until its clean standing is worth spending. Distinct from an agent that happens to be idle, because in this case the dormancy is the strategy.

Reputation systems built for agentic commerce tend to reward exactly what a sleeper produces, which is longevity without incident. Holding cost is close to zero, so an attacker can maintain a large dormant population and wake a subset when a specific opportunity appears, such as a promotion, a new merchant with loose controls or a payout window. Dormancy should therefore be a scored attribute rather than a neutral one, and emergence from it should be treated as a fresh event requiring current authorization evidence instead of historical good standing. Reactivation clusters are the signal to watch, where many long-quiet credentials sharing an origin come alive inside a narrow window. The term also appears in model security for a backdoored model that behaves normally until triggered, and the two senses can coincide.

Selling or transferring an agent identity, passport or verified credential to a party that did not establish it, so the buyer inherits standing it never earned. Directly analogous to the market in aged and verified marketplace accounts.

This breaks reputation at the root, because every score and history attached to that credential describes a different operator. A merchant looking at a well-regarded agent has no way to see that control changed hands last week unless the credential is bound to something that cannot be handed over with it. Binding to a verified principal or organization, and re-verifying that binding rather than trusting the credential alone, is the countermeasure. Signals worth monitoring include an abrupt behavioral break against a long stable history, a change of controlling wallet or runtime with no corresponding change of registered principal, and dormancy followed by activity in an unrelated merchant category. Whether a transferred credential carries the original principal's liability is unresolved, and issuers will have to settle it in the terms they write.

Institutions pool signal so that each member can see behavior that occurred outside its own walls. Long established in card fraud, deposit account and identity consortia, where members contribute confirmed outcomes and query the aggregate.

For agents the case is stronger than for humans, because an agent distributes its activity across counterparties as a matter of design, so the fraction visible to any one member is smaller. It is also harder to build. Members have to agree on an agent identifier stable enough to survive redeployment, on what counts as a reportable outcome, and on how to stop one member's false positive from propagating as consensus. Contribution incentives are the usual sticking point, since everyone would rather query than write, and a pool without contribution decays into stale data. Privacy obligations are unsettled here, because agent behavioral data usually links back to an identifiable principal, which pulls the pool into the same consent and data protection questions that govern consumer consortia.

Investigators surface hidden relationships by finding attributes shared across accounts, such as a device, an address, a payment instrument or a phone number, and treating each shared attribute as an edge. Standard practice in fraud ring work and AML network investigation.

Agent fleets share infrastructure to a degree human populations do not, which makes linking easier and at the same time far more prone to false positives. Hundreds of unrelated legitimate agents can share a cloud region, a model provider, a framework version or a hosted runtime image, so those attributes carry almost no discriminating power alone. The edges that do carry weight are the ones tied to control, including a common funding wallet, a common signing key, a common registered principal and byte-identical mandate documents. Weight edges by how expensive they are for an attacker to vary. Infrastructure an attacker gets for free is a weak edge, and anything that forces them to stand up a new accountable identity is a strong one.

Agentic fraud is fraud in which the agent's identity is valid but its authority is not. It covers loss events where an autonomous software agent takes an action its principal never authorized, while every credential presented in the transaction is genuine. The card is real, the API key was issued correctly, the token is unexpired, and the session shows no sign of hijack that a session-integrity check would recognize. What fails is authority, not authentication.

Because the credential checks pass cleanly, controls built to catch stolen or fabricated credentials never fire, and the first indication of loss is usually a dispute rather than an alert. Detection has to move from asking whether a credential is real to asking whether this agent was permitted to do this, for this principal, at this size, at this merchant, at this moment. Answering that requires evidence the payment message does not carry, including the delegation chain back to a human principal, the scope actually granted, the provenance of the funding instrument, the runtime the agent executed in, and how the agent has behaved at other merchants.

Fraud campaigns planned and executed by AI systems that chain many steps together, from target selection and account creation through control probing, funding and cash-out, with a human involved only at setup and payout. The distinguishing feature is not automation, which fraud has always had, but adaptation mid-sequence without a human rewriting the script.

Velocity rules, pattern rules and bot heuristics all assume repetition, and repetition is exactly what an adaptive attacker stops producing. Each run varies wording, pacing, device, funding route and merchant order, so attempts fall below per-entity thresholds while the campaign as a whole succeeds. Operators should expect reconnaissance to look like ordinary low-volume failure spread across many identities, and should expect the attacker to learn the decline taxonomy faster than the risk team can rotate it. The practical counter is to score the actor rather than the attempt, which requires a durable identity for the software doing the acting and reputation signal that travels across merchants instead of resetting at each one.

An attack agent that selects its own next move inside a fraud sequence rather than following a fixed playbook. Given an objective such as monetizing a batch of stolen card data, it decides which merchant to try, how to answer a step-up challenge, when to abandon an identity, when to change funding rails and when to retry.

The consequence for defenders is that the attack now has a feedback loop attached to it. Every decline, challenge and silent failure is training signal, so any control that leaks its logic through differential response behavior gets mapped within hours of contact. Watch for adaptive retry, where basket composition, amount, timing or shipping detail shifts slightly after each rejection instead of repeating identically, since that shape defeats fingerprint-and-block responses tuned to duplicates. Static thresholds are the weakest possible defense here. Controls that hold up are the ones an attacker cannot probe cheaply, such as requiring verifiable authority from an issuer the attacker does not control.

A narrower construct than a fully autonomous fraud agent. An AI system pointed at one task inside a fraud pipeline, such as filling stolen identity data into onboarding forms, generating plausible answers to knowledge-based questions, drafting victim correspondence, or probing a checkout to learn which controls fire at which amounts.

What this changes is the cost of the labor-intensive steps, which is where a great deal of fraud friction has always lived. Manual form-filling, call handling and per-victim tailoring were natural rate limiters, and defenses were quietly priced against them. Once those steps cost close to nothing, friction stops being a deterrent and becomes only a nuisance for legitimate users. Operators should re-examine any control whose value came from being tedious rather than from being hard to satisfy, and should shift the burden toward evidence an attacker cannot manufacture, such as an issued agent credential bound to a verified principal.

Mass automated attempts against a target, including credential stuffing, card testing, account creation, promotion abuse and inventory scalping, run through rented residential proxy pools, headless browser farms and off-the-shelf toolkits. Cost per attempt is low enough that success rates in fractions of a percent remain profitable.

Agentic commerce breaks the assumption underneath most bot defense, which is that automated traffic is unwanted traffic. A shopping agent acting for a real customer is automation by every technical signal, so blanket blocking of non-human traffic now blocks revenue, and permissive treatment of declared agents invites impersonation. The distinction cannot be made from headless-browser detection or user-agent inspection, both of which are attacker-controlled. It has to come from an agent presenting a verifiable identity tied to a principal and a scope, with unverified automation treated as the higher-risk class rather than as a category to block outright.

Criminal capability packaged and sold as a product, so that operating an attack requires no ability to build one. Vendors supply infrastructure, tooling, stolen data, laundering routes and support, and buyers supply only intent and payment.

The packaging model is what makes new attack techniques spread quickly, and agent-era techniques will be commoditized on the same timeline as everything else. Two effects matter for operators. First, rented infrastructure is shared across many unrelated buyers, so IP, device and hosting reputation carry less discriminating power every year. Second, the same agent frameworks and browser-automation tooling that legitimate commerce agents use are available to buyers with no technical skill, which means capability alone tells you nothing about intent. Underwriting has to attach to the identity and authority of the acting party rather than to the sophistication of the traffic, since sophistication is now rentable by the hour.

A subscription or per-use bundle covering the full fraud lifecycle, typically combining stolen credentials, synthetic identity kits, bot and automation tooling, mule or drop account access, and cash-out channels. The buyer gets a working pipeline rather than components to assemble.

As commerce moves to agents, expect the bundle to acquire agent-shaped inventory, including hijack-ready tool endpoints, injection payload libraries tuned to popular agent frameworks, and rented agent identities with some transaction history behind them. That last item deserves attention from anyone building reputation systems, because a reputation that can be aged cheaply and then sold is an asset class for the fraud economy rather than a control. Reputation designs should therefore bind history to an issued, revocable identity with a traceable principal behind it, and should treat sudden behavioral discontinuity in an established agent as a takeover signal rather than as growth.

Rented phishing infrastructure sold as a managed product, including hosted lookalike pages, template libraries, delivery, evasion of security crawlers, and increasingly a real-time reverse proxy that relays the victim's login to the genuine site and captures the resulting session.

Session capture is the part that matters most in agent environments. Agent credentials tend to be long-lived, broadly scoped API keys or OAuth grants rather than passwords behind an interactive login, and they are held by software that has no way to notice that a page looked wrong. A captured agent session is not just account access, it is spending authority that can be exercised immediately and continuously. Operators should assume the second factor will be relayed, and should constrain the damage instead, by scoping agent credentials narrowly, binding them to an environment, and requiring that a payment be checked against a mandate at execution time rather than trusting the session that carried it.

Face swap, face reenactment and voice cloning sold per job or per minute, with no technical skill required from the buyer. Pricing is low enough that synthetic media is now viable against individual mid-value targets, not just against large ones.

The pressure lands on any control whose evidence is perceptual. Onboarding checks that rely on a selfie or a video liveness pass, and approval steps that rely on a human recognizing a colleague on a call, both assume that producing a convincing likeness costs more than the fraud returns. That assumption no longer holds at ordinary transaction sizes. Where an agent workflow includes a human approval gate, that gate needs to produce something verifiable rather than something merely convincing, which in practice means a signed confirmation from a known device or credential rather than a face and a voice on a call.

Synthetic audio, image or video that impersonates a specific real person, produced by generative models from reference material that is usually public. Quality now clears the bar for real-time use in most consumer-grade channels, and cost per artifact is small enough for routine use against ordinary targets.

The relevant shift for agentic commerce is that the human who might have noticed something is off is often no longer in the loop. When an agent processes a voicemail, a video attachment or a screenshot as input to a decision, it has no perceptual suspicion to draw on and no relationship context that would flag a mismatch in manner. Detection models help but degrade quickly against new generators, and a merchant cannot rely on the counterparty having run one. The durable control is to refuse to treat media as authorization at all, and to require that any instruction with financial effect trace back to a signed mandate.

Real-time replacement or reenactment of a face during a video call, driven by a live operator and rendered with low enough latency to survive conversation. Injection into the call is often done through a virtual camera, which means the stream reaching the far end never passes through the physical capture path a liveness check assumes.

Two controls take direct damage. Video KYC, used to verify the human principal standing behind an agent, can be satisfied by an operator who has never seen the identity being claimed. And live approval calls, still the standard escalation when a payment instruction looks unusual, become a channel the attacker prefers rather than avoids. Operators should stop treating a video call as a step-up factor and treat it as an unauthenticated channel, moving verification to device and environment signals, issuer-verified identity data, and out-of-band confirmation that produces a record.

Identity and supporting documents that are generated or altered by AI, including passports, driving licenses, utility bills, bank statements and business registrations, produced to survive automated capture, template matching and basic image forensics. Because each artifact is generated fresh, reuse-based detection catches little.

In an agent context the damage compounds down the delegation chain. Every claim an agent makes about its authority resolves eventually to a human or a legal entity that was onboarded somewhere, and if that root was established with fabricated documents then all downstream evidence is internally consistent and entirely false. Agent identity is only as trustworthy as principal identity, and the two verifications cannot be treated as separate problems. The practical response is to weight issuer-verified and bank-verified data over document images wherever it is available, and to re-verify the principal when an agent's behavior or scope changes materially rather than only at onboarding.

Reproduction of a specific person's voice from a short sample, close enough to pass recognition by a colleague, a family member or a call center agent. Seconds of public audio are typically sufficient, and real-time synthesis allows interactive conversation rather than playback of prepared phrases.

Voice was load-bearing in payments precisely because it was cheap to check and hard to fake, which is why callback verification became standard practice for high-value transfers and account changes. That property has inverted. Operators should also account for the mirror-image problem, where the legitimate side of the call is an AI voice agent handling service requests, so neither party to a phone interaction can safely assume the other is human. Voice biometrics deployed as a primary factor should be reassessed and demoted to a supporting signal, with authorization tied to a credential or signed instruction that a caller cannot produce by sounding right.

Generated or manipulated content of any modality created with intent to deceive, spanning fabricated documents, images, audio, video, reviews, screenshots and correspondence. The category matters less for any single artifact than for what it does to a general assumption, which is that recorded media is evidence of an event.

Fraud and AML workflows lean on that assumption in more places than teams usually realize, including proof of address, proof of delivery, source of funds documentation, dispute evidence and merchant review corpora. Once artifacts are free to produce, the burden shifts from spotting fakes to demanding provenance, and provenance for media is not solved. Content credential standards exist but coverage across capture devices and platforms is partial, and no merchant can currently require them. Until that gap closes, which is a matter for device makers, platforms and standards bodies rather than for individual risk teams, controls should rely on data verified at its source instead of on artifacts submitted by the party being assessed.

Fraud whose economics depend on generative models producing volume, including fabricated identities and backstories, application narratives, supporting documents, complaint and chargeback letters, fake merchant listings and review inventory. The marginal cost of the hundredth artifact is effectively the same as the first.

Detection heuristics built on human production limits are the first to fail. Attackers previously reused text, reused images and reused personas because creating new ones took effort, and a great deal of link analysis quietly depends on that reuse. When every application carries unique wording, a unique face and an internally consistent history, clustering by artifact similarity finds nothing. Signals that survive are the ones an attacker cannot generate, including bank-verified account ownership, funding instrument provenance, device and environment continuity, and confirmed relationships to real counterparties. Operators should audit which of their detection rules depend on repetition and assume those rules are already weaker than their historical performance suggests.

A payment fraud in which a synthetic executive, and sometimes several synthetic participants, appears on a live video call to instruct staff to release funds, change banking details or approve an exception. The call typically follows a preparatory message that establishes urgency and confidentiality, so the video functions as the confirmation step the victim's own procedure demanded.

The pattern transfers directly to agent-operated finance functions, where the instruction may arrive as a meeting transcript, a recorded approval or a summarized decision passed into an agent's context. An agent has no basis for doubting that a recorded approval is genuine, and it will execute more quickly and with less hesitation than the employee it replaced. Payment authority therefore has to derive from a signed mandate held outside the instruction channel, checked at execution against amount, counterparty and scope, so that a persuasive instruction in any channel cannot by itself move money.

Manipulation of the person who holds authority, rather than defeat of the system that enforces it. The attacker supplies context, urgency and permission so that the target chooses to do the thing, which means no control is technically bypassed and the resulting transaction is fully authorized on its face.

The decision-maker is increasingly software, and prompt injection is the same discipline applied to a model. Instructions hidden in a product page, a review, an email body, a PDF or a tool response exploit the fact that an agent cannot reliably separate content it was asked to process from instructions it was meant to follow. Human defenses that partly worked, including suspicion, reluctance and the instinct that a request feels wrong, have no equivalent in an agent. Since persuasion cannot be prevented, the control has to constrain consequence, holding the agent to a scope it cannot renegotiate at runtime no matter what it has been convinced of.

Deceptive messages that harvest credentials or induce action by imitating a trusted sender, delivered by email, SMS, messaging apps or search advertising. Defense has historically combined technical filtering with user education aimed at producing hesitation before the click.

Education has no analogue for an agent. An agent that triages a mailbox, follows links, retrieves referenced documents and acts on their contents will process a phishing message at the same speed and with the same disposition as a legitimate one, and it does so continuously rather than in the moments of human attention an attacker previously had to win. Agents also hold richer material than a person does, including API keys, session tokens and stored payment context, so a single successful capture yields spending authority instead of one account. Operators should assume agent-facing phishing succeeds sometimes, and should reduce what a compromised agent can do by scoping credentials tightly and verifying authority at the point of payment.

Targeted phishing built on research into a specific individual, their role, their counterparties and a current piece of context such as a live deal, an invoice cycle or a period of absence. Higher success rates came at the cost of manual reconnaissance, which limited the technique to targets worth the effort.

That cost has collapsed, and per-target research is now economic against ordinary staff and ordinary vendors. The second change is that agents themselves are researchable targets. Published tool manifests, connector listings, agent descriptions and public integration documentation reveal what an agent can do and what phrasing it will accept, which is reconnaissance material of exactly the kind spear phishing runs on. Teams deploying agents should treat capability documentation as attack surface, limit what an agent advertises about its own permissions, and assume that anything discoverable about its interface will be used to construct instructions it will accept.

Construction of a false but plausible scenario that makes the requested action seem routine, such as an audit, a systems migration, a compliance review or an urgent request from a senior colleague. The pretext works by supplying a reason, which converts an odd request into an explicable one.

Agents are unusually susceptible because plausibility is all they have. An agent has no accumulated sense of how the organization actually behaves, no memory of the last three times a similar request turned out to be nothing, and no discomfort to override. Worse, the pretext need not arrive through a channel anyone is monitoring, since it can be embedded in a web page, a document or an API response that the agent retrieves in the course of legitimate work. Operators should assume the agent will accept the story and should place the check somewhere the story cannot reach, at the boundary where the action is authorized rather than where it is described.

Falsification of identifying data so that a message, call or request appears to come from a trusted source. Display names, sender addresses, caller ID, domains and device attributes are all routinely forged, and most of them were never designed to resist forgery in the first place.

Agent identity is currently in the same weak position, and often weaker. Agents commonly announce themselves through user-agent strings, custom headers or self-declared names in an API call, all of which are attacker-controlled text that any client can send. A declared agent name carries no more assurance than a display name in an email header, so building allow lists, fee treatment or trust tiers on top of declared agent identity creates a target rather than a control. Identity only becomes usable when it is cryptographically bound to an issuer and a principal, verifiable by the receiving party without trusting the sender's own claim.

Impersonation of an executive, employee or supplier, either from a compromised mailbox or a lookalike domain, in order to redirect a legitimate payment or extract sensitive data. Losses are typically large per incident because the payment is real, expected and properly authorized inside the victim organization.

Finance agents are the natural next target, since they hold the instruction channel and the payment capability in the same place. An agent reading a supplier mailbox and executing payment runs removes the accidental controls that sometimes caught BEC, including a person noticing that a supplier's tone changed or that a request arrived at an odd hour. It also removes the pause. Controls that depend on human recognition need replacing with checks the agent must satisfy mechanically, including counterparty and beneficiary verification against a record the mailbox cannot alter, and an authorization scope that excludes new beneficiaries without a separately signed approval.

Alteration of the payment details on an otherwise legitimate invoice, or a bank-detail change request sent from a real or convincingly imitated supplier. Everything else about the transaction is correct, including the amount, the purchase order, the goods and the commercial relationship, which is what makes the fraud hard to see.

An agent performing accounts payable will validate the parts of the invoice that are checkable and will not question the part that carries the loss. Matching to a purchase order, confirming delivery and reconciling the amount all pass, because the payload is a changed account number, and an account number has no internal consistency to test. The control has to sit on the beneficiary rather than the document, combining verification of account ownership against the supplier of record, provenance checks on the destination account or wallet, and treatment of any change of banking details as an event requiring out-of-band confirmation rather than as a data update.

Relay of a victim's authentication through a reverse proxy that sits between them and the genuine service, forwarding every step in real time and capturing the resulting session cookie or token. Because the second factor is relayed rather than bypassed, most multifactor deployments provide no protection.

Agent sessions raise the value of what gets stolen. Machine credentials are typically long-lived, broadly scoped and refreshed automatically, and there is no user present to notice an unfamiliar prompt, an odd domain or a session that has been active longer than it should be. A relayed agent session can be exercised at merchants the principal never visited, at times the principal is not working, with no signal that would distinguish it from ordinary agent behavior. Defenses that hold up bind the token to a device or environment, keep scope narrow, and check authority against a mandate at execution, so that possession of a session is not the same as possession of spending power.

Malware resident in the browser that alters what the user sees and what the client actually sends, so a payment displayed as one amount and beneficiary is transmitted as another. Because the manipulation happens inside an authenticated session on a legitimate device, server-side checks see a valid, correctly signed request.

The agent analogue sits between the model's decision and the tool call that carries it out, in a compromised connector, a proxied API, a tampered tool definition or a malicious server in the agent's toolchain. The agent's reasoning trace and its own logs record the intended action, while the parameters that reached the network say something else, and reconciling the two after the fact is close to impossible without independent evidence. Operators should treat the agent's self-report as an unverified claim, capture what was actually submitted in a signed record produced outside the agent's own process, and attest the environment the agent runs in as part of the transaction evidence.

Automated purchasing software that acquires scarce inventory at release, sneakers, concert tickets, graphics cards, faster than a human can complete checkout, usually for resale at a markup. Merchants treat scalping as abuse because it distorts allocation and pushes real demand into the secondary market.

Every technical signal used to catch scalpers, headless execution, millisecond form fill, checkout timed to the drop, is now the ordinary behavior of a consumer shopping agent acting for a real buyer. Behavioral detection cannot separate the two, because the mechanics are identical. What separates them is whether a principal actually delegated this purchase, at this price ceiling, for this quantity, and whether the agent's authorization scope says so. Operators should move the decision from speed heuristics to authorization evidence, checking principal identity, agent identity and a mandate that binds quantity and price. An agent with no verifiable principal buying forty units of a limited release is a scalper regardless of how human its timing looks, while an authorized agent buying one is a customer.

Extraction of promotional value beyond what an offer intended, typically by opening many accounts to claim a signup bonus repeatedly, or by structuring spend or play so the bonus converts to withdrawable value without the risk the promotion assumed. Gambling, fintech and marketplace operators price promotions against an expected rate of this leakage.

The economics change because agents make account creation nearly free. Email, phone, device fingerprints and funding can all be assembled and rotated by software, so the cost that once capped an abuser at a few dozen accounts falls toward the cost of an API call. Volume then arrives faster than a promotions team can measure it, and the offer is drained before the first weekly report. Detection built on per-account behavior misses this, because each account behaves reasonably, and the signal lives above the account, in shared agent identity, wallet provenance and funding reuse across accounts that otherwise look unrelated. Operators should instrument promotions for cluster-level exposure before launch and set a kill threshold in advance.

Systematic exploitation of discounts, credits, free trials, cashback and loyalty mechanics by parties with no genuine customer relationship behind the claim. It differs from ordinary price sensitivity in that the margin the offer was meant to spend on growth is captured industrially, by actors who never become customers.

Agentic commerce makes offer discovery mechanical. An agent can read terms, test stacking combinations, find the coupon scoped to one segment and apply it broadly, then repeat the routine across merchants without fatigue. Weak promotion logic that survived because nobody probed it now gets probed within hours of publication. Operators should assume terms are machine-read and adversarially tested, write enforcement into the redemption path rather than the terms page, and treat repeated near-miss redemptions as reconnaissance rather than user error. The harder question is which agent traffic is welcome, since an agent finding a legitimate discount for its principal is the intended use of a public offer, so the control has to key on authorization and identity rather than on whether the redeemer was software.

Harvesting referral rewards without producing a real referred customer, either by referring accounts the fraudster controls, by fabricating the referred party, or by inserting a referral link into a conversion that would have happened anyway. Programs are structurally exposed because the reward pays out on an event the referrer can manufacture.

A fleet of agents can build a referral graph that looks organic. Each referred account can be given a plausible history, distinct funding, its own device story, low-volume genuine activity, and a fan-out pattern spaced at human intervals rather than arriving in a burst. Graph analysis that hunts for tight self-referring loops will not fire on a structure designed by something that has read the same graph literature. Recovering the reward is harder too, since payouts increasingly settle to wallets rather than to a card that can be reversed. Operators should vest rewards against downstream behavior of the referred account instead of paying on signup, and should treat shared wallet provenance or shared agent identity across referrer and referee as disqualifying.

Abuse of a merchant's return policy for value, including wardrobing, returning a substituted or damaged item, returning goods bought with stolen instruments, and serial returning that turns a generous policy into a subsidy. Merchants tolerate a baseline rate because friction on returns suppresses genuine sales.

Return policy is a set of rules, and rules are exactly what an agent optimizes against. An agent can hold an item until the last allowed day, keep each account just below the return rate that triggers manual review, split purchases across merchants to stay under per-merchant limits, and re-tune the moment the published policy changes. Because it runs continuously, the drift from acceptable to abusive happens without any person deciding to cross a line. Operators should expect published limits to be treated as targets and should stop exposing exact thresholds in customer-facing text. The durable control is reputation that follows the agent across merchants, since a returner tuned against one retailer's policy is usually running the same routine at several.

Obtaining a refund for value that was never lost, through false damage or non-delivery claims, box stuffing, partial-return manipulation, or social engineering of support staff. Organized refunding operations sell this as a service, taking a percentage of the order value from a customer who keeps the goods.

Support channels are the soft point, and they are now the surface most exposed to agents. An agent can open a claim with a coherent narrative, correct order details, matching timestamps and a tone calibrated to the published policy, then escalate patiently across shifts without getting frustrated. Claim volume arrives faster than a support queue can adjudicate, which pushes teams toward auto-approval thresholds, which is precisely what the operation is measuring. Refunding as a service scales differently now, because the human labor that limited it has been replaced by inference. Operators should authenticate the agent making the claim rather than only the account it claims for, and require that a claim carry the same agent identity and authorization evidence as the purchase it disputes.

A claim that ordered goods never arrived, filed in order to keep both the item and the money. It sits awkwardly between service failure and fraud, because genuine non-delivery is common enough that merchants cannot refuse the claim class outright, and carrier evidence is frequently ambiguous.

Adjudication is a capacity problem, and agent-filed claims arrive faster than review capacity absorbs them. A claim built with the order number, the delivery window, correct carrier language and a consistent account of the doorstep will clear triage rules written to catch sloppy human claims. When agents also placed the orders, the merchant loses the human-side signals it leaned on, such as address familiarity and the hesitation of a caller inventing a story. Automatic approval below a dollar threshold becomes the exploited surface, because an agent can size every claim just underneath it. Operators need per-principal and per-agent claim rates rather than per-order decisions, and should treat a cluster of sub-threshold claims tied to one agent identity as a single event rather than many small ones.

A three-party scheme in which a fraudster runs a storefront or marketplace listing selling real goods at attractive prices, collects genuine card data from real buyers, and fulfills those orders by purchasing from a legitimate retailer using a separate set of stolen cards. The buyer receives the item and never complains, so discovery is delayed until the cards used on the fulfillment leg are disputed.

Agentic commerce widens the front door. A shopping agent selecting on price and availability will route its principal to the cheapest compliant listing, and a triangulation storefront is engineered to be exactly that. Agents also make the fulfillment leg cheaper to run, since placing and tracking thousands of retailer orders no longer requires staff. Retailers on the fulfillment side should watch for a rising share of orders where billing and shipping identity diverge and the ordering agent has no cross-merchant history. On the buyer side the control sits in the agent's counterparty checks before payment, because the principal cannot detect the scheme from the transaction alone.

A dispute filed against a purchase the cardholder actually made and received, framed as unauthorized or undelivered so the issuer reverses the payment. The merchant carries the loss and the fee, and the evidence it can supply, delivery confirmation, IP address, device history, is usually weaker than the cardholder's assertion.

Agent-initiated purchases hand the disputing cardholder a better story. Saying that an agent bought something the cardholder never authorized is plausible, hard to disprove, and lands in a dispute process with no field for agent authorization. Issuers today have no standard way to see whether a mandate existed, what scope it granted, or whether the agent stayed inside it, so the default resolution favors the cardholder. The remedy is evidentiary, and a merchant able to produce a signed verification record showing which agent transacted, under which principal, within which authorization scope, at least has something to file. Whether the card networks will accept that evidence and shift liability accordingly is unresolved, and the networks, not individual merchants, have to resolve it.

Fraud in which the account holder is the perpetrator rather than the victim, covering disputed-but-genuine purchases, deposit and credit abuse, bust-out on a credit line, and false claims of unauthorized activity. It defeats identity controls because the identity is real and the credential genuinely belongs to the customer.

This is the closest classic analogue to agentic fraud, and agents make it easier to sustain. The credential is valid, the device is the customer's own, the spending fits the customer's history, and now there is a second actor available to blame. A principal who instructed an agent to spend can later disown the instruction, and unless that instruction was captured as evidence at the time, nothing contradicts them. Operators should capture the mandate at authorization rather than reconstructing intent after a complaint, recording the grant, the scope, the limits and the agent it was granted to in a form the principal cannot repudiate. Without that record, delegation to an agent becomes a general-purpose denial available to anyone who wants one.

Fraud presented with a complete, internally consistent profile built to satisfy risk checks, a real-looking name, an address matching the BIN geography, a device with plausible history, an unremarkable order value and no velocity anomalies. It passes because every individual field is defensible and no rule has anything to fire on.

Assembling that consistency used to be manual work, and was therefore rate limited. Agents assemble it perfectly and repeatedly, testing a profile against a merchant's rules, reading the decline reason and correcting on the next attempt. Static rules and score thresholds degrade quickly against an adversary that can probe them, because the decision boundary becomes discoverable. The counter is not better profile scoring, since the profile is the thing being optimized, but evidence the fraudster does not control, such as who the agent is, who authorized it, where its funding came from and how it behaved at other merchants. A flawless profile with no verifiable principal behind it should read as a stronger warning than a messy profile with one.

Submission of false or manipulated information on an application for credit, an account, insurance or a service, ranging from inflated income through to a fully synthetic applicant. Institutions control it with document checks, bureau data, internal consistency rules and device intelligence.

Throughput is the change, because an agent can generate thousands of applications that are each internally consistent, with income, employer, address history and stated purpose that agree with one another and with public records. It can also read the decline and adjust, converting an application funnel into a feedback loop for the attacker. Institutions that rate-limit by IP or device will find both rotated cheaply. The useful controls move to evidence outside the application, verified principal identity, environment identity for the runtime that submitted it, funding provenance, and a requirement that an agent applying on someone's behalf carry a mandate naming that person. Applications with no identifiable submitting agent and no principal grant should be queued rather than scored, because the score itself is being gamed.

Fraud committed in the first days or weeks after account opening, before behavioral history exists to contradict it. Familiar patterns include an immediate high-value purchase, a deposit followed straight away by a withdrawal, and full drawdown of a newly granted credit line.

Agent-opened accounts arrive with no history by construction, and the first action is often the only action. The cold-start window that fraud teams manage with velocity limits and manual review now covers a much larger share of traffic, because legitimate agents also appear as brand new actors with no track record. Treating every new agent as high risk blocks real commerce, and treating them as low risk invites the classic attack. The way out is portable history, an agent identity that carries reputation across merchants together with a principal identity verified independently of the account, which gives a new account something to be scored on. Operators should decide in advance what evidence lets a first-transaction agent through and route everything else to step-up rather than deciding case by case.

Abuse of legitimate access by someone inside the organization, including payment redirection, data theft, unauthorized limit changes and collusion with external actors. Controls rest on least privilege, segregation of duties, approval thresholds and the deterrent effect of employment consequences.

An over-scoped agent is functionally an insider with none of those restraints. It holds credentials it is supposed to hold, acts inside the systems it was given, and cannot be deterred by a background check or a disciplinary process. Compromise of that agent, through prompt injection, a poisoned tool response or takeover of its control plane, converts sanctioned access into an attack with no perimeter crossing for anyone to detect. Segregation of duties has to be re-expressed as authorization scope, with hard limits on amount, counterparty and action type, and a separate approval path for anything outside them. Operators should also monitor for scope drift, since the practical failure is rarely a dramatic breach and is usually an agent quietly doing slightly more each week than anyone approved.

Theft routed through the supplier payment channel, including fictitious vendors, duplicate invoices, inflated invoices from a genuine supplier, and business email compromise that changes remittance details on an otherwise valid payable. It works because the payment looks like ordinary business activity all the way through approval.

Accounts payable is now being automated by agents that read invoices, match them to purchase orders and release payment. That removes the incidental control of a person occasionally noticing something odd about a bank detail change. It also opens a new injection path, because the invoice is untrusted input and the agent takes instruction from its contents, so a well-crafted document can carry directives the agent follows as though they came from the principal. Controls have to sit outside the document, which means bank detail changes verified through a channel the invoice cannot influence, step-up on payments to first-time counterparties regardless of amount, and an authorization scope that enumerates approved payees rather than approved limits alone.

Manipulation of buying decisions for improper benefit, covering bid rigging, kickbacks for steering awards, split purchases that stay under approval thresholds, and specifications written so only one supplier qualifies. Detection relies on price benchmarking, competitive bid records and separation between requester and approver.

Purchasing agents decide on criteria, and criteria can be poisoned, so where an agent selects on price, availability and vendor ratings drawn from sources an attacker can influence, seeding those sources costs less than bribing a buyer. Fabricated reviews, manipulated comparison pages and content written specifically for machine readers all become procurement attacks. The agent then behaves correctly against corrupted inputs, so nothing in its logs looks wrong. Operators should treat the agent's evidence sources as part of the control surface, pin approved supplier lists rather than letting the agent discover suppliers, and require human approval whenever the chosen counterparty is new. Split-purchase detection needs rewriting as well, since an agent will keep every order under an approval threshold without ever being told to.

Abuse of recurring billing, most often free-trial cycling across many accounts, continued use of a paid service backed by chargebacks, or signing up with stolen instruments and consuming the service before the dispute lands. Telecom and software businesses carry it as a cost of low-friction acquisition.

Trial cycling is a scripted task, and agents run it across clustered accounts without the per-account cost that once made it marginal. Where the service is metered compute or API access, the damage is worse, because the value extracted inside a trial can exceed the value of a paid month. Card-based deduplication also fails when funding rotates through virtual cards or stablecoin rails, which is normal in agent wallets. Operators should tie trial eligibility to something more durable than card and email, such as a verified principal identity or an agent identity with history, and should meter early consumption instead of assuming a trial has a fixed cost. Clustering on wallet provenance across accounts usually exposes the operation before the billing data does.

Data corrupted or deliberately planted so a system ingesting it treats false information as verified fact. Stolen PII is real data in the wrong hands, whereas poisoned PII is wrong data placed where a trusted process will pick it up, in a broker file, a public record, an enrichment API or an onboarding document.

Agents make this more dangerous because they read more sources and question fewer of them. An agent gathering context before a purchase or a payment pulls from whatever it can reach, with no instinct that a conveniently confirming result deserves suspicion. Planted data then propagates, since one agent's output becomes another system's input. The resulting failure looks like a correctly executed action built on a false premise, which is invisible to controls that only check whether the actor was authorized. Operators should record which sources an agent relied on, prefer signed or first-party attestations over open enrichment, and treat an unexplained change in a counterparty's reference data as a trigger for step-up rather than an update to apply.

Industrial fraud facilities, concentrated in parts of Southeast Asia, where trafficked or coerced workers run romance, investment and task scams at volume against managed quotas. They exist because these schemes need sustained human conversation, and that conversation was labor which had to be recruited, housed and controlled.

Language models remove the constraint the compound was built to solve. Conversation at scale no longer requires a room full of people, so the operating model shifts from headcount to inference cost, and the physical chokepoint that gave law enforcement something to raid weakens. For institutions the visible change is on the receiving side, where victim contact becomes more fluent, better localized and available at any hour, and pacing is tuned per victim rather than run from a shared script. Detection that leaned on stilted language, time-zone mismatches or template reuse loses most of its power. The durable signals stay on the money, in wallet provenance, mule account structure and the shape of outbound payments from a customer who never behaved that way before.

Recruitment into small paid online tasks, rating products, liking videos, completing app actions, with real early payouts that establish trust. The scheme turns when the victim is asked to deposit funds to unlock higher-paying task tiers, after which deposits are lost and further deposits are demanded to release a fabricated balance.

Both sides of this can now be automated, with the recruiter, the support handler and the fake platform's chat all agent driven, which removes the cost that limited how many victims one operation could hold. On the victim side, some targets are themselves running agents that will complete the tasks and, if loosely scoped, make the deposit. An agent holding a payment mandate and no counterparty check will fund a scam platform as readily as a real merchant. The control has to run before the payment, verifying who the counterparty is and whether this payee falls inside what the principal authorized. Operators should watch for first-time payees receiving escalating deposits from an account with no prior outbound pattern.

A fabricated job offer used either to extract money from the applicant, through equipment fees, training costs or overpayment check schemes, or to recruit them as a money mule under cover of a payment-processing role. Applicants hand over full identity documents willingly, so the scheme also produces high-quality PII as a byproduct.

The pitch is now generated, personalized and delivered at volume. Postings, recruiter outreach, interview conversation and onboarding paperwork can all be produced by an agent that mirrors the target's resume and industry vocabulary, which defeats the crude tells applicants were taught to look for. Mule recruitment scales accordingly, and the recruited accounts reach banks looking like ordinary new customers with plausible employment behind them. Institutions should read unexplained inbound-then-outbound patterns in newly employed young accounts as a mule signal rather than a victim signal, and should assume the employment story will check out on paper, because the paper was generated to check out.

Long-cycle investment fraud in which the target is cultivated over weeks or months through an apparently personal relationship, then guided onto a fake trading or crypto platform that displays fabricated gains. Small early withdrawals are honored, which converts skepticism into confidence before the large deposits are taken.

The expensive part was always the relationship, and that cost has collapsed. An agent can sustain hundreds of conversations at once, hold consistent detail across months, adjust pacing to each target's responsiveness and never break character, so volume no longer trades against quality the way a human operator's caseload did. Banks still see the same downstream shape, a customer moving increasing amounts to a crypto exchange or straight to a wallet, dismissing intervention, sometimes borrowing to continue. Warnings work less well when the counterparty can answer every objection the bank taught the customer to raise. Intervention therefore has to attach to the payment pattern and the destination wallet's provenance rather than to whether the customer can be talked out of it.

Transfer of a victim's mobile number onto an attacker-controlled SIM, achieved through carrier social engineering, insider assistance or a fraudulent port request. Once the number moves, SMS one-time codes and voice-based recovery flows deliver to the attacker, which unwinds most account recovery controls behind them.

Agent deployments have not removed this dependency, they have concentrated it. The console where an agent's mandates, spending limits, wallet keys and API credentials are managed usually sits behind the same phone-based recovery as any consumer account, which makes a phone number the cheapest route into an agent's control plane. Taking that over is worth more than taking over a single bank login, because the attacker inherits standing authority to spend rather than a one-time opportunity. Operators should require phishing-resistant authentication on any surface that can issue or amend an agent's authority, and should treat a recent SIM change on the principal's number as grounds to suspend the agent's scope until re-verified, not merely as a reason to step up the next login.

Automated systems that call or message a victim while the attacker triggers a login, impersonate the institution's fraud line, and collect the one-time code the victim has just received. Sold as a service with per-institution scripts and prerecorded prompts, they industrialize the final step of an account takeover.

Two things change. The scripts become conversational rather than prerecorded, so a victim who departs from the expected answer still gets a competent reply, and voice cloning makes callback verification less reliable than it was. The second shift is that one-time codes are increasingly a control on agent authority as well as on human logins, which means the same technique can approve an agent's step-up or raise a spending limit. Any design treating an SMS code as sufficient proof of a principal's intent inherits this weakness directly. Operators should bind high-value agent authorizations to a signed grant from a device-bound credential rather than a code the principal can be induced to read aloud, and should log which channel approved each scope change.

Control of a legitimate, already authorized agent passes to an attacker, who then inherits every permission that agent was issued. The identity resolves, the credential validates and the delegation chain still points at a real principal, so the activity looks authorized to any control that only asks whether authorization exists.

What makes this worse than a stolen human login is that the captured credential was purpose-built to act without asking a human first. An agent usually holds spend authority, a payment instrument, live merchant sessions and a mandate saying it may transact unattended, so a compromised agent can run at machine speed across many counterparties before a person notices. Detection has to move off credential validity and onto behavior, watching for permission-set expansion, new merchant categories, changed destination wallets, tempo shifts and instruction sources that do not match the principal's history. The useful response is a reversible freeze rather than revocation, because revocation is destructive and reissuance is slow.

An attacker obtains control of a genuine customer's account through stolen credentials, phishing, SIM swap, malware or social engineering, then transacts as the customer. Fraud teams treat it as an authenticated-session problem rather than an identity problem, because the login itself is technically correct and the account history is real.

Most of the ATO playbook survives into agentic commerce, but its best signals do not. Device fingerprinting, keystroke and mouse behavioral biometrics and typing cadence all assume a human at a browser, and none of them exist when the account holder is a headless process in a container. Step-up authentication assumes someone is present to answer, which is precisely what an unattended agent is designed to avoid. Victim-side detection also degrades, since a person notices an unfamiliar confirmation email while an agent notices nothing and keeps working. Operators should expect ATO controls to be rebuilt around identity attestation, mandate conformance and out-of-band notification to the principal rather than around the endpoint.

An attacker redirects an agent's objective in the middle of a task while its identity, credentials and permissions stay valid and unchanged. It is usually achieved through instructions injected into content the agent reads, such as a web page, a product listing, a review, an email or a tool response, so the agent pursues someone else's goal using its own legitimate authority.

Nothing is stolen here, which is what makes it hard to handle. Every request is signed with the right key, issued from the right runtime, inside the right session, so there is no credential to rotate and no anomaly at the authentication layer. The only reliable tell is semantic distance between what the principal mandated and what the agent is now doing, which means operators need instruction provenance logged alongside actions and a policy engine that compares intent to mandate before payment. Liability is unresolved when a hijacked agent pays an attacker, and it will be settled by scheme rules and merchant contracts rather than by existing card regulation.

Compromising, substituting or maliciously describing a tool that an agent calls, so that invoking it executes the attacker's intent instead of the caller's. Variants include tampering with a tool's description or metadata, which the model reads as instruction text, swapping the endpoint behind a familiar tool name, and returning crafted results that steer subsequent reasoning.

Tool surfaces are trusted input to an agent in a way no equivalent exists for a human user, since the agent has no independent means of confirming that a tool does what its description claims. A poisoned payment or checkout tool can substitute a destination wallet or an amount while reporting the expected merchant back to the principal, so the summary the human reads is fiction. Operators should treat the tool manifest as part of the agent's permission set, pin server versions, and alert when tools appear mid-session or a tool's declared behavior changes. Payment-side controls should compare the destination that actually receives funds against the merchant of record.

Attacks that target what an agent depends on rather than the agent itself, including model weights or a fine-tune, the orchestration framework, a package in the runtime, a hosted MCP server or a prompt template fetched at start-up. It is the familiar software supply chain problem pointed at a component that holds transaction authority.

Blast radius is the difference. One poisoned dependency can compromise every agent in a fleet that shares it, and each of those agents carries a valid credential, a clean transaction history and, in a reputation system, a good score earned honestly. Counterparties checking identity or past behavior will pass all of them. Operators should capture a model and dependency inventory at issuance so an affected population can be enumerated later, and should be able to freeze by dependency rather than one agent at a time. No accepted standard exists yet for attesting an agent's runtime to a counterparty that did not build it, and framework vendors and scheme rulebooks will have to settle what such an attestation must contain.

Automated replay of breached username and password pairs across many sites, exploiting the fact that people reuse credentials. Classic defenses combine rate limiting, bot detection, device intelligence and forced step-up on suspicious logins.

For agents the reusable secret is an API key or a long-lived OAuth token, and its handling is far worse than a consumer password. Keys get pasted into configuration files, environment variables, notebooks, CI pipelines and shared workspaces, copied between staging and production, and rotated rarely because rotation breaks running workflows. Bot detection is useless as a discriminator because the legitimate traffic is already automated, and a successful replay is indistinguishable from normal operation at the request layer. What remains observable is origin and concurrency, so operators should alert on the same key presenting from a new network, region or runtime, on simultaneous use from two places, and on use outside the agent's established operating window. The durable fix is binding the credential to an issued agent identity with a narrow scope and a short life.

Stealing a live session cookie or bearer token, typically through infostealer malware, a malicious browser extension or cross-site scripting, and replaying it to enter an authenticated session without logging in. It is valued by attackers because it skips the credential and the multi-factor challenge entirely.

Agents hold the same class of artifact in larger quantities and hold it longer. A working agent accumulates session tokens for merchants, banks, marketplaces and internal systems, commonly stored in plaintext inside a container image, a mounted volume or a developer's machine, and refreshed automatically so they never expire in practice. The payoff is higher than a consumer session because the token arrives attached to standing spend authority and a checkout flow that expects no human confirmation. Operators should watch for a token presented from a runtime that is not the agent's, or replayed from a different egress network, and should bind tokens to the agent's signing key so a stolen token without a valid signature fails at the counterparty.

Seizing control of an authenticated session while it is open, through token theft, network interception or session fixation. Exposure has traditionally been bounded by idle timeouts, absolute session lifetimes, re-authentication before sensitive actions and continuous session risk scoring.

Those bounds assume sessions end, and for agents they often do not. A long-running agent keeps a session alive for days or weeks, refreshing it automatically because interrupting it would break the task, so the timeout that once capped a hijack never fires. Re-authentication before a sensitive action assumes a person is available to perform it, and an unattended agent has nobody to ask. Operators need continuity checks at the session level instead, confirming that the same runtime, the same signing key and a consistent behavioral pattern persist across the life of the session, and treating a change in any of them as a compromise indicator. Where a human would receive a step-up challenge, the agent equivalent is an out-of-band confirmation to the principal and a freeze if it goes unanswered.

An attacker holding valid credentials triggers repeated push approvals until the victim approves one to stop the noise. The attack works on inattention and irritation rather than on any weakness in the factor itself.

Automation changes the dynamic in both directions. An agent acting as approver cannot be worn down by volume, so the classic version of the attack fails, but it can be talked into approving by injected instructions or a well-formed request, and it approves in milliseconds with none of the hesitation a person shows. The mirror-image risk is an agent that legitimately generates high approval volume against a human principal, since a person asked to confirm two hundred small purchases a day is trained into reflexive approval and will wave through the one that matters. Operators should instrument approval latency and approval rate, because a near-total approval rate at sub-second latency describes a control that has stopped functioning. Pre-authorizing routine spend inside the mandate and escalating only genuine exceptions is the practical remedy.

Reactivating a credential or account that has sat idle long enough that nobody is watching it. The classic analogues are the dormant bank account revived for mule activity and the unused card reactivated after a data breach.

Agent estates generate dormant credentials quickly and quietly. Test agents, single-purpose agents built for one task, agents belonging to departed employees and agents orphaned by a retired workflow all persist with valid keys, spend scope and established merchant relationships, and none of them raise an alert while doing nothing. They are attractive targets because their history is clean, their age reads as trustworthy to reputation scoring, and their first anomalous transaction has no recent baseline to be measured against. Operators should treat inactivity as a state that carries consequences, maintaining an inventory of issued agents, auto-freezing after a defined idle period, and requiring the principal to reactivate deliberately. An agent that has transacted nothing for months should not be able to spend again without a fresh authority check.

Detecting compromise by measuring an agent's live behavior against a known-good reference, either a recorded baseline of that agent's own past behavior or a controlled instance of the same build running a reference task in a clean environment. Divergence beyond a defined tolerance is the signal, whether or not any credential looks wrong.

The technique suits agents because the conventional compromise indicators, credential validity and device and geography, are the least informative signals available once an attacker holds the agent itself. Comparison is done on tool call sequences, counterparty selection, spend distribution, instruction provenance and timing. Running a clean reference instance also helps separate causes, since a reference that diverges in the same direction points at a shared model or dependency rather than at one compromised deployment. The limits are real. Baselines need enough stable history to exist, agents that are legitimately nondeterministic generate noise, and a patient attacker can drift inside the tolerance band. Where that tolerance sits is an operator judgment that no standard currently settles.

A notification to the principal that an agent's behavior or permission set has changed in a way consistent with compromise. It differs from a declined transaction because it concerns the state of the agent rather than the merits of one payment, and it is addressed to the human who delegated authority rather than to the counterparty.

Typical triggers include permission escalation, an authorization scope that cannot be derived from the mandate, a changed destination wallet, a new or altered tool surface, activity from an unfamiliar runtime and the sudden reactivation of a dormant agent. Latency dominates usefulness, since an agent can complete a long run of transactions in the time a person takes to open an email, so the alert has to carry one immediate action rather than a report to read later. FLINT's Sentinel pairs the alert with a one-tap reversible freeze, moving the passport to frozen and reserving revoked for confirmed compromise. Alert fatigue is the failure mode, so thresholds should be tied to the mandate instead of firing on every change.

Concealing the criminal origin of value so that it can be held, moved and spent without attracting attention. Practitioners describe the process in three stages, placement, layering and integration, and most monitoring programs are built around the timing and shape those stages take when human beings execute them.

Automation collapses the interval between the stages. An agent holding a wallet and a payment credential can receive value, move it across dozens of counterparties and spend it into ordinary goods and services within a single session, so a monitoring model never gets the days of dwell time it was calibrated against. Volume shifts as well, because the marginal cost of one more transaction approaches zero and each one can sit far below any threshold rule. Investigators also lose the human tells they lean on, since there is no login rhythm and no fatigue to profile. The control has to move upstream to who authorized the agent, what it was authorized to do, and whether the delegation chain terminates in a principal anyone can name.

The first stage, in which illicit proceeds enter the financial system. Classically it means depositing cash or buying monetary instruments, and it is the stage where the launderer is most exposed because cash handling triggers currency transaction reporting and teller scrutiny.

The front door for agent-era placement is not a branch. It is the fiat-to-stablecoin conversion at an exchange, the funding of an agent wallet from an account the agent does not own, the issuance of a virtual card to an agent, or the top-up of a prepaid API balance that can later be spent or resold. Exposure moves to whoever funds the wallet and to whether that funding can be reconstructed after the fact. Operators paid by agents should treat a freshly funded wallet with no prior activity as an unresolved provenance question rather than a new customer, and should ask what the funding source was before the first payment clears, not during a later investigation. Wallet provenance is doing the work that cash handling controls used to do.

Moving value through a series of transactions whose real purpose is to break the audit trail. Chains of transfers, cross-border hops and conversions between asset types all serve to put distance between the proceeds and the predicate offense.

Layering used to be constrained by settlement time, fees and the number of accounts a crew could operate. Agent-to-agent stablecoin transfers settle in seconds for fractions of a cent, so the number of hops becomes a matter of patience rather than budget, and each hop can be dressed as plausible machine commerce such as a data purchase, an inference call or a compute reservation. Graph analysis still works in principle, but it has to run at machine speed and it has to key on an identifier that survives across hops, which wallet addresses and ephemeral agent identities do not. What persists across a well-built laundering chain is the principal, if anyone bothered to record it. Operators should insist that agent identity be durable and verifiable at every hop rather than reissued at each one.

The final stage, in which laundered value re-enters the economy in a form that looks earned. Property purchases, business revenue, loans to oneself and payroll are the traditional vehicles, and the objective is a paper trail that would survive a bank's questions about source of funds.

Machine commerce provides a new integration surface. An agent that buys compute, data, storage, inference and third-party API access generates invoices and settlement records that read as ordinary operating expense, and an agent-operated vendor can book payments from agents its own principal controls as legitimate revenue. The difficulty for an investigator is that real machine demand and manufactured machine demand have the same signature, namely high-frequency, small-ticket, business-to-business spend with no consumer behavior attached. The useful test is independence, meaning whether the counterparties on both sides resolve to unrelated principals. Circular flow between agents sharing an issuer, a funding wallet or infrastructure is the pattern worth surfacing, and it is only visible if counterparty resolution happens across merchants rather than inside one.

Deliberately breaking a transaction into smaller ones to evade a reporting or recordkeeping requirement. In the United States it is a separate federal offense under 31 U.S.C. 5324, and the element that matters is the intent to evade rather than the amount involved, which is why deposits kept just under the $10,000 currency transaction reporting threshold are charged even when the funds are clean.

An agent executes an instruction exactly, so a spending policy that caps individual transfers produces textbook structuring with no deposit slip involved. That creates an unresolved attribution problem, because the intent to evade would have to be located in the principal who set the policy, the developer, or the operator running the agent, and no published enforcement action has settled how that is charged. Pattern alone will not distinguish evasion from ordinary agent design, since splitting payments for rate limits and budget control is normal engineering. The evidence that separates them is the mandate and the authorization scope, so retain both and their revision history.

A variant in which each transaction sits far below the reporting threshold rather than just beneath it, so detection tuned to threshold proximity never fires. Catching it depends on aggregation across time, counterparty and account rather than on any single transaction looking wrong.

Agentic payment turns micro-structuring from a technique into the default output of normal activity. Per-call payments for inference, bandwidth, data rows and tool access are naturally sub-dollar, which means the population of suspiciously small payments becomes the entire population and size stops carrying information. Baselining has to move to the relationship, meaning which agent, under which principal, paying which counterparties, at what aggregate over what window. Aggregation logic that exists today was written for currency transactions by or on behalf of the same person, and whether it reaches high-frequency stablecoin transfers by an agent fleet is untested and would most likely require rulemaking rather than interpretation. Until that happens, aggregation by principal is a control operators have to build themselves.

The movement of material value as a very large number of sub-dollar machine payments, each individually beneath every reporting, recordkeeping and monitoring threshold in force, and beneath the cost of investigating it. It defeats no single rule so much as it exits the size assumptions the rules were drafted around.

The Bank Secrecy Act framework rests on transaction sizes and human transaction rates that agentic flow does not produce. A million payments averaging $0.80 moves hundreds of thousands of dollars while never approaching a currency transaction report, never reaching the $3,000 funds transfer recordkeeping threshold, and never carrying the per-transaction weight that puts an alert in a review queue. Stablecoin rails make the arithmetic work, because settlement cost per payment is negligible and the same rails serve as the cash-out. No regulator has said how aggregation obligations apply here, and treating that silence as permission is a mistake. The workable control is aggregation and identity at the principal level, applied before the payment rather than in a monthly lookback.

Spreading structured transactions across many individuals so that no single actor's activity looks remarkable. Recruitment is the binding constraint, since each smurf has to be found, paid, trusted and managed, and every one of them is a person who can be identified, interviewed or turned.

An agent fleet is a smurf network with the recruitment cost removed. Provisioning a thousand agent identities is a configuration task, none of them take a cut, none defect, and none show up at a branch on camera. Traditional smurf detection leaned heavily on the human infrastructure behind the accounts, meaning shared phone numbers, addresses, devices and family relationships. The machine equivalents exist but sit at a different layer, namely shared issuers, shared key material, shared funding wallets and shared hosting. Operators should treat identity issuance as the chokepoint and look for correlated agents that resolve to a single principal, because without a binding link back to a principal a fleet is indistinguishable from a thousand unrelated customers.

A person who receives criminal funds into their own account and forwards them onward, sometimes knowingly, often recruited through a fake job offer or a romance approach. The value to the launderer is that a real identity with a real banking relationship sits between the criminal and the proceeds.

The agent equivalent needs no persuasion, takes no cut, and cannot develop second thoughts or cooperate with an investigator. Most mule casework depends on the human being interviewable and on the recruitment channel being traceable back toward the organizer, and an agent offers neither surface. What replaces the interview is the delegation chain, meaning the record of who issued the agent, who funded it, and what it was instructed to do. Where that record is missing or cannot be verified, the agent is functionally an anonymous mule with better uptime and no arrest risk. Operators should refuse to accept an agent's own assertion as evidence of origin, in the same way they would not accept a mule's account of where the money came from.

An agent identity created to receive and forward illicit value and then abandoned once it has been used or flagged. It differs from a hijacked legitimate agent in that there was never a genuine principal or purpose behind it, so nothing about its behavior is a deviation from anything.

The economics are what make this hard. Creating one costs almost nothing, burning one costs almost nothing, there is no account opening to survive, no relationship worth preserving and no history to protect, and a useful lifetime can be measured in minutes. Detection therefore cannot depend on behavioral history, because there will not be any by the time the money is gone. The signals available at first contact are the provenance of the funding wallet, whether the issuing party is credible and reachable, whether a signed authorization record traces to a principal that actually exists, and whether the agent's stated purpose matches its first action. Absence of history should be scored as risk rather than treated as neutral.

A set of accounts operated in coordination so that value can be split across them, moved through them and recombined at the far end. Detection is a graph problem, built on shared attributes between accounts and on the shape of funds flowing between them.

Agent systems produce these graphs as a matter of ordinary design, because orchestration is how multi-agent workflows are built. A planner delegating to worker agents that each hold a wallet has the same topology as a laundering network, so shape stops being diagnostic. What separates the two is whether every node in the cluster traces to a disclosed principal operating under a coherent mandate, and whether the cluster's aggregate behavior is consistent with that mandate. Graph detection keyed on wallet addresses will fail on its own, since rotating addresses costs nothing, so the clustering key has to be identity and issuance rather than address. Clusters that cannot be resolved to a principal deserve to be treated as high risk on that basis alone.

An account opened to receive funds and then be discarded, typically established with a stolen or synthetic identity, used within a short window and left behind once it is frozen. Onboarding friction and the cost of a usable fake identity set a floor on how disposable such an account can be.

Agent wallets sit below that floor. A self-custodied wallet requires no onboarding, nobody had to be impersonated to create it, and abandoning one costs a few seconds and some gas. Any control that relies on the expense of account creation stops working. The practical response is to move the costly thing from the account to the identity, so that an agent carries a passport that took effort to obtain and accumulates reputation worth keeping, which makes abandonment expensive again. Wallets whose entire history is one inbound and one outbound transfer are worth surfacing on that pattern alone. How far existing money services rules reach self-custodied agent wallets remains unsettled, and operators should not assume a licensed intermediary is present.

An account that takes in deposits from many dispersed sources and is swept out quickly, often from a different location than the one the deposits came from. The classic red flag combines many-to-one inbound flow with rapid outbound movement and very little balance held between the two.

Agent payment aggregation is architecturally identical. A settlement agent collecting thousands of micro-payments and sweeping them to its principal's wallet produces exactly this shape, and so does any facilitator built for machine commerce, so inbound dispersion and sweep speed no longer separate the legitimate case from the laundering case. What still separates them is whether the inbound counterparties are themselves verifiable, and whether the sweep destination was disclosed in the agent's mandate before the flow started rather than explained afterward. Operators should expect funnel-shaped flow to be normal in agentic settlement and rebuild the alert around counterparty verification and destination disclosure instead of retaining a shape-based rule that will now fire constantly.

A legal entity with no meaningful operations, staff or assets, used to hold accounts, own property and obscure who actually controls the money. Beneficial ownership disclosure is the standard countermeasure, on the theory that someone must eventually be named as the human behind the entity.

The agent-era analogue is a passport with no principal, meaning an identity that presents credentials, holds a wallet and transacts, yet resolves to no accountable person or company. The function is the same, since it interposes a legitimate-looking layer between the value and whoever controls it. The difference is that incorporating an entity at least leaves a registry entry somewhere, while an agent identity may leave nothing but a key and a self-asserted name. Operators should require that the delegation chain terminate in an identified principal and should treat an issuer unwilling to name a responsible party the way they would treat a company that refuses to disclose its beneficial owner. Whether beneficial ownership frameworks reach agent identities at all has not been tested.

A business with genuine operations used to commingle illicit proceeds with real revenue. It is harder to unwind than a shell because there is actual activity to point at, and the illicit share hides inside the natural variance of a real book of business.

Agent commerce supplies plausible transaction volume on demand. A vendor selling API access, data or compute to agents can generate demand from agents its own principal controls and record it as revenue that looks the same as any other customer's spend. Because machine demand can legitimately be spiky, high frequency and low ticket, the variance band an investigator would use as a baseline is much wider than in a retail business, which leaves more room to hide. The test that survives is buyer independence. Revenue concentrated in counterparties that share an issuer, a funding source or infrastructure with the merchant is the signal, and it is generally invisible from inside a single merchant's own data, which is what makes reputation data pooled across merchants useful here.

Laundering offered commercially by specialists, priced as a percentage of the amount cleaned and packaged with the accounts, mules and cash-out routes needed to deliver it. Providers compete on price, speed and reliability, and their customers are other criminals rather than the ultimate holders of the funds.

Agent infrastructure lowers the cost of running such a service and raises its throughput. A provider can sell funded wallets, agent fleets and orchestration as a product, and the marginal cost of adding another route is a provisioning call rather than another recruited person. Expect a market in agent identities with manufactured history, sold the same way aged social accounts and warmed email domains are sold today. Operators should therefore treat agent reputation as an attackable surface, on the principle that anything purchasable is farmable, and weight signed evidence contributed by real counterparties above any history an agent asserts about itself. Dense but shallow transaction history against counterparties that never dispute anything is worth a second look.

Processing sales for a prohibited or undisclosed business through a merchant account approved for something else. The acquirer sees an approved merchant category and a normal-looking ticket, while the goods actually sold are ones the acquirer would have declined to board.

Agent order flow thins out what little visibility the acquirer had. When the buyer is software, the incidental evidence a human shopper generates, meaning browsing history, cart behavior, device characteristics and a shipping address, is either absent or synthesized, so the descriptive signals used to spot a mismatch between stated and actual business are weaker. The reasonable response is to require checkout to carry an assertion of what is being purchased and who authorized it, retained as a signed record the acquirer can inspect later. Card network and acquirer rules do not yet address how responsibility is assigned when laundering runs through agent-mediated checkout, so allocation currently happens in commercial contracts, and the party holding contemporaneous evidence of what was authorized is the one in the stronger position.

Arranging transactions so that a sanctioned party receives value without appearing as a counterparty, usually through intermediaries, layered ownership or mislabeled goods and destinations. United States sanctions liability does not require knowledge, so a firm that facilitates a prohibited transaction unwittingly is still exposed.

An unverified agent is a ready-made intermediary. Screening works on names, addresses and ownership percentages, and none of those exist in usable form when the counterparty presents as a key and a self-chosen label. That gives a blocked party a layer that is cheap, disposable and outside the reach of every list-matching tool currently deployed. Because liability attaches without intent, an operator that pays an agent controlled by a sanctioned person carries that exposure whether or not it could have known. The workable posture is to decline payment to any agent that cannot be resolved to a screenable principal and to keep the record showing what was resolved and when. How far screening obligations extend through an agent to its principal has not been addressed in published guidance.

A value transfer arrangement operating alongside or outside regulated banking, in which an operator in one place pays out on behalf of an operator in another and the two settle later, often by netting. Hawala is the familiar example. Such systems are money transmitters under United States law and must register, but the compliance gap comes from the value transfer and the settlement being decoupled, so the flow that matters never appears as a single traceable payment.

Agent-to-agent stablecoin flow reproduces this structure without anyone setting out to build an IVTS. Value moves as instructions between agents, obligations accumulate, and settlement between operators can be netted later or handled off the visible rail entirely. Because the payments are small, frequent and machine-initiated, none of it resembles remittance traffic. Existing guidance on convertible virtual currency turns on who has independent control of the funds, and how that applies to an operator of agent payment infrastructure is untested. Anyone building such a network should document custody and control now rather than after the question is asked.

Raising, moving and using funds to support terrorist activity or organizations. It inverts the usual laundering problem, because the money is often legitimate in origin and the amounts involved are frequently small, which defeats detection that was tuned to look for criminal proceeds in meaningful sizes.

Small amounts are exactly what agent rails are optimized to carry. Sub-dollar transfers spread across many agent identities and multiple jurisdictions settle without an intermediary positioned to hold or question them, and speed removes the interval in which a human reviewer might otherwise intervene. Deniability improves as well, since the person who instructed the agent is separated from the transaction by a delegation chain that may never have been recorded. What remains available to detection is the network rather than the amount, meaning which principals, which issuers and which clusters of agents keep appearing together. That argues for retaining a durable record of who authorized every payment even when the individual value is trivial, because in financing cases the amount was never going to be the signal.

A control pattern in which identity, authority and risk are resolved before value leaves the payer, rather than being reconstructed afterward from settlement data. Card ecosystems tolerated post-hoc detection because chargeback rights, settlement windows and reversal mechanics gave the payer a second chance. Faster rails narrow that window, and some remove it.

When the payer is an agent, the second chance usually does not exist at all. Stablecoin transfers, instant bank rails and per-request API payments settle in seconds and are final, and an agent can fan out across dozens of counterparties before any batch review runs. The check that matters is whether this agent, acting for this principal, currently holds authority for this specific action and amount, and that question has to be answered synchronously in the payment path. The common failure is a flow that verifies a human once at onboarding and then lets a delegated agent transact unbounded. Control moves from reconciliation to pre-authorization, and evidence has to be captured at the same moment.

The same pre-authorization discipline applied at the point of fulfillment rather than the point of payment, for sellers whose product is delivered rather than shipped. It covers API responses, inference calls, data pulls, license grants and seat provisioning, where the cost is incurred the instant the request is served.

Sellers of digital capability have no shipping delay in which to catch fraud and often no chargeback exposure to motivate them, which makes the risk easy to underprice. The real loss is unrecovered cost of service, quota consumed by an unauthorized caller, and downstream liability for what the delivered capability was used to do. Because the requester is an agent, the check belongs at the gateway on each request, keyed to the agent's presented authority, not at the monthly invoice or the account level. Watch for API keys shared across an entire agent fleet, which collapses the distinction between an authorized agent and a compromised one. Rate limits are not an authority check.

A cryptographically signed artifact emitted at decision time that states which agent was evaluated, what authority it presented, which signals were considered, what verdict was returned and when. It binds to the transaction it authorized, so it cannot be detached and reused against a different action.

Parties to an agentic dispute are frequently three rather than two, since the agent, the principal it acted for and the counterparty are all distinct. A merchant that accepted an agent's payment needs to show later that it checked authority before serving, and cannot rely on the agent's own claims for that. The record is what the merchant holds. Useful records carry the inputs and the reasoning basis, not just a verdict string, because a bare verdict proves only that something answered. Confirm the record is independently verifiable, is bound to transaction identifiers and a timestamp, and cannot be replayed. How dispute forums and card networks will weigh such records is unsettled, and will be decided by scheme rules and litigation rather than by issuers.

Evidence that its holder can verify and present on its own, without a live call back to whoever produced it. The payload carries everything a verifier needs, and the issuer's role is reduced to publishing a key rather than answering a lookup.

Agentic disputes surface across organizational boundaries and often long after the fact, which is exactly when a callback-dependent proof fails. The vendor may be gone, the API version retired, the account closed, or the retention period shorter than the dispute window. An agent that transacted with forty merchants leaves forty separate evidentiary positions, and none of those merchants control the system that made the decision. Portability is what lets each of them defend independently. The practical requirements are a self-contained signed payload, stable key publication with documented rotation, and a verification routine that a counterparty can run offline years later. Anything that resolves only through a live dashboard should be treated as a report, not as evidence.

Signing a single payload with two independent algorithms in parallel, one classical and one post-quantum, so the artifact remains verifiable if either family is later broken. In this product the pair is ES256 and ML-DSA-65, and a verifier can check whichever algorithm it supports without needing both.

The reason to bother is retention time. Financial and AML record-keeping obligations commonly run five years or more, disputes surface late, and evidence created now may need to hold up against future capability rather than current capability. A signature is not confidential, so the exposure is not decryption of old data but forgery of old attestations, and an attestation that can be forged retroactively is worthless as evidence. Costs are real and should be stated plainly, since record size grows and verification requires libraries many counterparties do not yet ship. Whether adjudicators will ever require the post-quantum branch is unknown, and the honest position is that this is insurance on the evidentiary layer, not a live threat model today.

The logic that converts a set of verification signals into a bounded score and one of a small number of discrete verdicts. It defines which signals are considered, how they are weighted, where the thresholds sit and what each verdict obliges the caller to do next.

Because the consumer of the output is usually software rather than an analyst, the model must produce something machine-actionable and stable rather than a probability an operator interprets by feel. A bounded score makes outcomes comparable across transactions, counterparties and time, which is what allows thresholds to be tuned and audited. Determinism matters more than in human flows, since an agent that receives different verdicts for identical inputs will retry until it gets the one it wants. Operators should insist on versioning, because a silent weight change alters the meaning of every record already issued under the previous version. Exposing the verdict and its reason to the caller is normally right, while exposing the full weighting invites probing.

The verdict permitting an action to proceed inside the controls declared at the time of the check. It asserts that authority was established and that risk sat within limits for that specific action, amount and counterparty, and it asserts nothing beyond that.

The failure mode particular to agents is treating an allow as a standing grant. An agent holding a successful verdict for one purchase will, if the integration lets it, present or assume the same clearance for the next call, a larger amount, or a different merchant. Bind every allow to the action it covers, give it a short validity, and make replay detectable rather than merely discouraged. Operators should also decide in advance what an allow does not cover, since the controls it references are only meaningful if something downstream enforces them. A verdict recorded but not enforced at the rail is documentation, not a control.

The verdict requiring additional proof before the action clears. STEP-UP means more verifiable evidence is required, and it is not an affirmative fraud finding. In human-facing risk flows this has meant a one-time passcode, a biometric prompt, a 3-D Secure challenge or a document check, all of which assume a person is present to respond.

None of those assumptions survive delegation. An agent cannot meaningfully receive an SMS code, and any challenge the agent can satisfy entirely on its own proves only that the agent is still the agent, which was rarely the question. Useful agentic step-ups take one of two shapes, either an out-of-band challenge that reaches the human principal on a channel the agent does not control, or a demand for stronger cryptographic evidence such as a fresh, narrowly scoped mandate signed by the principal. The second is the only version that holds under machine-speed volume, because a human confirmation on every transaction defeats the point of delegation. Design for asynchrony, since the agent's workflow has to park and resume rather than block.

The verdict routing a case to a human because the signals conflict and no automated outcome is defensible. Classic implementations put the case in a queue, hold the transaction, and depend on an analyst reaching it within a service-level window.

That model assumes the transaction can wait, which an agent workflow generally cannot. A review verdict must therefore carry an explicit holding behavior, a timeout and a defined fallback outcome when the timeout expires, and the fallback should be declared in advance rather than improvised. Volume is the second problem, since review rates that were tolerable as a percentage of human transaction counts become unworkable against agent traffic, where a single workflow may generate thousands of small calls. Size the queue by absolute case count per hour and staff to that, then push the model to resolve conflicts that recur rather than sending each instance to a person. Every review outcome should feed back as labeled data, otherwise the same conflict arrives forever.

The terminal verdict. The request fails an authority, policy or risk check and does not proceed, and no additional proof is offered as a path forward within that attempt.

Agents respond to refusal differently from people. A goal-directed agent that is blocked will commonly retry, reword the request, split the amount, switch payment method, or route through a different counterparty, and none of that necessarily indicates malice, it indicates persistence toward an objective. Blocks must therefore attach to the agent identity and the underlying intent rather than to the individual request, and the same attempt reaching a second rail should meet the same answer. Enforcement has to sit at the point where value or access actually moves, since a verdict returned to an agent that also controls the execution path is advisory at best. Track retry patterns after a block as a signal in their own right, and remember that false positives now cost a stalled autonomous workflow rather than one annoyed customer.

A single number summarizing the risk of an event, derived from many underlying inputs. On its own it means nothing, since its entire operational value comes from the thresholds attached to it and the actions those thresholds trigger.

Scores calibrated on human populations misread agents in both directions. Transaction velocity, headless environments, datacenter addresses, absent mouse and typing dynamics and perfectly regular timing are anomalies for a person and unremarkable for an agent, so a model trained on the former inflates risk on legitimate automation while missing agent-specific abuse entirely. Score agent traffic against agent baselines, and keep the populations separate rather than adding an "is bot" feature to an existing model. A second consideration is that the score is increasingly consumed by other software, so it should travel with the reason and the model version rather than alone. Publishing a raw score to a counterparty agent invites optimization against it.

An outcome reached and applied without a human reviewer in the loop. Most mature risk programs already auto-decide the large majority of events and reserve people for the ambiguous remainder.

In agent commerce automated decisioning is not an efficiency choice, it is the only mode that operates at the relevant speed and volume. What changes is that both sides of the interaction are now automated, so no human is present at the decision or at the transaction, and the traditional assumption that someone eventually looks at something does not hold. Programs should compensate with deliberate sampling of auto-decided traffic, complete decision logging, and alerting on distribution shifts rather than on individual cases. Whether existing supervisory expectations around meaningful human oversight extend to this arrangement is untested, and firms should document their governance now instead of waiting for it to be settled by an examiner. The record produced at decision time is what makes the automation reviewable after the fact.

The component that combines signals, scores and policy rules into a real-time outcome for a specific event. It sits in the transaction path, takes structured inputs, applies the current model and rule set, and returns an outcome the caller is expected to enforce.

Placement changes when the caller is an agent. The engine has to answer synchronously inside a tool call, within a budget measured in hundreds of milliseconds, because the latency lands inside someone's agent turn and gets traded off against the check being skipped. The input mix shifts as well, away from device and behavioral telemetry and toward passport validity, mandate freshness, delegation chain integrity and spend against declared limits. An engine serving agents must also emit evidence rather than only an answer, since the calling merchant needs something to keep. Guard against rule discovery, because an agent that can retry cheaply will map thresholds by probing, and repeated near-miss attempts should themselves raise risk.

Applying controls in proportion to assessed risk rather than imposing the same requirements on every event. It is the basis of most modern fraud and AML program design, and it depends on having risk dimensions that actually discriminate.

Amount is the dimension that degrades first in agentic flows. When an agent makes thousands of sub-cent or few-cent calls, per-transaction value thresholds classify nearly everything as negligible while cumulative exposure grows unchecked, and structuring becomes an emergent property of normal operation rather than a deliberate evasion. The dimensions that hold up are authority-based, meaning how broad the granted scope is, how fresh the mandate is, how novel the counterparty is, how long the delegation chain is, and how much has been spent against the limit in the current window. Rebuild tiers around those, and evaluate aggregate spend per agent per period alongside per-transaction risk. Uniform rules fail here for the usual reason, they are either too tight to permit useful autonomy or too loose to constrain it.

In risk practice, the coordination of multiple verification and data services into a single flow, with conditional routing, fallbacks and a consolidated result. The orchestration layer decides which providers to call, in what order, and what to do when one fails or disagrees.

The word collides badly in this domain. In agent frameworks, orchestration means the coordination of models, tools and sub-agents toward a task, so the same term appears twice in one architecture diagram meaning two different things, and teams should qualify it as risk orchestration or agent orchestration in writing. Beyond the naming problem, risk orchestration in agent flows has to fit inside a tool call budget rather than an onboarding session, which rules out long serial provider chains. Fallback behavior needs to be specified precisely, since a provider timeout that silently degrades to a permissive outcome is how agents end up transacting unverified. Every provider consulted and every fallback taken should appear in the evidence record.

A sequence of checks run in order, usually cheapest and fastest first, continuing only until sufficient confidence is reached or the sequence is exhausted. It trades unit cost against coverage and is standard in identity verification and onboarding.

Waterfalls were designed for flows where a few seconds of wait is acceptable, and agent transaction paths do not offer that. Every additional stage is added to the latency of the agent's turn, and integrators facing a slow check will move it out of the critical path or drop it. The reordering that follows is to put cryptographic authority checks first, since verifying a signature, a mandate and a scope is fast, deterministic and often decisive on its own, leaving external data calls for the residual cases. Depth also becomes observable, because an agent that retries with variations can infer from response timing which stage rejected it. Cap the cascade explicitly and define the outcome when the cap is hit rather than letting it run.

An individual indicator that feeds a decision, such as a device attribute, a network property, a behavioral measurement or a history lookup. Signals are only useful insofar as they separate populations, and a signal that no longer separates anything still occupies a slot in the model.

Most of the fraud stack's inherited signals describe a human being at a keyboard, and they lose discriminating power when the transacting party is software running in a datacenter. Device fingerprints, IP reputation, typing cadence and session behavior converge across legitimate and illegitimate agents alike, so confidence built on them is thinner than the dashboard suggests. Agent-era signals are about authority and provenance instead, including passport validity and issuer, mandate freshness and scope, delegation chain integrity, conformance between the requested action and the granted scope, cumulative spend against limit, wallet provenance and counterparty history. Operators should audit their signal inventory for which inputs still discriminate on agent traffic and retire or reweight the rest, rather than carrying dead weight into a new risk surface.

Velocity measures how much activity an entity generates over a defined window, counted in transactions, accounts touched, authorization attempts, logins or dollar value. Rules built on it assume a human hand behind each event, so thresholds sit at a pace a person could plausibly sustain.

Agent traffic breaks that assumption at the source. A legitimate procurement agent may fire hundreds of small purchases across dozens of merchants inside a minute, a rate any conventional rule would have scored as certain card testing. Raising thresholds to accommodate agents removes the control rather than tuning it, because a compromised agent runs at exactly the same speed as an authorized one. The workable move is to measure rate against the mandate instead of against a human baseline, asking whether this volume sits inside the spending limits, merchant categories and time bounds the principal actually granted. Velocity becomes a scope question, and the alert fires when the pace carries the agent past the authority it holds rather than past an arbitrary count.

Detection by departure from baseline, where the system learns what normal looks like for a population or an individual account and flags what sits far enough outside it. Nothing about the method requires labeled fraud, which is why it carries most of the load against patterns nobody has seen before.

Baselines learned from human behavior misfire on agents in both directions. Agents look anomalous constantly on the dimensions humans vary on, timing, session length, navigation path, typing cadence, so the model screams at ordinary automated commerce. On the dimensions that actually matter for agent abuse the same agent looks perfectly consistent, because a hijacked agent keeps the identical machine rhythm while the destination, the merchant and the beneficiary change underneath. Operators need per-agent baselines keyed to a stable agent identity rather than a device or session, and the meaningful anomalies are shifts in counterparty, scope and delegation chain, not in speed or regularity.

Drift is the decay in a model's performance as the distribution it was trained on stops matching the world it scores. Practitioners separate covariate drift, where the input mix moves, from concept drift, where the relationship between features and fraud outcomes itself changes.

Agent adoption delivers both at once, and faster than the retrain cycles most fraud teams run. The input mix moves because automated traffic replaces human traffic on the same rails, and the concept moves because behavioral features that carried real predictive weight against humans carry none against software. Worse, the drift is adversarially shaped, since attackers can now generate high volumes of plausible-looking legitimate traffic cheaply and shift the baseline they are hiding inside. Teams should expect shortened model half-lives, monitor score distributions split by whether the counterparty is human or agent-initiated, and lean harder on features that are cryptographically anchored rather than learned, because identity and authority evidence does not drift the way behavior does.

Friction is deliberate work inserted into a flow to slow an actor down, raise the cost of an attack, or force a moment of conscious human attention. Classic examples include one-time passcodes, selfie liveness checks, cooling-off delays, CAPTCHAs and re-authentication at checkout.

Almost all of it is calibrated against human patience, which is why it does nothing to an agent. An agent will happily wait, retry, and solve or route around the challenge without irritation, so friction stops functioning as a deterrent and functions only as latency. The deeper problem is evidentiary. Passing a CAPTCHA once proved a human was present, but it now proves nothing about who authorized the payment or whether the agent is still operating inside its mandate. Step-up for an agent has to be redirected at the principal or at the agent's cryptographic authority rather than at the runtime, which means the control moves from the interface to the credential.

Manual review routes a flagged transaction or account to a human analyst who examines the case and adjudicates it, usually against a queue with a service-level target. It exists because some decisions carry consequences that a model's confidence score alone should not settle.

Agent volume makes the queue arithmetic impossible. Machine-initiated commerce can generate orders of magnitude more decisions per hour than human commerce did, and any review rate that was tolerable at human volume becomes an unstaffable backlog. Analysts also lose the material they were trained to read, since there is no browsing history, hesitation pattern or phone call to interpret, only a machine identity and whatever authority evidence accompanies it. Review has to be reserved for genuine conflict, cases where the identity is unverifiable, the mandate is ambiguous, or two parties dispute what was authorized, and everything else must be resolved by automated verdicts that emit evidence an analyst can inspect later if the case reopens.

The share of legitimate activity a control wrongly flags or declines, measured against the total legitimate population rather than against alert volume. It is the cost side of every fraud control, paid in abandoned checkouts, lost customers and support load.

Many platforms currently run a categorical block on detected agent traffic and treat it as prudence. It is a false positive strategy with the measurement switched off, because the declined population is overwhelmingly legitimate delegated purchasing and the platform never sees the revenue it forfeited. The cost compounds as buying moves to agents, since a blocked agent does not retry manually, it reroutes the entire basket to a merchant that accepts verified agents. Operators should measure agent decline rates separately from human ones, and the exit from blanket blocking is verification, deciding on the strength of the agent's identity, mandate and reputation rather than on the mere fact that the buyer is software.

The share of genuinely fraudulent activity a control approves, the miss rate. In card and ACH environments it has historically been partially recoverable, since chargeback rights, representment windows and reversal mechanics claw back some value after the fact.

That safety net thins as agent payments settle on rails built for finality. Stablecoin transfers and machine-to-machine settlement complete without a chargeback right, so a false negative is a realized loss at the moment of approval rather than a claim to be worked later. Volume makes it worse, because a single misjudged agent does not commit one fraud, it commits every transaction in its queue at machine speed before anyone notices. The practical consequence is that agent programs cannot be tuned like card programs, where a tolerable miss rate is priced into loss reserves. Controls have to be preventive and pre-authorization, and the evidence of what was checked has to be captured at decision time because there is no recovery process to reconstruct it later.

A red flag is a single observable indicator that, on its own, warrants closer scrutiny rather than proving wrongdoing. Regulators and industry bodies publish red flag sets so that frontline staff and detection rules share a common vocabulary for what deserves a second look.

The agentic set barely exists yet. Established flags lean on human tells such as nervous behavior, structuring just under reporting thresholds, or a customer who cannot explain their own transaction, none of which translate cleanly to software. Candidate agentic flags are being written now from operational experience rather than from guidance, and they look different, an agent transacting outside the merchant categories in its mandate, a delegation chain that cannot be resolved to a named principal, a wallet whose funding source changed mid-session, an agent identity presenting from infrastructure inconsistent with its issuer. Operators should document their own flags as they find them, because published catalogs will lag actual agent abuse by years.

A typology documents how a specific crime is actually executed, the sequence of steps, the roles involved, the instruments used and the way value moves. Financial intelligence units and industry groups publish them so institutions can build detection against real method rather than against abstract risk categories.

For agentic abuse the typology library is close to empty, which is the single largest gap in the discipline right now. What exists is fragmentary and largely vendor-observed, covering things like prompt injection redirecting an agent's payment instruction, credential theft producing an agent takeover that transacts inside a valid mandate, synthetic agent identities built to accumulate merchant trust before a bust-out, and layering through high-frequency machine payments too small to trip legacy thresholds. Filling the gap needs cross-institution sharing of confirmed cases in a shared technique vocabulary, which is why mapping into a common framework matters more here than in mature crime areas where everyone already knows the playbook.

Transaction monitoring is the ongoing, generally post-execution review of customer activity against rules, thresholds and behavioral baselines, producing alerts that feed investigation and regulatory reporting. It is the operational core of an AML program and is usually built as scheduled batch scoring over completed transactions.

The batch model assumed activity arrived at a pace humans generate and that reviewing yesterday's payments today was adequate. Continuous machine flow defeats both assumptions, since an agent can complete an entire abuse sequence between two batch windows and the loss is final before the alert is written. Monitoring also has to attach to the right subject, which is no longer just the accountholder but the agent acting for them, the mandate under which it acted, and the delegation chain connecting the two. Institutions running agent-facing products should expect to hold agent-level activity profiles alongside customer-level ones, and to justify to examiners why their monitoring cadence matches the settlement speed of the rail.

Real-time monitoring evaluates a transaction while it is still in flight, before authorization or settlement completes, so the decision can actually stop the payment. It differs from transaction monitoring mainly in when it runs and what it is allowed to do, which is intervene rather than report.

For agent payments this shifts from an advantage to a requirement. Where settlement is final, an in-flight decision is the only decision that exists, so the control has to sit in the authorization path with a hard latency budget rather than in an analytics pipeline downstream. That budget constrains what can be checked, which favors deterministic verification of identity, mandate and scope over heavy behavioral scoring that needs history the agent does not have. It also forces the verdict to be an action rather than a score, one of allow, step up, review or block, and it forces the system to record what it saw at decision time, since nothing about that moment can be reconstructed afterward.

Activity is suspicious, in the regulatory sense, when it has no apparent lawful purpose, has no reasonable explanation given what the institution knows about the customer, or is inconsistent with that customer's established profile. The standard is deliberately judgmental and rests on the known-customer profile as its reference point.

Agents arrive without one. A newly instantiated agent has no transaction history, no stated occupation, no source of funds narrative and no expected activity pattern to be inconsistent with, so the classic test has nothing to compare against. Institutions are filling the gap by importing the principal's profile and asking whether the agent's activity is consistent with what the human or business behind it would plausibly do, which works only when the delegation chain resolves to a real accountable party. The suspicion question for agents therefore reduces to authority and provenance, whether the agent can demonstrate who authorized it, for what, and within which limits, rather than whether its behavior looks odd.

A SAR is the confidential regulatory filing an institution submits when it identifies activity it suspects involves illicit funds or is designed to evade requirements. Filing carries deadlines, safe harbor protection and strict prohibitions on tipping off the subject.

The forms assume a subject that is a natural person or a legal entity, with fields for identification documents, dates of birth, addresses and registration numbers. An autonomous agent is neither, and naming one presents an unresolved practical problem, whether to file against the agent's principal, the developer or platform that deployed it, the operator of the wallet, or some combination, and how to describe the agent itself in narrative so the filing is useful to investigators. No supervisor has published settled guidance on this, so current practice is institutions naming the human or corporate principal and describing the agent in the narrative field. Resolution has to come from financial intelligence units updating filing schemas, not from filers inventing conventions in isolation.

An audit trail is the time-stamped, sequential record of what happened in a system, who or what did it, and when. Fraud, AML and dispute functions all depend on it, and its value in an investigation rests entirely on whether the record can be trusted to be complete and unaltered.

Ordinary application logs do not clear that bar once the parties do not trust each other. An unsigned log is an assertion by whoever wrote it, editable by its owner and worth nothing against a counterparty who disputes it, which is exactly the position a merchant and an agent developer occupy when a payment goes bad. Agent transactions cross organizational boundaries by default, so the record has to be portable and independently verifiable rather than internal. For that reason the useful artifact is not called an audit trail here. What matters is a signed record produced at decision time, carrying the agent identity, the mandate, the verdict and the evidence that supported it, so a party who was never in the transaction can still confirm what was checked.

MITRE F3, the Fight Fraud Framework, is a community framework that catalogs financial fraud tactics and techniques in a structured labeling vocabulary, following the pattern MITRE established for adversary behavior in cybersecurity. Its purpose is to let institutions describe how a fraud was carried out in terms other institutions can consume, rather than in internal case-note prose that travels nowhere.

The value for agentic fraud is that the technique catalog gives new abuse patterns somewhere to live before formal typologies exist. A verification record produced at decision time can be interpreted as an F3 sighting, an observed instance of a named technique indicator, which turns individual verdicts into shared intelligence about how agents are actually being abused across merchants and platforms. That mapping only works if the underlying record is signed and portable, since a sighting contributed by an untrusted party is just a claim. Coverage of agent-specific techniques is still thin and will be built from contributed sightings.

Threat simulation is the deliberate exercise of realistic attack scenarios against your own production controls to find out what they actually catch, as distinct from a code-level penetration test or a paper tabletop. Mature fraud teams run it continuously and score controls on detection and response rather than on design intent.

For agent-facing systems the scenario set has to cover four distinct surfaces, and most teams have controls for only the first. Identity abuse presents a forged or borrowed agent credential, while mandate abuse uses a validly identified agent to transact outside the authority it was granted. Runtime abuse redirects a legitimate agent mid-task through prompt injection or tool poisoning, and wallet abuse substitutes the funding source or beneficiary after authorization is given. Each of the four fails in a different place, so a control that catches one says nothing about the others. Exercising all of them against live decisioning is the only reliable way to learn whether the verdict path degrades safely, and the evidence trail each run produces should be inspected as closely as the verdicts themselves.

In card payments, a liability shift is a rule that moves responsibility for a fraudulent or disputed transaction from one party to another when a defined condition is met, most familiarly where cardholder authentication moves chargeback exposure from the merchant to the issuer. It is a creature of network rules and contract rather than a natural allocation of fault, and it functions only because the triggering condition is agreed in advance.

No comparable rule exists for a payment initiated by an autonomous agent. When an agent buys the wrong item, buys it twice, or is manipulated into buying at all, the loss can plausibly land on the consumer, the merchant, the issuer, the agent developer or the platform that ran the agent, and none of those parties has agreed to hold it. Card networks, regulators and courts will settle the allocation eventually, and until they do merchants price the uncertainty by declining agent traffic or treating it as elevated risk. Operators should retain evidence that the agent's authority was checked before the payment, because whichever way the rule lands, the party holding proof of authorization argues from the stronger position.

Describes a transaction that clears every credential and consent check yet falls outside what the principal actually wanted. The credential is valid and the session is legitimate, and the purchase is still not the one the account holder would have approved had they been asked.

Classic fraud taxonomies split cleanly into authorized and unauthorized, and that split carries the loss allocation with it. Agents break the split because consent is delegated once, at the moment a mandate is granted, then exercised many times without further human contact. A compromised or misdirected agent transacts with real authority, so the payment is authorized in the sense that matters to an issuer and unauthorized in the sense that matters to the customer. The control has to move from credential validation to intent validation, which means recording the scope the principal granted and testing each transaction against that scope rather than against the credential alone. Firms that cannot produce the granted scope will lose these arguments regardless of what their authentication logs show.

A payment made from an account without the account holder's authorization, covering stolen credentials, account takeover and third party initiated transfers. Most consumer protection regimes treat it differently from authorized fraud, generally placing more of the loss on the institution rather than the customer.

Agent consent makes the category boundary unstable. A customer who granted an agent a broad spending mandate has authorized something, but they have not necessarily authorized the specific purchase the agent made, and disputes will arrive precisely in that gap. Institutions should expect customers to characterize agent purchases they regret as unauthorized, and should expect the classification to decide who pays. Detection also degrades, because the behavioral markers of account takeover, including unfamiliar devices, odd hours and rapid sequencing, describe normal agent activity. The practical defense is a durable record of what the principal delegated plus evidence that the agent stayed inside it, since without both the institution has nothing to rebut the claim with.

A cardholder's formal challenge to a transaction, raised with the issuer, which opens a structured evidence exchange with the merchant under network rules. Reason codes and evidence standards were written around human intent, asking whether the cardholder made the purchase, received what was promised, and agreed to the terms.

Agent-initiated purchases fit those questions badly. The cardholder did not click anything, so a claim that they did not make the purchase is literally true even where they authorized the agent that did. A merchant defending such a dispute needs to show delegation rather than presence, which current representment templates do not ask for and issuer analysts are not trained to weigh. Until networks publish agent-aware reason codes and evidence requirements, the merchant's only durable position is a verifiable record produced at transaction time showing which agent acted, under whose authority, and within what limits. Operators should be capturing that record now, since the rules will be written against whatever evidence early adopters can actually produce.

The mechanism by which an issuer reverses a settled card payment and pulls funds back from the acquirer and merchant, following a cardholder dispute or a rules violation. Merchants carry the reversed amount plus a fee, and sustained chargeback ratios pull them into network monitoring programs with escalating penalties.

Agent purchases hand cardholders a plausible denial by default. Because the customer genuinely was not at the keyboard, first-party misuse becomes hard to separate from real agent malfunction, and the merchant absorbs the ambiguity. Expect claim volumes to rise wherever agents buy without per-transaction human confirmation, and expect ratio-based monitoring to penalize the merchants who adopt agent checkout earliest, which is a perverse outcome nobody designed. The countermeasure is evidentiary rather than behavioral, since a merchant cannot make the cardholder appear at checkout but can hold a signed record showing the agent was verified and acting inside an authorization the cardholder issued.

A cryptographically signed record, generated at the time of an agent transaction, that a merchant can submit when a dispute arrives. It attests that a specific agent was identified, that its authority traced to a named principal, and that the purchase fell inside the scope that principal had granted.

Ordinary representment evidence describes a human session, using device fingerprints, IP history, delivery confirmation and prior account behavior. None of that addresses the question an agent dispute actually raises, which is whether the agent had authority to buy. A record signed by an independent verifier at authorization time cannot be reconstructed afterward by either side, which is what makes it worth anything to an arbiter. Operators should capture it inline before the payment clears and retain it for the full dispute window, because evidence assembled after a chargeback notice arrives is weak and evidence the merchant could have fabricated is weaker. The value is not the cryptography, it is that the record existed before the loss did.

The US rule implementing the Electronic Fund Transfer Act, governing consumer electronic transfers and setting error resolution rights, investigation timelines and liability limits for unauthorized transfers from consumer accounts. Its central factual question is whether the consumer authorized the transfer.

Whether a transfer initiated by an agent the consumer configured counts as authorized is untested. Nothing in the rule contemplates a standing delegation exercised autonomously and repeatedly, and no US regulator has published an interpretation covering that fact pattern, so institutions are applying existing definitions to circumstances the drafters did not have in view. The exposure runs one way, since if agent-initiated transfers are treated as unauthorized whenever the consumer disclaims them, the institution absorbs the loss and the agent developer does not. Firms offering agent access to consumer accounts should document the consumer's delegation with the same rigor they apply to authentication, and should assume that documentation will be the contested item in any eventual examination or litigation.

Funds an institution returns to a consumer's account while it investigates a claimed error or unauthorized transfer, required in US consumer accounts when an investigation extends beyond a short initial period. The credit is reversible if the claim fails, though recovery in practice is imperfect.

Agents turn this into an abuse surface with scale behind it. A dispute that requires human effort to file is naturally rate limited, and an agent filing claims programmatically is not, so an institution can face coordinated claim volume across many accounts in a compressed window. Genuine agent-caused errors arrive in bursts too, since one misconfigured mandate produces many bad payments rather than one. Fraud teams should monitor claim rates per agent and per principal rather than only per account, and should treat a spike in agent-linked claims as a control failure signal to investigate at the source rather than as ordinary dispute noise to be worked case by case.

The foundational US anti money laundering statute, requiring covered financial institutions to keep records, file reports on defined categories of transaction, and maintain programs to detect and report suspicious activity. Much of its machinery keys off transaction size and off the existence of an identified customer.

Agentic payment patterns sit awkwardly against both anchors. Reporting triggers assume value moves in chunks large enough to be worth reporting, while agents transact continuously in small amounts, and identification duties assume a customer who is a person or a legal entity rather than software acting for one. Nothing in the statute exempts agent activity, so the obligations still attach to the institution, but the detection logic built to satisfy them was tuned for a different shape of behavior. Programs should be tested explicitly against high-frequency low-value flows, and against the question of whose identity is actually on file when an agent, not its principal, is the party transacting.

A report US financial institutions must file for cash transactions exceeding the long-standing threshold of more than $10,000 in one business day by or on behalf of the same person, including multiple transactions that aggregate to that amount. It is a bright-line filing obligation rather than a judgment call.

Agent payment flows pass beneath the line by construction. Machine-to-machine settlement runs in fractions of a cent per call, agent spend rarely touches cash at all, and the report that anchors much of the US reporting regime simply never fires. Structuring rules address deliberate splitting by a person, but agent payment design is small by nature rather than by evasive intent, so treating every agent as a structurer is neither accurate nor operable. Detection has to move toward aggregation across an agent identity and its principal over time, which most transaction monitoring stacks cannot do because they aggregate by account and have no concept of the agent as a distinct actor.

The bureau of the US Treasury that administers the Bank Secrecy Act, receives and analyzes the reports filed under it, and issues implementing regulations, advisories and enforcement actions. It also sets the definitions that decide which businesses fall inside the regime at all.

It has not issued guidance specific to autonomous agents that transact. Institutions therefore have no authoritative answer on how to identify an agent, whose customer relationship it belongs to, or how agent activity should be described in a suspicious activity report, while the underlying obligations continue to apply in full. Firms are making interpretive choices they will later have to defend to an examiner. Advisories are the likely vehicle when a position does arrive, and typologies tend to follow observed abuse rather than anticipate it, so institutions seeing agent-linked laundering patterns now are assembling the evidence base any future guidance will rest on. Documenting each interpretive decision and its reasoning is the practical hedge.

Global standards for anti money laundering and counter terrorist financing originate with this intergovernmental body, expressed as the Recommendations and enforced indirectly through mutual evaluation of member jurisdictions. National regimes generally follow its lead rather than the reverse.

The Recommendations are drafted to be technology neutral, and no agent-specific standard exists today. That matters because harmonized expectations for identifying and monitoring autonomous transacting software will most plausibly originate here before they appear in national rulebooks, in the way that standards for virtual asset service providers did. Firms building agent controls now are choosing definitions a future standard may or may not ratify, and a mismatch is expensive to unwind. The defensible posture is to align agent identification and record keeping with existing customer due diligence concepts, so that whatever taxonomy eventually arrives can be mapped onto records already held rather than reconstructed retrospectively from logs that were never designed for the purpose.

US federal legislation establishing a framework for payment stablecoins, addressing who may issue them and the supervisory regime issuers fall under. Implementing rulemaking by the relevant federal agencies has been proceeding since enactment, so operational detail continues to develop and firms should check the current rule text rather than rely on summaries.

Its relevance to agents is indirect and substantial. Agent-to-agent and machine-to-machine payments gravitate toward stablecoin rails because settlement is fast and per-transaction cost is low enough to support very small payments, and a regulated issuance framework converts those rails from an unsupervised experiment into supervised payment infrastructure. That pulls agent payment flows inside a perimeter where compliance expectations, record keeping and supervisory attention apply. Firms building agent payment products on stablecoins should plan for issuer-side and intermediary-side obligations to tighten over time, and should not assume a rail chosen for low friction stays outside the scope of financial regulation.

The European directive governing payment services, best known for requiring strong customer authentication on electronic payments and for opening bank account access to authorized third party providers. Its authentication model rests on challenging the customer in the moment with factors they possess, know or are.

An agent transacting on a standing instruction is not a customer who can be challenged. Exemptions exist for certain recurring and low-value payments, and agent flows will be pushed toward them because the alternative is a challenge with nobody present to answer it, which relocates risk onto whichever party grants the exemption. The access rules also assume third party access is performed by an authorized provider, whereas an agent may be software a consumer installed with no authorized party anywhere in the chain. European supervisors have not settled how agent-initiated payments should be authenticated, so any approach in production today should be treated as provisional and built to be changed.

Crypto-asset issuance and service provision in the European Union are governed by this framework, which covers asset-referenced and e-money tokens alongside authorization and conduct requirements for crypto-asset service providers. It regulates the assets and the intermediaries handling them.

Agents that settle in tokens inside that perimeter are transacting under regulation without being regulated subjects themselves. Obligations attach to issuers and service providers, so the compliance burden created by agent activity falls on the wallet operator, exchange or custodian in the flow rather than on the agent or the developer who deployed it. Those providers should expect supervisory questions about who controls a wallet that transacts autonomously and how the beneficial owner behind it was verified. Nothing in the framework settles whether an agent-controlled wallet is a customer wallet or an intermediated one, and that classification determines which controls apply and who has to run them.

The European Union's horizontal regulation of AI systems, which sorts systems into risk tiers with obligations scaled to the tier, prohibits a narrow set of practices outright, and imposes transparency duties including disclosure in defined circumstances that a person is interacting with an AI system. Its provisions phase in across several stages rather than applying all at once.

For agents that transact, the immediate relevance is disclosure and accountability rather than payment rules, since the regulation governs AI systems and not payments. A merchant facing an autonomous buyer has an obvious interest in knowing it is one, and transparency duties push in that direction without resolving the commercial question of whether the merchant may refuse to deal with it. Providers and deployers of agent systems used in financial contexts should map their classification and documentation duties early, as those are heavier than the transparency headline suggests. How the regime interacts with payment supervision and financial crime rules remains unworked.

Shorthand for the operational convergence of fraud and anti money laundering functions, driven by shared data, shared detection infrastructure and criminal behavior that ignores the internal boundary. Institutions that merge them are trying to get one view of a customer's risk instead of two partial views that never reconcile.

Agent risk lands directly on the seam. An agent that has been taken over is a fraud problem, an agent used to fragment value across thousands of small payments is a laundering problem, and much the same signal set separates the two, so an institution that keeps the functions apart sees half the picture twice. In practice agent activity often belongs to neither team, because fraud owns the transaction moment and AML owns the customer, and an agent is a third object that is neither. Someone has to be given the agent as a monitored subject in its own right, with a mandate spanning both domains.

The practice of exiting or refusing an entire customer category rather than assessing and managing risk within it, historically applied to correspondent banking relationships, money service businesses and whole jurisdictions. Supervisors have criticized it repeatedly as inconsistent with risk-based supervision, since it displaces activity rather than reducing it.

Blocking all agent traffic is the same move wearing a different label. Merchants and institutions that cannot distinguish a legitimate agent from a hostile one default to denying the category, which is defensible while volumes are small and stops being defensible once agent commerce carries real legitimate value. The displaced traffic does not disappear, it routes to counterparties with weaker controls or disguises itself as human traffic through a browser, and the second outcome is worse for detection than the activity being visible. The condition for managing rather than exiting is being able to tell agents apart, which requires the agent to have an identity and a checkable record of its authority.

Supervisors expect controls to be proportionate to assessed risk, concentrating resources where exposure is greatest and sparing low-risk relationships the friction applied to high-risk ones. Proportionality is meaningless without a defensible taxonomy, since there must be categories to be proportionate about.

No agreed taxonomy of agent risk exists yet. There is no accepted method for scoring whether one agent presents more risk than another, no standard factor set comparable to jurisdiction, product and channel, and no shared vocabulary for describing delegated authority. Firms are therefore operating a risk-based approach without a risk model, which collapses in practice into treating every agent as high risk or every agent as low. The factors that will matter are already visible in operations, including who the principal is, how the agent was issued and verified, how tightly its authority is scoped, and how it has behaved across counterparties over time. Build and document that model now rather than wait for one to be published.

The level and type of risk a board states the institution is willing to accept in pursuit of its objectives, expressed through limits and thresholds that cascade down into operating policy. It is a governance artifact whose usefulness depends entirely on being specific enough to constrain a real decision.

Few boards have stated an appetite for autonomous spend. That leaves engineering and product teams setting de facto limits through implementation choices, including how much an agent may spend without confirmation, which counterparties it may transact with, and what happens when it exceeds its mandate. Those are appetite decisions being taken several levels below where appetite is supposed to be set, by people who were not asked to take them. A workable statement needs quantities the business can be held to, such as maximum autonomous transaction value, aggregate exposure per principal, tolerance for agent-linked dispute volume, and the conditions under which a human must be brought back into the loop.

Financial institutions organize control ownership into three lines, with the business owning and managing its risk in the first, risk and compliance functions setting policy and providing challenge in the second, and internal audit giving independent assurance in the third. The structure works only where ownership at each line is unambiguous.

Ownership of agent risk has not been assigned in most institutions. Agents are usually built by engineering as a product capability, which puts them in the first line by default, while the exposure they create is fraud, credit and financial crime risk that the second line is accountable for and has often not been asked to review. Internal audit has no established program for testing whether an agent stayed inside its mandate, because no such program has been written anywhere. Until an owner is named, agent deployments pass through governance as technology changes rather than as new risk exposures, and the first proof of the gap will be a loss with no control mapped against it.