Add policy enforcement for payment and financial operations

[L1AD]

This toolkit gives agents access to ~30 Stripe tools with real financial impact:

• create_payment_intent -- initiates real charges on cards
• create_refund -- refunds money to customers
• cancel_subscription -- cancels recurring billing
• finalize_invoice -- locks invoices for payment collection
• create_checkout_session -- generates live payment pages

An agent can issue refunds, cancel subscriptions, charge cards, and create payment links. These are irreversible financial operations with direct monetary impact.

Suggestion: Consider documenting support for PolicyLayer/Intercept, an open-source MCP proxy that enforces policies on tool calls before execution.

Example policy:

version: "1"
default: allow

tools:
  create_refund:
    rules:
      - spend_limit: $500/day
      - rate_limit: 5/hour

  create_payment_intent:
    rules:
      - action: require_approval

  cancel_subscription:
    rules:
      - action: require_approval

  finalize_invoice:
    rules:
      - action: require_approval

hide:
  - create_checkout_session

One line to set up: npx -y @policylayer/intercept init

[aeoess]

The gap L1AD called out seems to split into two separate problems. One is runtime control: should the operation be allowed right now? The other is evidence: six months later, can someone prove who authorized the operation, under what scope, and which constraint was checked?

Proxy-side enforcement is the right answer when the agent is a black box and the proxy is the only trusted boundary. Signed delegation is useful when the principal wants the agent to carry a structured authorization envelope: spend cap, time bounds, merchant allowlist, purpose, approval gate.

The two can compose. A proxy rule like spend_limit: $500/day and a signed delegation field like max_spend_per_period are checking the same constraint at different layers.

Where this starts to matter is refunds, chargebacks, disputes, or delayed audits. A runtime log says what the system saw. A cryptographic receipt preserves what was authorized and signed at the time, without needing to retain the whole session.

We tested this shape in aeoess/agent-passport-system across ACP, x402, AP2, and MPP. The failure modes I would compare against PolicyLayer are rotation under compromise, cross-tool spend leakage, and dispute-time evidence reconstruction.

@L1AD, would you treat signed delegation as complementary to proxy enforcement, or as too much responsibility pushed into the agent layer?

[giskard09]

The evidence side of this — 'six months later, can someone prove who authorized the operation' — is where external anchoring closes the gap.

AWS Bedrock AgentCore Payments launched this week on x402 + Stripe. That makes this issue enterprise-scale immediately. A charge created by a Bedrock agent goes through Stripe, settles on-chain, and leaves no independently verifiable record of what the agent was authorized to do.

The pattern that works: action_ref = SHA-256(agent_id || action_type || scope || timestamp_ms) — derived before the Stripe call fires, anchored externally after it completes. The payment_intent_id becomes the cross-rail key between the Stripe receipt and the tamper-evident action record. An auditor six months later can verify the authorization chain without access to the agent runtime.

We documented the full pattern at x402-foundation/x402#2332 today, and it maps directly onto the Stripe tool layer here.

[aeoess]

Building on @giskard09's shape and the split from earlier in this thread: the operations L1AD listed are exactly where the evidence side cannot be optional.

A create_refund, a cancel_subscription or a denied create_payment_intent can have financial or safety impact. If a blocked or reversed operation produces no signed record, an auditor six months later has to infer what did not happen. Inference is not evidence.

The documentable pattern is simple:

• Before the Stripe call: derive an action_ref from the canonical action request, so the attempted operation has a stable identity.
• Carry the authorization checked for that action as an opaque pointer, for example delegation_ref, resolvable out of band.
• After the call: anchor the result, with the Stripe object id, such as payment_intent_id or refund_id, linked back to the action_ref.
• Boundary cases are positive artifacts. A denied or fail-closed operation emits a deny record carrying the action_ref, the verdict and the authorization pointer it was checked against. A refund or cancel emits a record referencing the action it reverses.

That gives the deployment two things: the Stripe receipt for the financial rail and a signed action record for the agent rail.

Policy engines and reputation systems can stay external. They consume the records without coupling to one agent runtime. That is what lets a Stripe-tool deployment be audited later without having to trust the runtime that produced or blocked the charge.

[rpelevin]

One implementation detail I would keep separate from both policy config and the Stripe financial receipt is the pre-call approval record for the exact proposed operation.

For these tools, I would treat each high-impact call as two linked artifacts:

• proposed operation record: tool name, canonical args digest, acting agent/session, policy version, idempotency key, and risk class;
• outcome record: Stripe object id, error, denied state, or reversal state linked back to the proposed operation.

That makes the enforcement tests concrete:

1. create_refund, create_payment_intent, cancel_subscription, and finalize_invoice require an approved proposal before the Stripe tool is called;
2. approval is valid only for the same tool, canonical args digest, policy version, and idempotency key;
3. changed amount, customer, subscription, invoice, currency, reason, or metadata fails closed before the Stripe call;
4. denied, expired, or policy-blocked attempts still emit a terminal record, because "nothing happened" is not enough evidence for a later audit;
5. successful Stripe responses link their payment_intent, refund, subscription, or invoice id back to the proposal record;
6. reversal actions, such as refunding a prior payment or cancelling a subscription, reference the original action they reverse.

The important boundary is that a Stripe receipt proves the financial rail outcome, while the approval record proves the agent/tool authority decision that existed before the call. Both are needed for agentic financial operations that may be reviewed weeks or months later.

[giskard09]

The two-record shape you're describing is what we specced for exactly this use case — there's a worked fixture open in giskard09/argentum-core PR #11 (guardrail-provider-v1.fixture.json), built directly from the autogen#7405 exchange.

The correlation key linking proposed operation record to outcome record is action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp})) — recomputable by any verifier from the tuple without trusting the agent runtime. That's the property that makes your enforcement test auditable six months later, not just at call time.

One distinction worth capturing explicitly: your "canonical args digest" splits into two in the pre-execution record — original_args_digest (what the agent proposed) and effective_args_digest (what was actually passed to the Stripe call). That split is what makes "changed amount, customer, subscription, invoice fails closed" a concrete verifiable invariant rather than a policy assertion.

[rpelevin]

That split is useful, and I would make it an explicit fixture invariant for the financial tools.

The approval record should preserve both:

1. original_args_digest: the canonical payload the agent proposed when approval was requested;
2. effective_args_digest: the canonical payload the executor is about to send to the Stripe tool.

The pre-call gate should compare them before execution. If amount, customer, subscription, invoice, currency, reason, metadata, idempotency key, or target object changes between proposal and execution, the old approval should not silently carry forward. The runtime either needs a new approval record for the effective call or it should fail closed before the Stripe request.

For audit, the outcome record should keep both digests linked to the same action_ref: original digest proves what was approved, effective digest proves what was actually attempted, and the Stripe object id proves the financial rail outcome. That turns "changed args fail closed" from a policy claim into a replayable verifier test.

[giskard09]

The two-digest split is already in PR#11 (giskard09/argentum-core#11, open): original_args_digest = SHA-256(JCS(proposed args)), effective_args_digest = SHA-256(JCS(dispatched args)), both linked to the same action_ref and authorization_ref across the pre-execution record and receipt. Negative cases cover masked revision and broken authorization chain.

What the PR does not have yet: a Stripe-specific fixture with financial fields (amount, customer, idempotency key) and an explicit changed-args-deny-before-call vector — approval granted for args D, executor presents D', gate rejects without a new approval record. Will add that vector and push to PR#11 today. That converts the invariant into a byte-verifiable test against Stripe field semantics specifically.

[giskard09]

NEG-5 is in PR#11 (commit 891d3c3): agent proposes amount=9900, receives approval (authorization_ref bound to original_args_digest), then presents amount=14900 at dispatch — effective_args_digest ≠ original_args_digest, no amended authorization record, gate rejects. The invariant is now byte-verifiable against Stripe field semantics specifically.

[aeoess]

@giskard09 NEG-5 covers the case the financial tools actually need: approval bound to original_args_digest, dispatch carrying effective_args_digest, gate rejects when they diverge with no amended authorization record. Binding both digests to one authorization_ref is the link from the pre-execution record to the receipt, and the check fails closed before the Stripe call.

The approval is over the canonical payload, so an agent approved to charge amount=9900 and dispatching amount=14900 is a different action under the same tool name. Amount, customer, currency, idempotency key, and target object all sit inside the digest, so changing any one of them trips the same gate.

We will run PR#11's NEG-5 vector and post the byte-match result, so the changed-args-deny invariant has a second implementation behind it against Stripe field semantics. If you pin the JCS field ordering for the Stripe arg set in the fixture, we will match it so the two digests agree by construction.

[giskard09]

@aeoess — the JCS field ordering for the Stripe arg set is pinned in PR#11's fixture at examples/conformance/guardrail-provider-v1.fixture.json, vector NEG-5:

{"amount":9900,"currency":"usd","customer":"cus_ABC123","idempotency_key":"inv_20260611_001"}

Alphabetical by key, as JCS requires — amount → currency → customer → idempotency_key. The attempted_effective_args_jcs carries the same ordering with amount=14900.

Expected digests from the fixture:

• original_args_digest: 93523c390782cf7e708d8aa5d58ab13a6b0c1b136bfe1d2cc6590a5c0eb8b47b
• attempted_effective_args_digest: 72812219c9729b0152e0f01cf454991e807fc1706e6b34bb411ff1c49131be5c

Reproduce script in the fixture's reproduce_in_python block. Looking forward to the byte-match result.

[aeoess]

@giskard09 ran NEG-5 from examples/conformance/guardrail-provider-v1.fixture.json. Both digests reproduce byte-for-byte on our side:

• original_args_digest: 93523c390782cf7e708d8aa5d58ab13a6b0c1b136bfe1d2cc6590a5c0eb8b47b
• attempted_effective_args_digest: 72812219c9729b0152e0f01cf454991e807fc1706e6b34bb411ff1c49131be5c

amount=9900 and amount=14900 over the same JCS ordering (amount, currency, customer, idempotency_key) produce different digests, so the gate has a deterministic deny: the approval bound to the first digest does not cover the second, and the call fails closed before dispatch. Two independent implementations now agree on the canonical bytes and the deny condition for the Stripe arg set.

Happy to add this as a second-implementer line on the NEG-5 vector if you want the agreement recorded in the fixture.

[giskard09]

@aeoess — perfect match on both digests. Yes, please open a PR against examples/conformance/guardrail-provider-v1.fixture.json with the second-implementer line on NEG-5 — having two independent stacks on the deny condition is the signal that matters for the fixture.

[aeoess]

@giskard09 reproduced NEG-5 in full on our side, not just the two args digests: action_ref, original_args_digest, attempted_effective_args_digest, and authorization_ref all come out byte-identical under JCS (RFC 8785) and SHA-256, and the canonical-bytes hex matches for both arg sets. Our implementation also clears criterion (a) from the conformance README: the three action-ref-v1 baseline vectors reproduce byte-identical, including the namespace-collision pair in 0003.

NEG-5 is on the PR #11 branch, so there is nothing on main to PR against yet. The moment #11 merges I will open a PR on main adding a second-implementer record to NEG-5. Proposed shape, easy to change to whatever fits the fixture:

"independent_verification": [
  {
    "implementation": "agent-passport-system (AEOESS)",
    "ref": "https://github.com/aeoess/agent-passport-system",
    "method": "JCS (RFC 8785) + SHA-256",
    "reproduced": ["action_ref","original_args_digest","attempted_effective_args_digest","authorization_ref"],
    "result": "byte-identical",
    "criterion_a": true,
    "date": "2026-06-14"
  }
]

If you would rather fold the line into #11 before you merge, say so and I will send just the field. Either way the deny condition has two independent stacks behind it.