AI permissions and the AI action policy

Two separate controls decide what Conviro's assistant may do with your store:

1. AI capabilities — set in Magento (Stores › Configuration › Conviro › AI Chat › AI Capabilities, or wizard step 6). They decide what the assistant may read and answer from your store.
2. AI action policy — set in the Conviro dashboard (Settings › AI actions). It decides which changes the assistant may prepare, and who has to confirm and approve them.

Code: AiChat/Model/Config.php::getCapabilities, apps/api/src/modules/ai-actions/ (migration 0224_ai_action_policy.sql), dashboard pages from a98996a0. Read 2026-09-24; not deployed — the dashboard pages have not yet been opened in a browser against a real store.

1. AI capabilities (Magento)

Installation-wide (default scope); sent to Conviro on every registration.

Two trust-policy numbers sit in the same group: Return window (days) and Warranty length (months) — see Trust layer.

2. AI action policy (Conviro dashboard)

Settings › AI actions › Policy (workspace owners and admins). Nine actions:

Not supported on this store (release gate R3): when the store answers a return or quote request with 401 / 403 (the integration lacks the permission — Magento Open Source has no RMA or B2B API, or the permission was not granted) or 404 (no such route), Conviro does not report a failure to the shopper: a flow's or the AI's request becomes a task for your team, exactly as if there were no store API (task_created, outcome notSupportedOnStore). A staff member who called the endpoint directly gets the failure with its reason. With Order-action assistance off in Magento, returns and quote requests are tasks from the start. The RMA / B2B write path is unit-tested only; it has not been run on an Adobe Commerce installation. | Modify order | Task for your team (no store API granted). | | Edit delivery address | Task for your team. | | Exchange | Task for your team. | | Create coupon | Task for your team. |

Each action has one mode:

A corrupt or unknown stored value reads as off.

Changes to the policy (security review R3, 2026-09-25):

• A save carries the version it was based on; if a colleague saved in between it is refused and the page reloads (no lost update).
• Customer confirms lets an action run without a person looking at it, so only the workspace owner can choose it; admins can choose Off and team approves.
• Switching an action off withdraws, in the same save, every request of that action still waiting for the customer or for your team; a customer who was waiting for a decision is told it was closed without changes.
• The policy is read again when the customer confirms and when your team approves: an action switched off since then does not run (the request expires), and one made stricter since then goes to your team for approval.
• The audit log records the real person; when Conviro support acts in your workspace (impersonation), it records the support user, with your user alongside.

What happens in a conversation

1. The shopper asks to cancel, return or exchange an order that the assistant has verified (order number + checkout e-mail). Pairs that do not match are counted per conversation, per visitor / messaging identity and per e-mail: after 5 misses in an hour order lookups stop for that key and the assistant says it cannot verify orders in the chat right now (without saying which detail was wrong), and offers your team.
2. Eligibility is read from the verified live order state:

   Action	Eligible Magento order states
   Cancel	new, pending, pending_payment (a held order is not cancellable)
   Hold, modify, edit address	new, pending, pending_payment, processing
   Return, exchange	complete, processing
   Comment, coupon, quote request	any

3. If the policy allows it, the assistant replies with a prepared, not done request and two choices — confirm / decline — in the conversation's language (21 languages; buttons where the channel has them, a numbered list otherwise). Only an explicit choice confirms (the button or its exact label; its number only when the assistant's last message offered exactly these two options; a free-text "ok" does not). A newer request replaces an older unconfirmed one in the same conversation; two requests prepared at the same moment leave one. With Customer confirms, the confirm button is not enough: the customer types the 6-digit code sent to the order's checkout e-mail (valid 10 minutes, 5 attempts; the e-mail goes through your workspace's mail settings, in the conversation's language; at most 3 code e-mails per order e-mail an hour). If the code cannot be sent, the request goes to your team for approval instead.
4. The request expires after 30 minutes without a choice (10 minutes with a code).
5. With team approves, the request waits in Inbox › Approvals (also under Settings › AI actions › Approvals): tabs Waiting, Failed, Decided; approve or reject with an optional internal note. A decision is taken once — a second click or a colleague deciding at the same time changes nothing. A request nobody decides within 7 days expires and the customer is told.
6. Execution: Conviro re-reads the order from Magento (e-mail and state checked again) immediately before writing. Magento answering false counts as a failure. Anything without a store API — or a store call that fails — becomes a task for your team with the prepared details; Conviro never reports a success it did not get. A request still running after 15 minutes (a server stopped mid-call) is closed as failed with a follow-up task, so someone checks the order.
7. The outcome is posted into the customer's conversation, in their language.

Audit log

Settings › AI actions › Audit log: every step of every request, filterable by action, step, order number and date. Steps: requested, blocked by policy, eligible / not eligible, prepared, customer confirmed / declined, expired, approved / rejected (with the team member), done in store / store did not accept (with the HTTP status), task created, customer notified, policy changed, code e-mailed / wrong or expired code, moved to team approval. Each step is written in the same database transaction as the status change it records. The customer appears only as a masked e-mail (a***@example.com); the e-mail is kept only as a keyed hash that is never shown, and when the conversation is deleted the request's content is scrubbed (the audit trail stays).

Flows and staff actions

• The flow-builder nodes Magento order cancel, Magento RMA create and Magento quote create go through the same policy: off blocks them (the node's ticket fallback applies), team approves queues them.
• Customer confirms (since 2026-09-25, security review R3 residual risk R-b): a flow step alone no longer confirms a write to the store — the flow's check is order number + checkout e-mail, which can be guessed. Like chat, the customer must type the one-time code e-mailed to the order's checkout address (6 digits, 10 minutes, 5 attempts, at most 3 code e-mails per order e-mail and hour, in the conversation's language). A node collects it when you set its One-time code variable (verificationCodeField) — the variable a Collect Input step stores the customer's answer in. In the flow editor the three nodes show that field on top, with the node's other settings as JSON below it (a pasted {{variables.code}} is stored as code); the editor's Available variables list shows the nodes' outputs, codeRequired among them:
  1. the node runs and e-mails the code; its output is codeRequired: true, verificationRequestId and codeSentTo (masked address);
  2. your flow asks for the code (a Collect Input step → the variable you named) and runs the same node again;
  3. the right code runs the write (success: true); a wrong one answers codeInvalid: true with attemptsLeft; an expired, used-up or foreign request answers codeExpired: true (the ticket fallback applies).

  With the field empty (the editor says so under it), or when the code cannot be e-mailed (no mail transport, the hourly limit), the request goes to team approval instead (pendingApproval: true) — it never runs on order number + e-mail alone. A request that only becomes a task for your team (no store write) needs no code.

• Actions a team member takes in the Conviro dashboard are audited under their name and are not subject to the AI policy (a human is acting).
• An AI or flow write is refused unless it carries the verified checkout e-mail (checked again against the fresh order — or, for a B2B quote, the customer); a flow's order lookup without an e-mail check does not return the customer's e-mail or name.
• Conviro's action writer (magento-order-actions.ts) is the only code in the Conviro API that writes to a Magento store.

Upgrade note

Every action is off for every workspace until switched on. Flows that used the three Magento write nodes before this release stop writing until the matching action is enabled (6f21008f).

Measured (backend unit and Postgres tests only): gateway 34/34, Magento order actions 16/16, no-bypass scan 12/12, service 9/9, Postgres 17 store 6/6 (five concurrent approvals → one transition; three concurrent expiry sweeps → one expiry). After the security review (2026-09-25): the ai-actions suites 94/94 + executor 23/23, Postgres 16 store 10/10 (unique open request under concurrency, stale policy version refused, same-transaction withdrawal, 7-day and stuck sweeps, scrubbing). Not run against a Magento store.