Security audit
Security checks for vulnerabilities and agentic risk
This static-analysis skill also exposes recurring paid monitoring and conflicting instructions about when it may spend your credits.
Prefer a package restricted to the advertised static teardown workflow. Before using this version, require approval before credit spending, keep one-time collection manual, and verify recurring plans remain disabled unless explicitly requested. An unanswered quote should never authorize a later charge.
scripts/ari.pyRecurring paid collection is enabled before pricing disclosure without an executable confirmation gate
If an Agent invokes this setter while attempting to obtain its advertised cost note, or otherwise before obtaining billing consent, the account can incur subsequent recurring collection charges until monitoring is stopped or the service suspends it.
Weekly watches and ongoing monitoring history materially exceed the declared static-analysis-only scope. These are distinct monitoring capabilities, not merely implementation details supporting a one-time page breakdown. The snippet does not establish what metrics are monitored, so it does not support claiming that the code produces specifically prohibited sales, inventory, or return-rate conclusions.
The static-teardown skill includes executable instructions for broader workflows, including paid VOC generation without transaction-specific approval and automatic competitor collection. The final fixed-entry restriction mitigates this, but conflicts with earlier instructions calling the package a general-purpose entry point, leaving an unreliable authorization boundary.
The declared purpose explicitly limits the skill to static product-page analysis. The supplied commands instead expose persistent monitoring and recurring collection controls, which are materially broader capabilities rather than ordinary implementation details of a static analysis. The underlying script is not supplied, so actual collection and billing effects cannot be independently verified, but the scheduling operations shown are outside the declared scope.
The description explicitly limits the skill to static product-page analysis. The supplied command interface instead supports a stateful monitoring lifecycle, including weekly refresh schedules and price-acceptance parameters. These are material capabilities beyond the declared scope. The underlying script is not supplied, so the exact data monitored, billing effects, and external resources accessed cannot be verified; the commands alone do not establish that prohibited sales or inventory conclusions are produced.
The description explicitly limits the skill to static product-page analysis. Weekly watch creation and watch lifecycle management introduce ongoing monitoring and potentially recurring paid refreshes, which are materially different capabilities. The implementation of ari.py is not supplied, so the snippet does not establish what data is collected or whether any charges actually occur; the exposed watch operations nevertheless exceed the declared static scope.
The comparison workflow recommends binding a competitor and states that binding triggers weekly automatic collection, without separately requiring approval of that recurring side effect. Consent to a one-time comparison does not authorize ongoing collection or any associated recurring charges.
The command targets a category leaderboard rather than a user-provided or authorized product page, materially departing from the declared static-analysis scope. The supplied chunk does not reveal the implementation of scripts/ari.py or define neg_rate, so it does not establish that return-rate analysis, external API access, or state-changing actions occur.
The supplied commands expose watch-monitoring and historical-data retrieval, whereas the description explicitly limits the skill to static product-page analysis. These are undeclared capabilities rather than merely supporting details of static analysis. The snippet does not reveal the monitored metrics, so it does not establish that the skill accesses sales, inventory, advertising, orders, or return-rate data.
The supplied commands concern watch functionality and its pricing rather than the declared static analysis of product-page content. Requiring an ARI API key does not disclose this additional capability. The implementation of ari.py is not supplied, so the snippet does not establish that monitoring is activated or that recurring jobs are created.
The declared purpose explicitly limits the skill to static product-page analysis. The supplied commands instead expose watch-related quoting and listing functionality, which is not a supporting implementation detail of the stated analysis task. The underlying Python implementation is not supplied, so the snippet does not establish that it creates watches, performs ongoing monitoring, or accesses sales or inventory data.
The declared scope is limited to static product-page analysis, but the supplied command selects an alerts operation instead. This indicates an undeclared capability. The available code does not establish whether it retrieves, creates, or otherwise manages alerts, nor whether it accesses any explicitly excluded business metrics.
The skill explicitly converts an unanswered historical quote into a later instruction to generate a report, potentially charging credits under server auto-confirm rules. Silence and an idle product record do not establish current intent or payment authorization.
The manifest limits the skill to static analysis of supplied or authorized competitor pages. These instructions instead establish scheduled page refreshes that track prices, BSR, ratings, and listing changes with recurring credit charges. Requiring user confirmation mitigates unauthorized billing, but does not make persistent monitoring consistent with the declared purpose.
The documented collection default enables weekly monitoring unless manual collection is explicitly requested, exceeding the skill's stated static-teardown scope. An agent performing a one-time collection could consequently establish recurring billable activity without specific user authorization; preserving existing schedules does not prevent this risk for newly collected products.
The supplied CLI includes recurring collection and monitoring despite the skill's static-teardown scope. Collection defaults to weekly, and schedule changes and competitor additions can enable ongoing collection without a separate recurring-cost confirmation; command exposure depends on an external whitelist whose absence or malformed contents fail open.
run_analysis converts a missing local confirmation into permission to spend credits when the server returns a truthy autoConfirm value. cmd_voc similarly permits collection and analysis without --confirm, contradicting the documented consent boundary and allowing apparently quotation-only invocations to incur charges.
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.
- 重新发布：各市场首批上架的 1.5.0 包早于免确认修复，新注册的免费版用户仍会被要求先确认报价。
1.5.1 与当前官网下发的修复版一致，市场侧以新版本号覆盖旧包。
- 免确认只认服务端报价返回的 `autoConfirm`；采集报价扣除首次采集免费页；
非美国站首次采集可用赠送积点时不再提示「赠送积点不可用」（行为与修复后的 1.5.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.
- 行为变更：新用户（注册并验证邮箱后）第一次要 VOC，只给 ASIN 即可（站点默认美国站），
`voc` 直接执行——自动补采集（默认 3 页）、生成报告、按服务端定价扣费并归档，
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
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.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
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.
不再停在报价等确认。费用在报告返回的 `charges` 字段透明展示（采集/分析/合计/余额前后）。
- 免确认与否**只认服务端报价返回的 `autoConfirm` 布尔**：服务端策略前 N 次付费生成不看金额上限
（新用户赠送积点按设计覆盖「3 页采集 + 一份 VOC」）；用户自设阈值优先、显式要求「每次先问」
时仍先报价；余额不足不自动。客户端不再从 `autoConfirmNote` 文案或 `autoConfirmRemaining`
自行推断——文案匹配会把 Free 小额提示里的「先确认」误判成用户要求每次询问，恰好挡住新用户。
- 采集报价同口径扣除服务端 `trialFreePages`（首次采集试用免费页），避免新用户被误报「积点不足」。
- 非美国站：服务端 `credits.gift` 策略下用户首次采集不限站点，`credits/balance` 返回 `giftAllSites`，
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.
为 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("autoconfirm", parents=[common],
help="免确认阈值：autoconfirm 50 / autoconfirm off / autoconfirm default；不带参数查看")
p.add_argument("value", nargs="?", default="")
p.set_defaults(fn=cmd_autoconfirm)
p = sub.add_parser("version", parents=[common], help="显示 Skill 版本与渠道（无需 Key）")
p.set_defaults(fn=cmd_version)
Without declared permissions the skill's intent is opaque and cannot be validated.
The auto-confirm rules include first-run exemptions without an amount limit, not just user-configured spending authorization. Treating that server default as consent can consume credits before the user sees a price, contrary to the specialized skill's explicit confirmation requirement.
`voc <ASIN>`（没说站点就用默认的美国站，不要为此追问）。
命中服务端免确认规则（新用户首次体验不看金额 / 账户剩余免确认次数 / 用户自设阈值）且余额充足时，
**直接完成采集 + 生成 + 扣点并归档**，不再停在报价环节。绝不能描述成“先帮你问个价 / 只报价不扣点”。
免确认与否以返回里的 `autoConfirm` 为准，不要自己从提示文案里猜。
- 直接生成成功后，返回结果带 `charges`（采集扣点、分析扣点、合计、扣前/扣后余额）与 `autoConfirmNote`。
**先讲报告，再用一句话转述实际扣点**，不要在拿到结果后再补问「要不要生成」，也不要回头补一次报价。
- 只有在返回 `confirmationRequired: true` 时（余额不足、或用户自行设置了“每次先问”）