Security audit
Security checks for vulnerabilities and agentic risk
This Amazon review tool can spend credits before you approve the cost, including through a command described as a preview.
Before requesting reports, set ARI to ask before every charge using autoconfirm off. Use quote for previews; deepdive is not reliably quote-only. Approve recurring costs separately and check existing schedules: selecting manual for a collection preserves an existing product's schedule rather than disabling it. Keep the saved API key private.
scripts/ari.pyQuote-only deepdive can execute a paid analysis
A user or Agent following the documented deepdive preview workflow can consume credits unexpectedly. When the product is absent and --confirm was supplied, productNote can additionally claim that no charge occurred even though the helper executed the analysis.
scripts/ari.pyRecurring paid collection can be enabled without an executable confirmation gate
An Agent or integration can activate continuing paid collection before the user approves its recurring cost, leading to subsequent credit deductions until the schedule is disabled.
The broad feature set is not inherently unsafe, but the instructions explicitly permit spending credits under server-defined first-use exemptions without prior price approval. They also describe competitor binding that initiates weekly collection without attaching an explicit recurring-charge consent requirement to that operation.
The declared purpose describes review collection and negative-review analysis, but does not disclose recurring monitoring, competitor tracking, or per-refresh price acceptance. These are additional user-facing capabilities rather than merely implementation details. The excerpt contains command examples, not the underlying implementation, so it does not establish what each refresh collects or whether charges actually occur.
Historical series and digests could support the declared trend analysis, but the command set additionally exposes a recurring monitoring lifecycle with explicit per-refresh price acceptance and optional competitor tracking. Those are substantive capabilities not disclosed by the review-analysis description. The supplied chunk does not demonstrate negative-review filtering, root-cause analysis, frequency ranking, or improvement recommendations.
Historical series and digests could support the declared trend analysis, but recurring monitoring, competitor tracking, and explicit price acceptance introduce capabilities not disclosed in the description. The chunk is a command reference rather than evidence that these operations have actually executed; nevertheless, the operations it exposes materially exceed the declared negative-review analysis workflow.
The workflow states that adding a competitor automatically starts weekly collection, but it does not explicitly require disclosure and approval of that recurring commitment at the binding step. Approval of a one-time competitor comparison could therefore be incorrectly treated as authorization for ongoing collection and potential charges.
The supplied command requests a Kitchen-category leaderboard, not reviews or complaint analysis for an individual ASIN. Although negative-review rate is thematically related to the description, category-level product ranking is a distinct, undeclared capability. The CLI implementation is not supplied, so further behavior or side effects cannot be established.
Review collection supports the declared analysis purpose, but configuring recurring, potentially billable automation is a distinct capability not disclosed in the description. The chunk exposes schedule management rather than review analysis. The underlying script is not provided, so this assessment is limited to the commands and their documented effects.
The command explicitly selects '--type compare' and supplies '--competitor', indicating a competitive comparison rather than solely the declared single-ASIN negative-review analysis. The supplied chunk does not expose the script implementation, so its exact data collection and outputs cannot be verified.
The supplied commands concern watch configuration, estimates, and inventory rather than collecting or analyzing negative reviews. Watch-service inspection is not described in the declared purpose, and this chunk does not establish that it is a supporting step for review analysis. This assessment is limited to the two supplied commands; it does not imply that they create watches or modify account state.
The supplied commands concern watch-service pricing and watch listing, capabilities not described in the declared negative-review analysis workflow. No review collection, complaint analysis, recommendations, or chart generation appears in this chunk. The implementation of scripts/ari.py is not supplied, so this assessment is limited to the visible commands and annotation.
The explicit '--type compare' and '--competitor' arguments select a competitive-comparison workflow rather than the declared negative-review analysis workflow. This is a distinct, undeclared capability, not merely a supporting implementation detail. The script implementation is not supplied, so its precise data access and outputs cannot be verified.
The only supplied executable action selects an alerts operation rather than an identifiable review-collection or negative-review-analysis workflow. This indicates an undeclared capability. The snippet does not establish whether alerts are retrieved, configured, or otherwise processed, so no more specific behavior can be confirmed.
The instruction converts an unanswered quotation from a previous conversation into execution in a later conversation when automatic confirmation applies. Silence and an idle product record do not establish current task authorization, so this can spend credits on work the user never approved or no longer wants.
run_analysis converts an absent local confirmation into approval when the server returns a truthy autoConfirm value, contradicting the documented requirement for --confirm. cmd_voc similarly permits collection and analysis without that flag, and deepdive can unexpectedly reach the same charging path; account-level preferences may authorize some uses, but this client does not independently establish their scope.
The surrounding changelog describes using a server-returned autoConfirm flag to permit paid operations without first obtaining price confirmation. A service eligibility decision is not necessarily user authorization to spend credits; the review-analysis context makes this a billing-consent risk rather than inherently malicious automation. This is evidence of a documented design issue, not verification of its runtime implementation.
- 重新发布：各市场首批上架的 1.5.0 包早于免确认修复，新注册的免费版用户仍会被要求先确认报价。
1.5.1 与当前官网下发的修复版一致，市场侧以新版本号覆盖旧包。
- 免确认只认服务端报价返回的 `autoConfirm`；采集报价扣除首次采集免费页；
非美国站首次采集可用赠送积点时不再提示「赠送积点不可用」（行为与修复后的 1.5.0 相同）。
- 命令、字段与计费规则不变，不提高最低支持版本。
The documented policy automatically collects data and generates paid reports, with the first N paid generations explicitly lacking an amount ceiling. Requesting review analysis does not necessarily authorize an undisclosed charge, and showing charges afterward cannot provide advance consent. User-set thresholds, explicit ask-first preferences, and balance checks reduce exposure but do not establish a safe default spending limit.
- 行为变更：新用户（注册并验证邮箱后）第一次要 VOC，只给 ASIN 即可（站点默认美国站），
`voc` 直接执行——自动补采集（默认 3 页）、生成报告、按服务端定价扣费并归档，
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
This occurrence belongs to the same billing-authorization issue: a structured server flag is treated as sufficient permission for automatic paid execution. Using a boolean instead of interpreting explanatory text is technically sound, but it does not replace user consent, especially when the default server policy has no amount ceiling.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
This is a duplicate detection of the same policy described by the other finding at line 34, not a separate exploit. The concern is delegating spending authorization to server-controlled autoConfirm without a default amount ceiling, not the mere presence of that field or the decision to avoid parsing prose.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
The changelog extends automatic paid execution to multiple analysis types whenever autoConfirm is true, broadening the same consent weakness beyond VOC generation. Returning charges afterward and blocking insufficient balances do not prevent unwanted consumption of available credits. This remains a documented billing-design concern; the supplied file does not establish how the runtime enforces authorization.
为 true 时赠送积点计入 `nonUsCollectCredits`、`siteNote` 为空；UK/DE/JP 卖家的第一份 VOC 同样一步直出。
- 余额不足仍在执行前拦截（402）并引导充值；定价以服务端配置为准，代码常量仅为兜底。
- 一致性：`analyze` 各类型（insight / keywords / trend / variant / compare）走同一口径，
`autoConfirm=true` 即直接生成并返回 `charges`。
- 文档：移除所有写死的单价与合计示例。采集/分析单价与页数由后台 `pricing` 配置决定，
一律以本次报价返回的 `credits` / `totalCredits` 为准，不得凭文档或记忆报数。
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- 能力层收窄：44 个专属包不再只是「声明窄」，包体 `scripts/ari.py` 同时按各自契约裁剪。
构建期用 AST 删除文档未承诺的命令、它们的解析器注册块，以及只被它们引用的辅助函数与
常量；专属包因此不再包含 `export`（任意路径写文件）、`autoconfirm`（撤销逐次确认）、
`workbench`（改写差评处理状态）、`alerts`（标记预警已读）、`competitors`、`schedule`、
`voc` / `analyze` / `charts` / `deepdive` 等母版命令。
- 新增运行期兜底闸：专属包在包内写入 `allowedCommands` 白名单，`ari.py`
Without declared permissions the skill's intent is opaque and cannot be validated.
Automatic execution includes first-use and remaining-use exemptions that are not necessarily spending limits chosen by the user. Treating a server-provided autoConfirm flag as sufficient consent can consume credits without prior disclosure of an uncapped operation's cost.
`voc <ASIN>`（没说站点就用默认的美国站，不要为此追问）。
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
The workflow lets a server flag determine whether financial approval is needed, including exemptions unrelated to user-configured thresholds. Reporting the charge after report generation provides transparency but does not supply prior authorization.
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
才报出 `totalCredits` 与余额并等待同意，同意后追加 `--confirm`。
The standard workflow deliberately invokes a potentially chargeable command before obtaining a quote and describes first-use behavior as delivering the report before discussing money. A request for analysis alone does not establish informed approval of an undisclosed credit charge.
1. 运行 `check`，确认账户、邮箱验证状态和可用积点。
2. 用户要 VOC / 评论分析报告时，默认运行 `voc <ASIN> --site <站点>`，**不要再先跑一次报价**。
**返回里有 `autoConfirmed: true`（或直接带 `reportId` / 正文）就说明报告已经生成并扣点了**
（1.5.0：新用户首次体验直接出结果，用户先拿到报告再谈钱）。
此时把报告讲给用户，并转述 `charges` — 本次采集扣了多少、分析扣了多少、合计多少、扣后还剩多少。
**不要在拿到结果后再补问「要不要生成」，也不要再回头补一次报价。**
This passage explicitly permits the first few paid generations without an amount ceiling and instructs the agent not to request approval when autoConfirm is true. Email verification and provision of an ASIN do not demonstrate consent to an unspecified financial commitment.
- **价格一律以服务端本次报价为准**（`analysis/quote` 与 `collect` 报价返回的 `credits` /
`totalCredits`）。文档与示例里出现的任何单价、页数、合计都只是演示，后台可调，
**不要凭记忆或旧文档报数，也不要把示例价当成承诺价。**
- 报价返回 `autoConfirm: true` 时直接生成，不要再问「要不要」。
生成后一句话交代本次实际扣了多少、扣后余额（读 `charges` 字段）。
1.5.0 起服务端对新用户前几次付费生成不看金额上限：新用户验证邮箱后只给一个 ASIN，就一次性出报告。
- 用户说「以后别问了 / 50 以内直接做」→ 运行 `autoconfirm 50`；说「以后每次先问我」→ `autoconfirm off`；