Security audit
Security checks for vulnerabilities and agentic risk
This relaunch-check skill also exposes automatic credit spending and recurring collection with inconsistent approval controls.
Prefer a corrected package that enforces the dedicated relaunch workflow. If proceeding, set account billing to ask every time, request free quotes explicitly, choose manual collection for one-time work, and review existing schedules and competitor subscriptions. The review concern is spending authorization and scope; the inspected files do not establish malicious intent or unrelated data theft.
scripts/ari.pyRecurring paid collection can be enabled without an enforced confirmation gate
The command can activate ongoing billable collection before obtaining explicit confirmation. Pricing is fetched only after the update succeeds, so the returned cost explanation does not enforce advance approval.
scripts/ari.pyThe documented quote-only deepdive path can execute paid analysis
A caller seeking the documented free preview can consume account credits and generate an archived report. When the main-product target is missing, the output can additionally claim that analysis was downgraded to a quote without charging even though paid execution occurred.
The declared purpose describes a review-based relaunch-readiness assessment, while the supplied commands expose an ongoing monitoring workflow with recurring refresh pricing and competitor tracking. These are material additional capabilities, not merely implementation details of a readiness check. The chunk is reference documentation rather than evidence that the commands have been executed; it also does not demonstrate the declared readiness analysis or minimum-review requirement.
The supplied commands manage persistent monitoring subscriptions rather than perform the declared product-detail and review-based relaunch readiness assessment. Recurring watches, competitor tracking, and price acceptance are material capabilities not disclosed in the description. The chunk does not show review retrieval, enforcement of the minimum review count, or relaunch risk analysis.
The narrow launch-readiness entry point contains competing general-service instructions that permit immediate credit consumption, account-setting changes, and persistent collection workflows. Although the final section requires audit/launch and explicit confirmation, the contradictory executable guidance creates a plausible path to paid actions outside the user's requested assessment; implementation-level capabilities are not independently verified.
The declared purpose describes a relaunch-readiness assessment based on product information and reviews. The supplied commands instead expose an ongoing monitoring lifecycle, including persistent watch state and price acceptance. These are substantive capabilities not disclosed by the description, rather than merely implementation details of a readiness check. The underlying script is not supplied, so this finding concerns the command interface shown and does not establish that any monitoring or charges actually occurred.
The supplied command requests a Kitchen category leaderboard ranked by negative-review rate. This is materially different from assessing relaunch risks for a particular existing ASIN. No ASIN or readiness-assessment operation appears in the command. The implementation of scripts/ari.py is not supplied, so additional data access or side effects cannot be established.
Collecting product details and reviews could support the declared assessment, but configuring persistent, potentially billable weekly monitoring is a distinct operational capability not disclosed in the description. The snippet shows schedule-management commands rather than a readiness assessment. The underlying script is not supplied, so its implementation and actual billing effects cannot be verified.
The comparison instructions describe binding a competitor as a route to automatic weekly collection without placing a separate recurring-cost consent gate at that step. Authorization for a one-time comparison does not authorize persistent collection, and the broader schedule safeguards are not explicitly applied to competitor binding.
The supplied command explicitly selects --type compare and supplies --competitor, indicating a competitive comparison rather than the declared relaunch-readiness assessment. The implementation of the script is not supplied, so review-count enforcement, API-key handling, and any additional effects cannot be determined from this chunk.
The supplied commands expose watch-monitoring and pricing functions, which are not declared in the ASIN relaunch-readiness description. The chunk does not show product-detail or review-based readiness analysis or establish that these watch functions support such analysis. It also does not show enabling monitoring or incurring charges.
The declared purpose describes an ASIN relaunch-readiness assessment, not recurring monitoring or watch-management functionality. The supplied commands expose those additional capabilities without showing a connection to the declared assessment. The chunk does not establish that watches are created, charges are incurred, or sales or advertising budgets are predicted.
The supplied command explicitly selects '--type compare' and provides '--competitor', indicating a competitive comparison rather than the declared review-based relaunch-readiness assessment. The script implementation is not supplied, so review-count enforcement, API access, and any additional behavior cannot be verified.
The supplied commands expose watch-reporting functionality that is not described in the declared purpose. They operate on a watch ID and show no connection to product-detail analysis, review requirements, or relaunch-risk evaluation. Watch data could potentially support such an assessment, but that supporting relationship is not established in this chunk. No sales prediction, advertising budgeting, or supply-chain execution is shown.
The supplied entry point invokes an alerts operation rather than an identifiable product-and-review readiness assessment. This indicates an undeclared capability, although the missing implementation limits certainty: the snippet does not establish whether alerts support the declared assessment or perform a separate function.
run_analysis converts an absent --confirm into authorization when the server supplies a truthy autoConfirm value, contradicting the documented explicit-confirmation boundary. cmd_voc applies the same policy to collection plus analysis, so a call expected to return a quote can instead spend account credits; deepdive also inherits run_analysis behavior.
In context, this documents relying on a server-provided autoConfirm flag to skip confirmation for credit-consuming operations, including default allowances not tied to an explicit user spending limit. A server policy decision is not necessarily user authorization to spend; however, this changelog alone does not establish that the affected commands remain reachable in this specialized package.
- 重新发布：各市场首批上架的 1.5.0 包早于免确认修复，新注册的免费版用户仍会被要求先确认报价。
1.5.1 与当前官网下发的修复版一致，市场侧以新版本号覆盖旧包。
- 免确认只认服务端报价返回的 `autoConfirm`；采集报价扣除首次采集免费页；
非美国站首次采集可用赠送积点时不再提示「赠送积点不可用」（行为与修复后的 1.5.0 相同）。
- 命令、字段与计费规则不变，不提高最低支持版本。
The documented default automatically collects data, generates a report, and deducts credits without confirming the quote, with the first N paid operations explicitly lacking an amount ceiling. Honoring user-set thresholds and checking available balance reduce exposure but do not establish informed spending authorization for users who have configured neither; reporting charges afterward does not prevent unwanted deductions.
- 行为变更：新用户（注册并验证邮箱后）第一次要 VOC，只给 ASIN 即可（站点默认美国站），
`voc` 直接执行——自动补采集（默认 3 页）、生成报告、按服务端定价扣费并归档，
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
Using a structured boolean instead of interpreting explanatory prose is not itself unsafe. The concern is the surrounding policy: that boolean can authorize default paid execution without an explicit user-approved amount ceiling, making this another reference to the same spending-consent issue rather than a separate vulnerability.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
This duplicates the preceding finding at the same location and does not establish an additional attack path. The documented risk is allowing server-defined automatic spending without a user-approved default cap, not avoiding unreliable interpretation of autoConfirmNote or autoConfirmRemaining.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
This extends the same automatic charging policy to several analysis types, potentially consuming credits for operations whose current price the user has not approved. Returning charges afterward provides transparency rather than authorization; actual exposure in this launch-readiness package remains unverified because only the changelog is supplied.
为 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.
def cmd_autoconfirm(args):
"""免确认阈值：不带参数=查看；`autoconfirm 50`=50 积点以内不问；`autoconfirm off`=每次都问；`autoconfirm default`=恢复默认。"""
value = (args.value or "").strip().lower()
if value:
if value in ("off", "ask", "0"):
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.
def cmd_autoconfirm(args):
"""免确认阈值：不带参数=查看；`autoconfirm 50`=50 积点以内不问；`autoconfirm off`=每次都问；`autoconfirm default`=恢复默认。"""
value = (args.value or "").strip().lower()
if value:
if value in ("off", "ask", "0"):
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.
def cmd_autoconfirm(args):
"""免确认阈值：不带参数=查看；`autoconfirm 50`=50 积点以内不问；`autoconfirm off`=每次都问；`autoconfirm default`=恢复默认。"""
value = (args.value or "").strip().lower()
if value:
if value in ("off", "ask", "0"):
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.
limit = int(value)
except ValueError:
emit(error_obj("ARI_BAD_ARGUMENT", 0, "参数不对",
"用法：autoconfirm 50（50 积点以内不问）/ autoconfirm off（每次都问）/ autoconfirm default（恢复默认）"),
args.compact)
return
out = request_json("PUT", "/api/v1/user/autoconfirm", {"limit": limit})
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.
limit = int(value)
except ValueError:
emit(error_obj("ARI_BAD_ARGUMENT", 0, "参数不对",
"用法：autoconfirm 50（50 积点以内不问）/ autoconfirm off（每次都问）/ autoconfirm default（恢复默认）"),
args.compact)
return
out = request_json("PUT", "/api/v1/user/autoconfirm", {"limit": limit})