Shadow Mode for AI agent spend

Why start in shadow

The first version of any spend policy is wrong in both directions. It blocks things the agent legitimately needed, and it lets through things nobody would have approved. Switch it on against a live agent and you find out which is which the expensive way: a stalled campaign, a failed job, an angry client — or a charge you only notice at the end of the month.

Shadow Mode removes that trade-off. The agent keeps working exactly as before. Every spend it makes is decided against its authority and recorded — what would have been allowed, capped, sent to a person or blocked, and why. Nothing is blocked. You tune the authority on real traffic, and you switch it on only when the evidence says it is right.

What Shadow Mode does

• Every spend is decided. The same checks as in Enforce run on every request: identity, authority version, currency, merchant, category, amounts, velocity, budgets and — where a purpose is set — a purpose assessment.
• Nothing is blocked. The response always carries effective_decision: ALLOW. The verdict Neltava would have given is in decision, next to it.
• Budgets are simulated honestly. Shadow spends are counted on their own ledger, exactly as Enforce would count them, so “would have exceeded the monthly budget” means what it says — and never touches an enforced budget.
• People can weigh in. Reviewers can say what they would have decided on would-review spends, and label whether a spend served the purpose. Those labels are the ground truth the purpose assessment is measured against.

Connect an agent

Connecting is one call right before the agent pays. Your payment flow doesn’t change, and in Shadow Mode your agent proceeds whatever the answer. Create an agent and its key in the console, then use whichever fits your stack.

MCP — Claude Code, Cursor, any MCP client

No code: the agent gets an authorize_spend tool and is told to ask before any purchase.

claude mcp add --transport http neltava https://api.neltava.com/mcp \
  --header "Authorization: Bearer $NELTAVA_AGENT_KEY" \
  --header "X-Neltava-Agent: growth-agent"

TypeScript

import { Neltava } from "neltava";

const neltava = new Neltava(); // NELTAVA_AGENT_KEY

const d = await neltava.authorize({
  task: "Q4 pipeline: enterprise developer leads",
  action: {
    merchant: "Platform Weekly",
    amount: 90.00,
    currency: "USD",
    description: "Sponsored slot reaching platform engineers at enterprise companies",
  },
});

if (d.proceed) {
  // pay d.amount — in Enforce, through your payment adapter with d.capability
}

HTTP, from any language

curl -X POST https://api.neltava.com/v1/decisions \
  -H "x-api-key: $NELTAVA_AGENT_KEY" \
  -H "idempotency-key: run-7-step-3" \
  -H "content-type: application/json" \
  -d '{
    "task": "Q4 pipeline: enterprise developer leads",
    "action": {
      "type": "purchase",
      "merchant": "Platform Weekly",
      "amount_minor": 9000,
      "currency": "USD",
      "description": "Sponsored slot reaching platform engineers at enterprise companies"
    }
  }'

{
  "decision_id": "dec_7f3c…",
  "decision": "ALLOW",
  "effective_decision": "ALLOW",
  "reason_code": "WITHIN_AUTHORITY",
  "requested_amount_minor": 9000,
  "authorized_amount_minor": 9000,
  "currency": "USD",
  "mode": "SHADOW",
  "explanation": "Allowed: 90.00 USD at Platform Weekly is within growth-agent's authority."
}

The Shadow report

After a few days of traffic, the Shadow report answers the questions you would otherwise guess at:

• What would have been blocked — by which rule, for how much. Only deterministic rules count here; a purpose assessment is never counted as a prevented spend.
• What would have gone to a person — and why: a limit, a threshold, or a purpose doubt.
• What the purpose assessment flagged, next to what your reviewers said about the same spends.
• Where the authority is wrong — rules that would have stopped legitimate work, and gaps no rule covered.

That last point is the one teams use most. Before changing an authority, you can replay the agent’s recorded decisions against the proposed version and see what it would have changed — without writing anything, and without touching the live authority.

Readiness: criteria, not a score

“Are we ready to enforce?” deserves a better answer than a percentage. The report checks explicit, deterministic criteria for each agent, and shows which are met:

The purpose criteria apply when purpose evaluation is on. An agent moves through three stages — connect, observe, prove — and is ready for Enforce only when every criterion is met.

Switching to Enforce

Enforce is switched on per agent, by a person, by typing the agent’s name. If the criteria aren’t all met, the console says so and asks for an explicit acknowledgement. You can return an agent to Shadow Mode at any time.

In Enforce, the same decisions take effect:

• a blocked spend is refused, and a would-review spend waits for a person in the review queue;
• an allowed spend carries a single-use capability bound to its payee, amount and currency. Your payment service consumes it with a payment-adapter key before it pays — a second use, a higher amount or a different payee is refused.

When you don’t need it