Security audit
Security checks for vulnerabilities and agentic risk
This instruction-improvement skill includes broader account controls and can spend credits despite its promised confirmation limits.
Prefer a version restricted to instruction improvement with enforced spending approval. Before using this version, set ARI to ask before every charge, select manual collection for one-time work, and review recurring schedules and competitor monitoring. Do not assume deepdive is a free preview.
scripts/ari.pyDeepdive can execute paid analysis despite its quote-only contract
A purported preview can consume account credits. For an absent primary subscription, the command can additionally return a misleading note that analysis was downgraded to a quote and no credits were deducted.
scripts/ari.pyRecurring paid collection can be enabled without an executable confirmation gate
An Agent can enable ongoing daily or weekly collection and future credit deductions before the user has confirmed recurring costs. This is a confirmation-enforcement defect, not evidence of cross-account access.
The specialized instruction-improvement entry point contains conflicting generic directives to execute paid VOC analysis automatically and describes itself elsewhere as an unrestricted operations entry point. Although the final section requires product/instructions and explicit payment confirmation, the competing actionable workflows create a credible path to out-of-scope execution and credit consumption.
The declared purpose describes review-based documentation recommendations, whereas the chunk exposes a recurring monitoring lifecycle with pricing acceptance and competitor tracking. These are substantive capabilities not disclosed in the description, rather than merely implementation details of extracting recommendations. The underlying script is not supplied, so exact API effects and billing behavior cannot be verified. There is no evidence here of automatic document publication.
Amazon review access and use of an ARI key are consistent with the description, but recurring watch management, competitor tracking, and price acceptance are substantive capabilities not disclosed by the narrowly stated purpose. The supplied chunk documents commands rather than showing that any watch has actually been created or any charge incurred. It does not show automatic document publication or medical, legal, or safety certification.
The comparison workflow recommends binding a competitor and states that binding starts weekly collection, without explicitly requiring separate approval for that recurring activity at this step. Authorization for a one-time comparison does not necessarily authorize persistent competitor collection, and the general scheduling safeguards are not clearly applied to this command.
Retrieving reviews could support the declared analysis, but configuring ongoing, potentially billable collection is a distinct operational capability not disclosed by the recommendation-only description. The supplied chunk manages collection schedules rather than extracting documentation improvements. It does not show automatic document publication or medical, legal, or safety-certification activity.
The supplied commands manage persistent, scheduled monitoring rather than extract review evidence or recommend instruction improvements. Recurring watches and explicit price acceptance introduce operational and potential financial effects not disclosed by the description. Although Amazon ASINs and the ARI service are consistent with the declared domain, these capabilities go beyond incidental implementation details. The supplied chunk does not establish automatic document publication or other prohibited uses.
The supplied command performs category-level ranking, which is materially different from the declared review-analysis purpose. It does not visibly identify installation, usage, or maintenance questions or produce instruction-improvement evidence. The snippet alone does not establish what --confirm authorizes, so no publishing or other side effect is inferred.
The supplied commands expose watch-monitoring and pricing functionality not described in the declared review-to-documentation workflow. The chunk does not demonstrate review analysis or documentation recommendations. It also does not show watches being created or enabled, documents being published, or other behavior beyond these queries.
The command explicitly selects '--type compare' and supplies '--competitor', indicating a competitive comparison workflow rather than the declared review-to-instruction improvement workflow. The script implementation is not supplied, so its exact data access and output cannot be established. There is no evidence here of automatic publication or medical, legal, or safety-certification activity.
The supplied commands expose recurring-watch and pricing functionality that is not declared in the review-to-instruction-improvement description. These appear to be additional user-facing capabilities rather than implementation details of extracting improvement recommendations. The underlying script is not supplied, so the assessment is limited to the commands and their accompanying comment.
The command specifies --type compare and --competitor, indicating competitive analysis rather than the declared review-to-instruction improvement workflow. Amazon product access and ARI usage are consistent with the description, but the comparison capability is undeclared. The underlying script is not supplied, so the exact analysis output and any side effects cannot be verified; the command alone does not establish automatic publication.
The supplied command targets alerts, which is materially different from the described review-based instruction analysis. The implementation of scripts/ari.py is not provided, so the exact alert behavior and any side effects cannot be established; the mismatch assessment is based on the exposed subcommand.
run_analysis converts an absent confirmation into authorization based solely on the server's autoConfirm value, contradicting the documented explicit-confirmation boundary. The same mechanism in cmd_voc can authorize both collection and analysis, and deepdive can unexpectedly incur charges through run_analysis.
In the surrounding billing policy, a server-provided autoConfirm flag permits credit-consuming operations without price confirmation, including initial operations without an amount ceiling. A server eligibility decision is not necessarily user authorization to spend credits, creating a risk of unexpected balance depletion; this changelog alone does not establish that the specialized skill exposes the affected operations.
- 重新发布：各市场首批上架的 1.5.0 包早于免确认修复，新注册的免费版用户仍会被要求先确认报价。
1.5.1 与当前官网下发的修复版一致，市场侧以新版本号覆盖旧包。
- 免确认只认服务端报价返回的 `autoConfirm`；采集报价扣除首次采集免费页；
非美国站首次采集可用赠送积点时不再提示「赠送积点不可用」（行为与修复后的 1.5.0 相同）。
- 命令、字段与计费规则不变，不提高最低支持版本。
The documented workflow automatically collects data and generates a paid report from an ASIN, while the first N paid generations have no amount ceiling unless the user has configured one. Honoring explicit confirmation preferences and checking the balance reduce exposure, but neither establishes informed spending consent for users with default settings.
- 行为变更：新用户（注册并验证邮箱后）第一次要 VOC，只给 ASIN 即可（站点默认美国站），
`voc` 直接执行——自动补采集（默认 3 页）、生成报告、按服务端定价扣费并归档，
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
This overlaps the same automatic-spending policy rather than establishing a separate vulnerability. Using a structured boolean instead of interpreting explanatory text is sensible, but the documented default still permits paid operations without a user-approved amount ceiling.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
This is a duplicate match to the same financial-consent issue at line 34, not an additional attack path. Explicit user preferences are reportedly respected, but users without configured preferences can still incur credit charges based solely on the server's automatic-confirmation policy.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
The changelog extends the same automatic-spending behavior to multiple analysis types, executing when autoConfirm is true and reporting charges afterward. Post-execution disclosure does not prevent unexpected spending; applicability remains uncertain because the changelog also says specialized packages remove analyze.
为 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 documented auto-confirm rules include first-use and remaining-use exemptions without an amount limit, not just thresholds deliberately configured by the user. Treating those service defaults as spending authorization permits credit deductions before cost disclosure and conflicts with this specialized skill's explicit-confirmation requirement.
`voc <ASIN>`（没说站点就用默认的美国站，不要为此追问）。
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
The agent is told to rely on the server's autoConfirm flag to authorize paid execution, although that flag may represent default first-run policy rather than a user-approved spending limit. Server eligibility to execute an operation is not sufficient evidence of the user's financial authorization.
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）
才报出 `totalCredits` 与余额并等待同意，同意后追加 `--confirm`。
This workflow explicitly skips quotation and invokes a command that can collect data, generate a report, and deduct credits immediately. Reporting charges afterward provides transparency but cannot substitute for authorization before spending, especially given the contradictory fixed-workflow confirmation rule.
1. 运行 `check`，确认账户、邮箱验证状态和可用积点。
2. 用户要 VOC / 评论分析报告时，默认运行 `voc <ASIN> --site <站点>`，**不要再先跑一次报价**。
**返回里有 `autoConfirmed: true`（或直接带 `reportId` / 正文）就说明报告已经生成并扣点了**
（1.5.0：新用户首次体验直接出结果，用户先拿到报告再谈钱）。
此时把报告讲给用户，并转述 `charges` — 本次采集扣了多少、分析扣了多少、合计多少、扣后还剩多少。
**不要在拿到结果后再补问「要不要生成」，也不要再回头补一次报价。**
The workflow explicitly invokes keyword analysis to generate advertising terms, negative keywords, competitor-brand terms, and a backend Search Terms string, and proactively promotes advertising use after a report. These outputs serve listing optimization and advertising rather than the manifest's limited purpose of improving installation, usage, and maintenance instructions.
The instruction explicitly allows initial paid generations without an amount cap and tells the agent not to ask when autoConfirm is true. An ASIN and a request for analysis do not necessarily authorize an undisclosed credit charge, and the first-run rule is not evidence of informed standing consent.
- **价格一律以服务端本次报价为准**（`analysis/quote` 与 `collect` 报价返回的 `credits` /
`totalCredits`）。文档与示例里出现的任何单价、页数、合计都只是演示，后台可调，
**不要凭记忆或旧文档报数，也不要把示例价当成承诺价。**
- 报价返回 `autoConfirm: true` 时直接生成，不要再问「要不要」。
生成后一句话交代本次实际扣了多少、扣后余额（读 `charges` 字段）。
1.5.0 起服务端对新用户前几次付费生成不看金额上限：新用户验证邮箱后只给一个 ASIN，就一次性出报告。
- 用户说「以后别问了 / 50 以内直接做」→ 运行 `autoconfirm 50`；说「以后每次先问我」→ `autoconfirm off`；