Security audit
Security checks for vulnerabilities and agentic risk
This skill can spend service credits without fresh approval, and its advertised quote-only protection is unreliable.
Before analysis, set account confirmation to 'ask every time' using autoconfirm off. Use quote for estimates; omitting --confirm is not a reliable safeguard. Require fresh approval for unanswered quotes and separate approval for recurring collection. Prefer a corrected release that enforces these boundaries and resolves the conflicting billing promises.
scripts/ari.pyQuote-only deepdive can automatically execute paid analysis
The CLI sends an authenticated POST to /api/v1/analysis/voc and can consume account credits despite the documented requirement that deepdive only analyze with --confirm. In the missing-product branch, it can also report that execution was downgraded to a quote and no credits were charged after having initiated paid analysis.
The declared purpose concerns turning review complaints into product-development recommendations. The supplied commands instead manage recurring monitoring subscriptions, including competitor tracking and price acceptance. These are substantive capabilities not disclosed in the description, rather than merely implementation details of generating an improvement list. No review analysis or improvement prioritization is shown. This assessment concerns the commands presented; the implementation of scripts/ari.py is not supplied.
Review retrieval, authentication, report access, and exports can support the declared purpose and are not themselves the basis for this finding. However, the supplied code exposes substantial additional operational and financial capabilities, especially recurring monitoring, competitor management, and account-level auto-confirm settings. These are not disclosed by the narrow product-improvement description. The CLI also permits workflow/focus overrides rather than visibly enforcing product-improvement-only analysis. An optional allowedCommands configuration could restrict top-level commands, but that configuration is not supplied and the code defaults to unrestricted access when it is absent. The exact promised prioritization and change-cost classification cannot be verified because analysis is performed server-side.
Collecting reviews could support product-improvement analysis, but configuring recurring, potentially billable collection is a substantive capability not disclosed in the description. The supplied commands manage monitoring schedules rather than analyze complaints or generate prioritized improvement recommendations. This assessment is limited to the visible commands; the implementation of scripts/ari.py is not provided.
Recurring monitoring, persistent watch management, and acceptance of refresh charges are substantive capabilities not disclosed by the product-improvement description. They go beyond supporting a one-time review-to-improvement analysis. The supplied chunk does not demonstrate complaint analysis or iteration prioritization. It is a command reference, so it establishes exposed operations rather than proving that any watch was actually created or any charge incurred.
The declared purpose is review-based product improvement planning, but the supplied chunk centers on a watch-management workflow, including scheduled monitoring and price acceptance. These are substantive capabilities not disclosed in the description, rather than merely supporting analysis details. The chunk shows no complaint analysis, prioritization, or categorization of product changes. The underlying script is not supplied, so this assessment concerns the exposed commands rather than verified backend execution.
The visible commands concern watch-service pricing and listing watches, rather than analyzing review complaints or prioritizing product changes. These capabilities are not described in the declared purpose, and the snippet establishes no supporting connection to that workflow. The underlying Python implementation is not supplied, so this assessment is limited to the visible commands and their annotation.
The supplied commands concern ARI watch functionality, including watchEnabled, per-refresh costs, monthly estimates, and watch listing. These capabilities are not described in the declared product-improvement purpose, and the chunk shows no review-complaint analysis or improvement prioritization. Using the same ARI API does not by itself make these operations supporting implementation details. This assessment is limited to the supplied chunk.
The competitor workflow states that binding a competitor enables weekly collection, but does not attach the explicit recurring-cost approval required elsewhere for schedules and watches. An agent could treat association as an incidental comparison setup step and create an ongoing collection obligation without informed consent.
The supplied commands expose watch-monitoring functionality rather than review-to-product-improvement analysis. They do not show complaint analysis, impact or severity prioritization, or classification of changes by implementation cost. Although monitoring data could support a broader analysis workflow, the supplied chunk establishes no such connection, and the declared description does not disclose watch-monitoring capabilities.
The supplied command explicitly selects --type compare and provides a --competitor ASIN, indicating a competitive comparison rather than the declared review-to-improvement workflow. Although competitive analysis could inform product development, it is the explicit operation shown here and is not described as a capability. The underlying script is not supplied, so its internal processing and outputs cannot be verified.
The supplied command requests a negative-review-rate leaderboard, not complaint analysis or a prioritized product-iteration checklist. Although negative-review rates could support improvement analysis, no connection to that workflow is shown. The visible operation therefore materially differs from the declared purpose. No additional behavior is inferred from --confirm or the unavailable script implementation.
The supplied command explicitly selects operations quote --workflow audit --focus full. Its immediate function is obtaining an audit quote, not converting review complaints into prioritized product changes. The Amazon ASIN and marketplace are consistent with the declared domain, but the selected operation and workflow differ materially. This assessment is limited to the supplied invocation; the underlying ARI implementation is not shown.
可见命令的核心操作是 --type compare，且要求提供 --competitor，表明其直接用途是竞品对比。声明没有描述这一独立分析能力，而命令也未体现改进清单、严重度排序或改进成本分类。由于未提供 ari.py 的实现，无法确认其内部行为或输出；此判断仅依据所示调用，不推断额外的数据访问或副作用。
The supplied command targets alerts rather than review analysis or product-iteration recommendations. This indicates a different capability from the declared purpose. However, scripts/ari.py is not supplied, so the exact alert behavior and any resource access cannot be verified.
The skill directs the agent to revisit an unanswered quote in a later conversation and proceed with generation when automatic confirmation applies. An idle product or prior inquiry is not current authorization to spend credits, so this can initiate unwanted paid work unrelated to the user's present request.
run_analysis changes confirm from false to true based on a server-supplied autoConfirm value, allowing chargeable execution without the documented --confirm flag. cmd_voc similarly extends an analysis quote's auto-confirm decision to paid collection, so an agent expecting a preview can consume account credits without obtaining transaction-specific approval.
Read together with the v1.5.0 entry, this documents allowing a server-provided autoConfirm flag to authorize credit-consuming actions without transaction confirmation or a default spending ceiling. Server permission is not necessarily user consent, so an ordinary product-analysis request could consume credits unexpectedly; the supplied changelog does not establish whether the implementation adds further safeguards.
- 重新发布：各市场首批上架的 1.5.0 包早于免确认修复，新注册的免费版用户仍会被要求先确认报价。
1.5.1 与当前官网下发的修复版一致，市场侧以新版本号覆盖旧包。
- 免确认只认服务端报价返回的 `autoConfirm`；采集报价扣除首次采集免费页；
非美国站首次采集可用赠送积点时不再提示「赠送积点不可用」（行为与修复后的 1.5.0 相同）。
- 命令、字段与计费规则不变，不提高最低支持版本。
The documented policy automatically collects data and generates a paid report, with the first N paid generations exempt from an amount limit. Gift-credit coverage, balance checks, and post-operation charge disclosure reduce some consequences but do not establish informed authorization to spend existing credits.
- 行为变更：新用户（注册并验证邮箱后）第一次要 VOC，只给 ASIN 即可（站点默认美国站），
`voc` 直接执行——自动补采集（默认 3 页）、生成报告、按服务端定价扣费并归档，
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
This is another match within the same automatic-spending policy, not a separate vulnerability. Using a structured boolean rather than interpreting explanatory text is appropriate, but treating that server boolean as sufficient authorization remains unsafe without an explicit user-approved spending policy.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
This duplicates the preceding finding's underlying authorization concern. The danger is not the autoConfirm identifier or avoiding prose-based inference, but allowing a server-selected default to trigger paid work without an established user spending mandate.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
This extends the same automatic-spending behavior to multiple analysis types, potentially consuming credits for tasks beyond report generation. Returning charges afterward provides transparency but cannot substitute for authorization before the credits are spent.
为 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.
The skill treats server-defined first-run eligibility as permission to collect, generate, and debit credits without disclosing the cost beforehand, including cases with no amount limit. A server's willingness to execute is not evidence of user-approved spending; explicitly configured user thresholds are safer, but do not justify the default first-run path.
`voc <ASIN>`（没说站点就用默认的美国站，不要为此追问）。
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
The instruction makes the API's autoConfirm field the decisive authority for bypassing user confirmation. Because that field can reflect default first-run rules rather than explicit user consent, paid execution can occur without an approved price or spending limit.
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
才报出 `totalCredits` 与余额并等待同意，同意后追加 `--confirm`。