It combines agent context, rules, risk and human confirmation to make visible a decision that otherwise stays scattered across systems.
Guided pilots with visible state: what is current, what is conditional and what remains planned.
An agent can pass identity verification and still run an action the merchant would never have approved: an out-of-range discount, an order that drains a promotion, a retry that duplicates a charge. Control combines agent context, economic rules, risk signals and human steps to decide how an operation proceeds before the cost appears.
A technical identifier does not explain who operates the agent, for what purpose or under what mandate. Receive identity and authorisation signals instead of treating every request as equivalent.
A basis for a reasoned decision, not an assumption.Amount, frequency, discount or purchase pattern may require a different outcome than a standard purchase. Without explicit rules every valid request is treated the same, and that is where abuse gets through.
Allow, review or block, explainable per operation.When policy requires it (a high amount, an unusual pattern) the agent waits for explicit confirmation instead of continuing on its own.
Agent autonomy does not replace the merchant.Control is not a black box that approves or rejects. Every step leaves a visible reason, and the merchant defines the cut-off point in advance.
The same mechanism produces a different outcome depending on who looks at it.
Instead of discovering abuse after the charge, you define in advance which condition triggers review or block.
An explained rejection is more useful than a generic error: the agent can replan instead of retrying blind.
Human confirmation is only useful if it arrives with enough context and at a moment when the operation can still be stopped.
Before designing a pilot it helps to know what is operational today and what remains conditional on a pending requirement.
Guided access, not a public API yet
agent verificationAmount, frequency, discount per merchant
POLA combination of signals to flag review
RISKHold until confirmation on supported surfaces
human reviewCut off an agent's access mid-flight
REVWithout a control layer every valid request executes the same, and abuse is discovered at reconciliation. With Control, the condition is evaluated before checkout.
No. It sits before the delegated action executes and uses the signals you already have. It does not replace your risk system, checkout or payment provider.
Policy defines the limit: below a threshold the operation may continue on its own; above it, it waits for confirmation. The merchant sets that threshold, not Trusteed.
No. Access to agent verification is guided during the pilot. A public API with authentication, rate limiting and metrics is a later step, subject to its own pending requirements.
A pilot is scoped to one concrete sensitive operation. The metric (explained decisions, correct reviews or loss avoided) is defined before starting, not at the end.
The next step is one sensitive operation, one policy and one decision metric. We do not present agent verification or risk as an available standalone product until their pending requirements are met.
