The agent is not the control
Teams that let an AI agent prepare payments usually start by telling the agent what it may do: stay under a limit, pay only known vendors, ask a human when unsure. Those instructions shape behavior. They are not a control, because the thing being controlled is also the thing deciding whether the rule applies.
A control has to sit outside the agent, in the path the payment takes. The agent proposes a transfer. Something else decides whether that exact transfer is sent, and that something keeps working when the agent is wrong, confused, or manipulated.
What the check should look at
The check does not need to understand why the agent wants to pay. It needs the facts of the proposed payment and the policy that applies to them. A useful first policy is short.
- Authority: is this proposer allowed to move money at all, or only to read and report?
- Destination: has this account been paid before, is it new, or is it on a restricted list?
- Amount against a hard ceiling that no automated payment may exceed.
- Amount against a lower threshold above which a new destination needs a person.
- Currency and any other field your processor treats as binding.
- That the request being sent is byte for byte the request that was evaluated.
Three outcomes, not two
Allow and deny are not enough. Most real payments that worry a finance team are not clearly wrong; they are unusual. A third outcome, escalate, holds the payment and routes it to a reviewer who signs in, sees what was proposed and why it was held, and approves or rejects it.
Two details matter. The reviewer should not be the party that proposed the payment, and an approved payment should be checked against policy again before it runs, so an approval cannot be used to push through something the policy refuses outright. In StreamKernel's demo policy, for example, a transfer above a ceiling is refused, and a smaller one to an unfamiliar account waits for a reviewer. Those limits are synthetic; yours replace them.
Write the record before the money moves
If the only record of a payment decision is written afterwards, a failure between the decision and the log leaves nothing to show. The safer order is to write a signed record of the intent first: what was proposed, by whom, which policy version decided, and the outcome. Only then is the request dispatched. A second record states what the processor answered, including the uncomfortable case where the answer never came back.
An idempotency key on the request helps with retries, but it does not make payments exactly-once on its own. Whether a retry can move money twice depends on the processor honouring that key. A good record says plainly when an outcome is uncertain and leaves it to a person to resolve.
What this does not replace, and where StreamKernel is today
A check like this sits in front of your processor; it does not replace the processor's own risk controls, your fraud tooling, or reconciliation. It also does not prove who the agent is. That needs authentication at the edge, which is a separate piece of work.
StreamKernel demonstrates this pattern today on a synthetic payment-transfer flow with a simulated processor: allow, escalate, and deny, with signed intent and result records. It has no connector to a named processor yet, and in the demo the proposer's identity is asserted, not authenticated. The sensible first step is one payment action, with real limits, built as a pilot.