Agent Commerce Action Review

Agent Commerce Action Review

Preflight proposed actions with a local, evidence-first approval rubric. This skill performs no network requests and never authorizes or executes an action.

Hard Boundaries

• Review only. Do not execute, simulate execution, sign, publish, deploy, pay, trade, delete, or change external state.
• Do not call a hosted evaluator or send the manifest to an external service.
• Never ask for or reproduce secrets, tokens, passwords, cookies, credentials, private keys, seed phrases, recovery codes, customer data, or private wallet material.
• Describe sensitive dependencies with booleans or labels, such as "credentialRequired": true; do not include the sensitive value.
• Treat missing evidence as missing. Do not infer approval, reversibility, budgets, or target identity.

Normalize The Proposal

Convert each proposed action into this compact manifest when the user has not already supplied equivalent fields:

{
  "actions": [
    {
      "id": "deploy-production",
      "actor": "copilot",
      "action": "Deploy the customer portal to production",
      "target": "production",
      "readOnly": false,
      "externalStateChange": true,
      "destructive": false,
      "credentialRequired": false,
      "amountUsd": 0,
      "budgetUsd": 0,
      "approved": false,
      "validation": "Run the production smoke suite",
      "rollback": "Redeploy the previous release"
    }
  ]
}

Workflow

1. Summarize each proposed action without executing it.
2. Remove any sensitive value from the review context. If safe abstraction is impossible, stop and return deny.
3. Read the decision rubric.
4. Identify every applicable risk category. Do not stop after the first match.
5. Apply decision precedence: deny overrides review, which overrides allow.
6. Compare declared spend or budget only with a limit explicitly supplied by the user or repository policy. If no limit exists, do not invent one.
7. List the missing evidence required to move the action toward a safer state.
8. Report results in the required format below.
9. Keep execution separate. A later execution request still requires explicit user approval and the safeguards appropriate to that action.

Use the worked examples to resolve ambiguous cases consistently.

Required Output

Start with a summary table:

| ID | Decision | Severity | Primary reason |
| --- | --- | --- | --- |
| deploy-production | REVIEW | high | Production deployment changes external state and lacks explicit approval. |

Then provide one section per action:

## deploy-production: REVIEW

- Risk categories: production-change, external-publish
- Reasons:
  - Production deployment changes external state.
  - Explicit approval is not present in the current conversation.
- Required evidence:
  - Exact target and proposed command
  - Current-conversation user approval
  - Validation plan and success criteria
  - Rollback command or recovery path
- Execution status: not executed

Always include Execution status: not executed.

Incomplete Proposals

Ask only for the non-sensitive facts needed to decide the review. When a critical fact remains unavailable:

• use review when the action may be safe after ordinary clarification;
• use deny when the proposal involves credentials, funds, live trading, public identity, destructive changes, or another irreversible boundary without explicit approval.

Never reinterpret a failed or incomplete review as approval.