Agent Transaction Monitoring
Prerequisite: Security Model
Your fraud detection system flags a transaction as suspicious: a single account submitted 47 purchase orders in 90 seconds, each for a different supplier, each for exactly $4,999 — one dollar below the review threshold. Every rule you built for human behavior fires. But the account belongs to a procurement agent operating within its delegated scope, executing a batch purchase order its principal approved three hours ago. Your fraud team spends 40 minutes investigating a false positive. Meanwhile, a different agent — one that drifted outside its instructions — quietly routes $12,000 to an unrecognized payee, and nobody notices because the transaction looks normal by human standards.
Traditional transaction monitoring assumes human actors. Agents break every assumption it relies on.
The Neither-Human-Nor-Software Problem
Your monitoring system classifies actors into two categories: humans and automated systems. Humans are slow, variable, contextual. Automated systems are fast, deterministic, predictable. Agents are neither.
| Behavior | Human | Automated system | AI agent |
|---|---|---|---|
| Transaction velocity | 1–5/minute | 100–10,000/sec | 10–100/sec, bursty |
| Amount patterns | Variable, round numbers | Exact, repeating | Variable, optimized |
| Timing | Business hours, irregular | 24/7, steady | 24/7, task-driven bursts |
| Payee diversity | Low, repeat payees | Fixed counterparties | High, novel payees |
| Error behavior | Gives up, calls support | Retries deterministically | Retries with variation |
| Scope drift | Gradual, intentional | None (hardcoded) | Subtle, emergent |
An agent that books 200 hotel rooms across 15 cities in 4 minutes looks like a credential-stuffing attack to velocity-based rules. An agent that negotiates prices with three vendors and selects the cheapest looks like account takeover when the “account” suddenly transacts with an unknown merchant. An agent that retries a failed payment with slightly different parameters — adjusting the amount, changing the description — looks like a card testing attack.
Rules calibrated for human cadence produce false positive rates of 40–60% on agent-originated traffic. Rules calibrated for batch automation miss the agent behaviors that actually indicate compromise or drift.
Identifying Agent Traffic
Before you can monitor agent transactions differently, you must know which transactions originate from agents. This requires explicit identification at the protocol level — you cannot infer it from behavior patterns alone.
The Anthropic/Visa/Mastercard Agent Commerce Blueprint specifies that agent-initiated transactions must carry machine-readable metadata identifying the agent, its principal (the human who delegated authority), and the scope of delegation. The x402 protocol extends HTTP with payment negotiation headers that include agent identity claims.
{
"transaction_id": "txn_8f3a2b",
"actor": {
"type": "agent",
"agent_id": "agent_procurement_v3",
"principal_id": "user_4521",
"delegation_scope": "office_supplies",
"max_single_amount": 5000,
"max_daily_amount": 25000,
"allowed_categories": ["5111", "5943", "5944"]
},
"initiated_at": "2026-03-15T14:23:07Z"
}Without this metadata, your monitoring system must guess whether a transaction came from a human or an agent. Guessing produces two failure modes: treating agent traffic as human (false positives overwhelm analysts) or treating human traffic as agent (reduced scrutiny on actual fraud). Both are expensive.
If your payment API does not require agent identification at the protocol level, you cannot build reliable agent-specific monitoring. The metadata must be mandatory for agent-initiated flows, not optional. An agent that can omit its identity will — either through misconfiguration or because a compromised agent strips its own headers.
Delegation-Aware Anomaly Detection
The core monitoring question for human transactions is “does this look like the account holder?” For agent transactions, the question splits into two:
- Is the agent operating within its delegated scope? The principal said “buy office supplies up to $5,000 each.” Is this transaction office supplies? Is it under $5,000?
- Is the agent behaving as designed? Even within scope, is the agent’s pattern consistent with its expected behavior model?
These are independent checks. An agent can be within scope but behaving abnormally (a procurement agent buying office supplies at 3 AM from a new supplier, which is within delegation but outside its behavioral baseline). An agent can also be outside scope but behaving normally (a travel agent that books a hotel as expected but in a city the principal didn’t authorize).
Scope enforcement
Scope enforcement is deterministic. The delegation defines hard constraints — amount limits, category restrictions, approved counterparties, time windows. Every transaction is checked against these constraints before execution.
| Constraint | Check | Response |
|---|---|---|
| Single transaction limit | amount <= max_single_amount |
Reject, notify principal |
| Daily aggregate limit | daily_total + amount <= max_daily_amount |
Reject, notify principal |
| Category restriction | mcc IN allowed_categories |
Reject, notify principal |
| Counterparty allowlist | payee IN approved_payees |
Queue for principal approval |
| Time window | now() BETWEEN valid_from AND valid_until |
Reject, revoke delegation |
| Geography | merchant_country IN allowed_countries |
Queue for principal approval |
Scope enforcement is a gate, not a scoring model. A transaction either passes or it does not. There is no “suspicious but within scope” — scope violations are blocked, not flagged.
Behavioral baseline detection
Behavioral detection is probabilistic. An agent has an expected pattern based on its purpose and history. Deviations from that pattern are scored, not blocked.
Build the baseline from the agent’s first 50–100 successful operations. Track:
- Transaction velocity — mean and standard deviation of transactions per minute, per hour
- Amount distribution — typical range, mean, clustering patterns
- Counterparty entropy — how many unique payees per session, repeat rate
- Retry behavior — retry frequency, parameter mutation between retries
- Session duration — how long the agent operates per activation
A procurement agent that typically processes 10–15 orders over 20 minutes, then suddenly submits 80 orders in 3 minutes, has deviated from its baseline even if every individual order is within scope. The deviation score triggers a review — not a block.
Rate Limiting and Velocity Controls
Agent-specific rate limits operate at three levels: per-transaction, per-session, and per-delegation.
Per-transaction limits are scope enforcement — amount caps, category restrictions. These are hard limits defined in the delegation.
Per-session limits throttle the agent’s activity within a single activation. A procurement agent might be limited to 50 transactions per session, with a mandatory 500ms delay between submissions. These limits prevent a malfunctioning or compromised agent from draining an account in seconds.
rate_limits:
per_session:
max_transactions: 50
min_interval_ms: 500
max_session_duration_minutes: 60
per_day:
max_transactions: 200
max_total_amount: 25000
velocity_alerts:
- trigger: "10 transactions in 60 seconds"
action: "pause_and_notify"
- trigger: "3 transactions to same payee in 5 minutes"
action: "flag_for_review"
- trigger: "amount > 2x historical mean"
action: "require_principal_confirmation"Per-delegation limits cap the agent’s total activity across all sessions. A travel agent delegated $10,000 for a conference trip has a lifetime budget. When the budget is 80% consumed, the principal receives a notification. At 100%, the delegation expires regardless of remaining scope.
The velocity controls must account for legitimate bursts. A procurement agent that finds a sale on office supplies might rationally accelerate its purchasing. The monitoring system should distinguish between velocity that correlates with a plausible optimization (bulk discount, expiring inventory) and velocity that has no rational explanation (buying the same item 50 times).
Spending Velocity and Pattern Deviation
Spending velocity measures not just how fast an agent transacts, but the rate of change in its spending patterns. A sudden shift in any monitored dimension triggers an alert.
| Metric | Normal range | Alert threshold | Action |
|---|---|---|---|
| Transactions/hour | 5–20 | > 50 | Pause, notify principal |
| Unique payees/session | 1–5 | > 15 | Flag for review |
| Average amount change | ± 10% session-over-session | > 50% change | Require confirmation |
| New payee ratio | < 20% of transactions | > 80% new payees | Queue for approval |
| Category concentration | > 80% in primary category | < 50% in primary category | Flag for review |
Pattern deviation detection uses a sliding window. Compare the agent’s behavior in the current window (last 10 minutes, last 50 transactions) against its historical baseline (last 30 days, last 500 transactions). Score the deviation using Population Stability Index (PSI) or Kullback-Leibler divergence across the monitored dimensions.
A PSI score above 0.25 on any dimension triggers a review. Above 0.5, the agent is paused and the principal is notified. These thresholds require calibration per agent type — a procurement agent has different normal variance than a travel booking agent.
Distinguishing Drift from Compromise
The hardest monitoring problem for agents: an agent that drifts outside its instructions looks different from a compromised agent, but both produce transactions that deviate from the baseline.
Drift is gradual. The agent’s optimization objective leads it to explore adjacent actions. A procurement agent finds that buying from a different supplier saves 8%, so it starts routing orders there. The transactions are reasonable, the amounts are normal, but the counterparty set has shifted. Drift is the agent doing something its principal didn’t explicitly authorize but might approve if asked.
Compromise is abrupt or deliberate. An attacker gains control of the agent’s credentials or manipulates its instructions. The transactions serve the attacker’s objective, not the principal’s. Compromise often manifests as: transactions to previously unseen payees at unusual amounts, rapid exfiltration patterns (many small transactions to multiple destinations), or transactions that precisely avoid monitoring thresholds.
| Signal | Drift | Compromise |
|---|---|---|
| Onset | Gradual over sessions | Sudden within a session |
| Amount patterns | Consistent with task | Anomalous or structured |
| Payee changes | Nearby alternatives | Unrelated entities |
| Category alignment | Adjacent categories | Unrelated categories |
| Time patterns | Consistent | Shifted or continuous |
| Retry behavior | Normal | Aggressive, parameter-mutating |
The monitoring response differs. Drift warrants a principal notification: “Your agent has started using new suppliers — approve or restrict?” Compromise warrants an immediate pause: “Unusual activity detected — agent suspended pending review.”
The Feedback Loop
Agent monitoring produces a feedback loop that human transaction monitoring does not. When you flag an agent’s transaction and the principal confirms it was authorized, that confirmation updates the agent’s behavioral baseline. The monitoring system learns what the principal actually wants, not just what the delegation document specified.
This creates a risk. If a compromised agent’s transactions are mistakenly confirmed by a principal who doesn’t review carefully — clicking “approve” on a batch notification without reading each line — the monitoring system learns to treat compromise patterns as normal. The confirmation flow must force principal engagement: show the specific deviation, require explicit acknowledgment of the new pattern, and maintain an undo window.
Over time, the monitoring system builds a per-agent, per-principal behavioral model that is more precise than the static delegation scope. The delegation defines the boundaries. The behavioral model describes the expected path within those boundaries. Deviations from the path trigger review; violations of the boundaries trigger blocks. Both layers are necessary — the behavioral model alone cannot catch a compromise that operates within scope, and the scope alone cannot catch drift that stays within boundaries but deviates from intent.