Use cases
High-responsibility actions from outside your trust domain
First Instinct starts with five frozen scenarios where an external AI agent or automation initiates an action a receiving organisation is accountable for. The first release is the external refund request.
First release
External refund request
An external agent asks a merchant to issue a refund it may not be authorised to request.
| Who initiates the request? | An external AI agent acting for a buyer or a third-party service. |
|---|---|
| Which trust domain controls the agent? | The requesting platform or agent runtime, outside the receiver's control. |
| What evidence is presented? | Order reference, prior conversation, a claimed delegation, buyer identity signals. |
| Which fact is not independently verified? | Whether the agent's sponsor is authorised to request this refund, at this amount, on this order. |
| Which receiver team owns the loss? | Payments, disputes and merchant operations — they carry the loss or chargeback. |
| Which decision would First Instinct produce? | require-human-approval when sponsor or mandate scope is unverified; allow only when policy thresholds are met; indeterminate when required evidence is missing. |
| Can the Target issue a receipt? | Yes — the merchant's refund workflow issues accepted_for_processing, then completed, failed or reversed. |
| Can the implementation be reused for the next customer? | Yes — the refund evaluation profile is reused per merchant with local policy. |
Scenario 02
Payout destination change
An external agent tries to change where a seller's money is paid out.
| Who initiates the request? | An external agent or automation acting for a seller or payee. |
|---|---|
| Which trust domain controls the agent? | The seller's own tooling or a marketplace agent, outside the receiver's control. |
| What evidence is presented? | Account session, the change request, device and network signals, an optional carrier signal. |
| Which fact is not independently verified? | Whether the party controlling the agent is authorised to move the payout destination. |
| Which receiver team owns the loss? | Risk, treasury and marketplace payouts. |
| Which decision would First Instinct produce? | deny or require-human-approval on a weak binding; indeterminate without corroborating evidence. |
| Can the Target issue a receipt? | Yes — the payout system issues accepted_for_processing then completed or failed. |
| Can the implementation be reused for the next customer? | Yes. |
Scenario 03
Seller account-control change
An external agent attempts to change who controls a seller account.
| Who initiates the request? | An external agent acting for a seller or a third-party operations tool. |
|---|---|
| Which trust domain controls the agent? | The seller's agent or an external ops tool. |
| What evidence is presented? | Authenticated session, a claimed mandate, prior account history. |
| Which fact is not independently verified? | Whether the actor has the authority to change who controls the account. |
| Which receiver team owns the loss? | Marketplace trust and safety. |
| Which decision would First Instinct produce? | require-human-approval or deny when authority cannot be established. |
| Can the Target issue a receipt? | Yes — the account system issues the outcome it actually applied. |
| Can the implementation be reused for the next customer? | Yes. |
Scenario 04
Merchant-state change
An external agent requests a change to a merchant's state on a platform.
| Who initiates the request? | An external agent or automation acting for a merchant. |
|---|---|
| Which trust domain controls the agent? | The merchant's automation, outside the platform's control. |
| What evidence is presented? | The change request, a claimed mandate, organisational authority signals. |
| Which fact is not independently verified? | Whether there is organisational authority to change the merchant's state. |
| Which receiver team owns the loss? | Platform risk and compliance. |
| Which decision would First Instinct produce? | require-human-approval or deny; indeterminate when organisational authority is unprovable. |
| Can the Target issue a receipt? | Yes — the platform issues the state change it actually made. |
| Can the implementation be reused for the next customer? | Yes. |
Scenario 05
Vendor bank-account change
An external request asks a buyer to change a supplier's bank details before payment.
| Who initiates the request? | An external agent or automation acting for a vendor or supplier. |
|---|---|
| Which trust domain controls the agent? | The supplier's system, often unverified upstream (a classic invoice-fraud vector). |
| What evidence is presented? | The change request, invoice history, a claimed mandate, an optional bank or PSP signal. |
| Which fact is not independently verified? | Whether the request genuinely originates from the authorised vendor. |
| Which receiver team owns the loss? | Accounts payable and finance. |
| Which decision would First Instinct produce? | require-human-approval or deny; indeterminate without independent source verification. |
| Can the Target issue a receipt? | Yes — the ERP or AP system issues the outcome it actually recorded. |
| Can the implementation be reused for the next customer? | Yes. |
Research candidates
Not part of the frozen five
These are under research and are deliberately not listed alongside the frozen scenarios above.
Account recovery
Under research; not part of the frozen first-wave scenarios.
Payment draft creation
Under research; not part of the frozen first-wave scenarios.