Security audit
Security checks for vulnerabilities and agentic risk
This audit skill needs review because its broader tools can spend credits during operations described as previews and enable ongoing paid collection.
Prefer a corrected audit-only package that fixes preview charging. If proceeding, configure the account to ask before every charge, approve recurring collection separately, and review existing schedules and competitor subscriptions. Do not assume omitting --confirm makes every command free.
scripts/ari.pyDocumented preview-only deepdive can generate a paid report
Unexpected credit deduction and report generation. For an absent main-product subscription, deepdive can additionally return a message claiming that analysis was downgraded to quotation and no credits were deducted, even after the helper executed it.
scripts/ari.pyRecurring paid collection changes lack an enforced confirmation gate
Unintended recurring collection and depletion of account credits until the schedule or relationship is disabled.
The document combines a narrowly scoped, confirmation-required promise audit with general workflows that direct automatic paid VOC execution and other account operations. The final audit-only restriction mitigates the risk, but conflicting operational instructions can still route a narrowly authorized request into broader, charge-incurring work; actual CLI enforcement is not shown.
The comparison workflow says that binding a competitor causes automatic weekly collection, but that step does not explicitly require separate approval for recurring collection or disclosure of its cost. Approval for a one-time comparison is not necessarily approval for persistent monitoring, although the document's general recurring-charge safeguards partially mitigate this ambiguity.
Amazon product monitoring could support promise verification, but ongoing scheduled jobs and explicit price acceptance are material operational capabilities not disclosed in the description, rather than merely internal implementation details. The supplied chunk shows watch-management commands, not promise-versus-review analysis. It does not establish that charges actually occurred or reveal the underlying CLI implementation.
Collecting product and review evidence can support the declared audit purpose, but configuring ongoing, potentially paid collection is a material operational capability not disclosed in the description. The supplied chunk documents scheduling commands rather than showing the underlying implementation, so it does not establish what data is collected or how billing occurs.
The visible commands expose watch-management and pricing functions that are not described in the declared promise-audit purpose. Although ARI integration is declared, the chunk does not connect these watch functions to evidence verification. This assessment is limited to the supplied commands; the underlying script implementation is not shown.
Product monitoring could support promise verification, but ongoing scheduled watches, competitor tracking, and price-accepted refreshes materially expand the declared audit-only scope. These are user-facing capabilities rather than incidental implementation details. The supplied content contains command examples rather than their implementation, so actual API calls, charges, and data access cannot be independently verified.
Although monitoring results could support promise verification, managing persistent, potentially billable watches is a material capability not disclosed in the description. The snippet focuses on watch lifecycle management and monitoring history rather than comparing product promises with review evidence. It is a command reference, so it demonstrates exposed operations, not that any commands were executed or charges incurred.
The supplied command requests a negative-review-rate leaderboard, which is a distinct analytical output not disclosed in the description. Negative-review rates alone do not establish whether product-page promises match actual customer experiences. The underlying script is not supplied, so this assessment is limited to the visible invocation and does not infer additional access or side effects.
The supplied command explicitly requests comparison against a competitor rather than verification of product-page promises against review evidence. This indicates an undeclared analysis capability. The underlying script is not supplied, so the assessment is limited to the visible invocation; no additional data access or side effects are inferred.
The supplied command invokes alerts, rather than an identifiable product-promise or review-verification operation. Alert functionality is not declared, and the chunk provides no evidence connecting it to the promised audit workflow. This assessment is limited to the visible command; its underlying data access, network activity, and side effects cannot be established.
The instructions explicitly encourage generating a previously quoted report in a later conversation when the user never responded to the quote. An idle product and server-side auto-confirm eligibility do not establish current user authorization, so this can consume credits for abandoned work.
run_analysis changes confirm from false to true based on a server-supplied autoConfirm value, allowing a paid request without the explicit flag promised by the module. This also affects deepdive, whose intended quote-only downgrade can be overridden by this branch; cmd_voc has an equivalent bypass that can additionally submit collection.
The documented policy makes a server-provided autoConfirm flag sufficient to authorize chargeable operations. The surrounding release notes describe default automatic approval without an amount ceiling, rather than requiring prior user authorization for a defined spending limit; this could consume account credits unexpectedly. This is a documented authorization-design concern, not verification that the affected commands are present in this specialized package.
- 重新发布：各市场首批上架的 1.5.0 包早于免确认修复，新注册的免费版用户仍会被要求先确认报价。
1.5.1 与当前官网下发的修复版一致，市场侧以新版本号覆盖旧包。
- 免确认只认服务端报价返回的 `autoConfirm`；采集报价扣除首次采集免费页；
非美国站首次采集可用赠送积点时不再提示「赠送积点不可用」（行为与修复后的 1.5.0 相同）。
- 命令、字段与计费规则不变，不提高最低支持版本。
The changelog explicitly describes automatically collecting data, generating a report, and deducting credits without presenting the quote for confirmation, with no amount ceiling for the first N paid generations. Requesting a report does not necessarily authorize an undisclosed charge, and showing charges afterward does not establish prior consent. Gift credits and insufficient-balance checks reduce exposure but do not provide a user-approved spending boundary.
- 行为变更：新用户（注册并验证邮箱后）第一次要 VOC，只给 ASIN 即可（站点默认美国站），
`voc` 直接执行——自动补采集（默认 3 页）、生成报告、按服务端定价扣费并归档，
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
This overlaps the same automatic-spending policy identified at line 32, rather than establishing a separate exploit. Ignoring descriptive autoConfirm metadata is not itself unsafe, but accepting the server boolean as sufficient authorization remains problematic when default approvals have no monetary ceiling. Honoring explicit user thresholds mitigates the risk only for users who have already configured them.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
This is another overlapping match for the same documented spending-authorization weakness, not an additional independent vulnerability. Using a structured boolean instead of inferring permission from prose is sensible, but a service-selected approval flag cannot replace user consent to an otherwise unbounded charge. Runtime applicability remains uncertain because the supplied file is a changelog and describes command removal from specialized packages.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
This extends the same automatic charge policy to multiple analysis types: autoConfirm=true leads directly to generation and post-execution charge reporting. If the flag reflects service defaults rather than explicit user authorization, an ordinary analysis request can cause unexpected credit expenditure. The changelog alone does not demonstrate that these commands remain available in this specialized skill.
为 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 spending can be appropriate under a user-established limit, but this instruction also accepts first-use and remaining-use server exemptions without an amount cap or demonstrated user approval. It therefore treats service eligibility as spending authorization and can deduct credits before the user sees the price.
`voc <ASIN>`（没说站点就用默认的美国站，不要为此追问）。
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
The autoConfirm response is used as the sole decision criterion even though the documented server rules include exemptions that are not user-selected spending limits. This is the same authorization weakness as the preceding finding: a service response can permit charging without establishing informed consent.
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
才报出 `totalCredits` 与余额并等待同意，同意后追加 `--confirm`。
The standard workflow directs immediate general VOC execution, which may charge credits, while the specialized entry point requires a quoted and explicitly confirmed promise audit. This contradiction creates a concrete risk of executing and charging for the wrong workflow, rather than merely producing an off-topic answer.
The default workflow explicitly skips quotation and invokes a command capable of charging before discussing cost. Reporting charges afterward does not repair missing prior authorization, particularly for this skill's explicitly confirmation-required audit purpose.
1. 运行 `check`，确认账户、邮箱验证状态和可用积点。
2. 用户要 VOC / 评论分析报告时，默认运行 `voc <ASIN> --site <站点>`，**不要再先跑一次报价**。
**返回里有 `autoConfirmed: true`（或直接带 `reportId` / 正文）就说明报告已经生成并扣点了**
（1.5.0：新用户首次体验直接出结果，用户先拿到报告再谈钱）。
此时把报告讲给用户，并转述 `charges` — 本次采集扣了多少、分析扣了多少、合计多少、扣后还剩多少。
**不要在拿到结果后再补问「要不要生成」，也不要再回头补一次报价。**
This passage expressly allows early paid generations without an amount ceiling based only on a server flag and an ASIN. That creates a credit-spending authorization gap; the surrounding requirement to use accurate prices does not substitute for approval before charging.
- **价格一律以服务端本次报价为准**（`analysis/quote` 与 `collect` 报价返回的 `credits` /
`totalCredits`）。文档与示例里出现的任何单价、页数、合计都只是演示，后台可调，
**不要凭记忆或旧文档报数，也不要把示例价当成承诺价。**
- 报价返回 `autoConfirm: true` 时直接生成，不要再问「要不要」。
生成后一句话交代本次实际扣了多少、扣后余额（读 `charges` 字段）。
1.5.0 起服务端对新用户前几次付费生成不看金额上限：新用户验证邮箱后只给一个 ASIN，就一次性出报告。
- 用户说「以后别问了 / 50 以内直接做」→ 运行 `autoconfirm 50`；说「以后每次先问我」→ `autoconfirm off`；
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.
- 报价返回 `autoConfirm: true` 时直接生成，不要再问「要不要」。
生成后一句话交代本次实际扣了多少、扣后余额（读 `charges` 字段）。
1.5.0 起服务端对新用户前几次付费生成不看金额上限：新用户验证邮箱后只给一个 ASIN，就一次性出报告。
- 用户说「以后别问了 / 50 以内直接做」→ 运行 `autoconfirm 50`；说「以后每次先问我」→ `autoconfirm off`；
说「恢复默认」→ `autoconfirm default`。这是唯一需要你代用户设置的东西，设完复述一句当前规则。
- 报价需要确认时，只说两个数：这次多少积点（取报价返回的 `credits` / `totalCredits`，
**不要自己算、不要写死单价**）、余额多少，然后等用户一个「好」。单价与页数由后台配置决定，