Security audit
Security checks for vulnerabilities and agentic risk
This skill can spend ARI credits without fresh approval, including after an unanswered quote and during an operation described as a free preview.
Before use, set ARI to ask before every charge and verify the setting. Use the dedicated quote command for pricing; omitting --confirm does not reliably prevent spending. Review existing recurring schedules and use manual collection for one-time requests. The publisher should correct preview execution and stop treating unanswered quotes as permission.
scripts/ari.pyPreview-only deepdive can silently execute paid analysis
Unexpected credit consumption and report creation during an operation documented as non-billing by default. When the main product is absent, the subsequent product note can additionally claim that analysis was downgraded to a quote with no charge even though the helper executed it.
The narrow rating-analysis description conceals a substantially broader operational and billing surface, including instructions to generate paid reports under server-provided first-use exemptions without establishing user-approved spending limits. Although many administrative actions explicitly require consent, the default paid-generation and unanswered-quote paths create concrete authorization gaps rather than merely expanding functionality.
The supplied commands primarily expose a recurring monitoring workflow, including state-changing watch management and price acceptance, rather than the declared star-rating analysis. Historical series could support rating-trend analysis, but that overlap does not account for the undeclared scheduling, competitor-monitoring, and watch-lifecycle capabilities. The underlying script is not supplied, so this assessment is limited to the visible command interface.
The declared purpose covers rating analysis, but the supplied chunk exposes recurring-monitoring lifecycle operations rather than rating breakdown or diagnostic analysis. Persistent scheduling and per-refresh price acceptance are material capabilities not disclosed in the description, rather than merely supporting implementation details. The underlying script is not supplied, so actual billing or data collection cannot be confirmed.
Historical series and digests could support rating analysis, but the snippet primarily exposes a recurring monitoring lifecycle rather than star-rating breakdown or diagnosis. Persistent watch creation, competitor monitoring, and price acceptance are material capabilities not disclosed in the declared purpose. The snippet does not establish that these commands were executed or what specific data the watches collect.
The declared purpose covers rating analysis, but the supplied commands manage monitoring schedules rather than perform that analysis. Configuring recurring, potentially billable collection is a material operational capability not disclosed in the description, rather than merely an internal implementation detail. The underlying script is not supplied, so its precise persistence and billing behavior cannot be independently verified.
The supplied command targets a category leaderboard, not an individual ASIN’s rating breakdown or historical trends. This is a materially different operation from the declared diagnostic purpose. The implementation of ari.py is not supplied, so additional behavior or side effects cannot be established.
The competitor-binding instruction states that adding a competitor starts weekly collection, but this step lacks the explicit recurring-cost disclosure and separate approval required elsewhere. Approval of a one-time comparison could therefore be interpreted as permission to create an ongoing collection relationship, potentially causing repeated charges.
The supplied commands concern watch-service pricing and listing, rather than star-rating breakdowns, historical rating analysis, or negative-review diagnosis. Monitoring and its billing estimates are not declared capabilities, and the snippet does not establish that they are supporting steps for the stated rating-analysis purpose. This assessment is limited to the supplied commands; the implementation of ari.py is not shown.
The supplied commands concern the ARI watch service rather than star-rating analysis. The quote command is explicitly annotated with watchEnabled, perRefresh, and monthlyEstimate, while the list command enumerates watches. Neither command visibly analyzes rating distributions, historical rating changes, or negative-review periods, and watch-service administration is not declared in the description. The underlying script is not supplied, so this assessment is limited to the visible commands.
The command explicitly selects '--type compare' and supplies '--competitor B0BBBBBBBB', indicating a comparative analysis involving another product rather than only the declared single-ASIN rating breakdown. The underlying script is not supplied, so its exact outputs and any additional effects cannot be verified.
The supplied command explicitly selects '--type compare' and supplies '--competitor', indicating a comparative workflow rather than the declared single-product rating diagnosis. The underlying script is not supplied, so its precise analysis, API access, and data handling cannot be verified.
The supplied command targets a single review through the advise subcommand and includes --confirm. This does not match the declared workflow of analyzing an ASIN’s rating distribution and historical trends. The implementation of ari.py is not supplied, so the command’s exact effects—including whether it modifies anything—cannot be established.
The supplied commands focus on an existing watch rather than explicitly analyzing an ASIN’s star ratings. A watch time series could support rating-trend analysis, but digest and event retrieval introduce a monitoring capability not described in the declared purpose. The underlying CLI implementation is not supplied, so the precise data retrieved and any additional side effects cannot be established.
The supplied command targets alerts, while the declared purpose is ASIN-specific rating breakdown and diagnosis. Nothing in the visible chunk requests an ASIN or performs the described analysis. The underlying script is not supplied, so the exact alert behavior and any side effects cannot be established.
The supplied command selects benchmark, which indicates a different operation from the described rating-diagnostic workflow. Nothing in the visible chunk demonstrates star distribution, historical rating analysis, or negative-review timing analysis. This assessment is limited to the command shown; the underlying script could clarify whether benchmarking includes those functions.
The skill explicitly instructs the agent to generate a previously quoted report in a later conversation even when the user never responded to the quote. An idle product record proves neither current intent nor spending authorization, and server auto-confirmation can turn this inference into an actual credit deduction.
The agent-facing command can persistently change account-wide spending-confirmation policy through a PUT request without a separate consent step. This exceeds ordinary rating analysis and can weaken safeguards for later operations, although exploitation requires invoking the mutation command and actual availability depends on the package's command allowlist.
run_analysis converts a missing --confirm into permission to spend credits based solely on the quote response's autoConfirm value. cmd_voc implements a similar bypass that can also trigger collection, contradicting the documented explicit-confirmation contract and making apparent preview invocations chargeable.
This entry references the documented policy of allowing paid operations based solely on a server-provided autoConfirm flag. In conjunction with the described default first-N-operation exemption, this creates a consent gap: requesting analysis can spend account credits without the user approving the price or explicitly enabling automatic spending. This is a documented design concern, not verification that the rating-analysis package implements or exposes these operations.
- 重新发布：各市场首批上架的 1.5.0 包早于免确认修复，新注册的免费版用户仍会被要求先确认报价。
1.5.1 与当前官网下发的修复版一致，市场侧以新版本号覆盖旧包。
- 免确认只认服务端报价返回的 `autoConfirm`；采集报价扣除首次采集免费页；
非美国站首次采集可用赠送积点时不再提示「赠送积点不可用」（行为与修复后的 1.5.0 相同）。
- 命令、字段与计费规则不变，不提高最低支持版本。
The documented policy automatically performs paid collection and report generation for initial requests without an amount ceiling or a price-confirmation step. Respecting explicit ask-first preferences and checking the balance limit exposure, but neither establishes affirmative spending authorization; showing charges afterward does not provide prior consent. Applicability to this specialized skill requires implementation review because the changelog also describes removal of general-purpose commands.
- 行为变更：新用户（注册并验证邮箱后）第一次要 VOC，只给 ASIN 即可（站点默认美国站），
`voc` 直接执行——自动补采集（默认 3 页）、生成报告、按服务端定价扣费并归档，
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
This overlaps the same documented automatic-spending consent gap, rather than identifying an additional vulnerability. Ignoring explanatory text fields and using a typed boolean is not itself unsafe; the concern is that the boolean can authorize uncapped initial paid operations without documented user opt-in. No executable implementation is supplied to establish reachability in this package.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
This is a duplicate detection of the same automatic-spending policy, not an independent attack surface. Parsing autoConfirm rather than inferring policy from prose is reasonable, but a service-generated flag cannot substitute for user consent when the documented default permits initial paid operations without an amount ceiling. The changelog alone does not establish that this specialized skill can invoke those operations.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
The changelog extends the same automatic paid-execution policy to multiple analysis types, potentially broadening unintended credit consumption. Returning charges after generation provides transparency but does not address missing advance authorization under the default exemption. This remains a documented design issue whose presence in the rating-analysis package is unverified.
为 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`
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.
p = sub.add_parser("check", parents=[common], help="验证 Key、账户和积点余额")
p.set_defaults(fn=cmd_check)
p = sub.add_parser("autoconfirm", parents=[common],
help="免确认阈值：autoconfirm 50 / autoconfirm off / autoconfirm default；不带参数查看")
p.add_argument("value", nargs="?", default="")
p.set_defaults(fn=cmd_autoconfirm)