AI 编程代理被“幻觉名称”诱导：Slopsquatting、Phantom Domains 与 HalluSquatting 指向同一类供应链风险
据 BleepingComputer 2026 年 7 月 24 日报道，ActiveState 对近期被称为 Slopsquatting、phantom squatting 与 HalluSquatting 的攻击方式作出解释：这些名称看似不同，核心却是同一种“后绑定”攻击模式。攻击者利用 AI 编程代理对不存在或被幻觉生成的包名、代码仓库名、域名产生信任，在开发工具尝试拉取依赖、访问仓库或解析域名时，将恶意资源塞进软件供应链。对跨境团队而言，这类风险不仅是代码安全问题，也会影响账号系统、支付页面、远程协作环境和访问链路的可信度。
同一攻击逻辑：AI 先“想象”名称，攻击者再占位
来源显示，Slopsquatting、phantom domains 与 HalluSquatting 的共同点，是 AI 工具在生成代码、配置或文档时，可能给出看起来合理但实际并不存在的名称。例如，一个开发代理建议安装某个包、引用某个仓库，或把服务接入某个域名；如果这些名称在真实生态中尚未被注册，攻击者就可能提前占用它们，并放入恶意代码或伪装资源。
这种模式被称为“late-binding”，可以理解为：AI 输出时并未真正确认资源安全存在，后续执行阶段才发生实际绑定。问题在于，开发流水线、自动化部署脚本、远程 IDE 或 CI/CD 工具一旦默认信任这些名称，就可能在无人确认的情况下下载并运行不可信内容。风险点并不只在 AI 是否会“胡说”，而在系统是否会把 AI 的输出直接变成可执行动作。
对跨境账号、支付与远程办公的实际影响
跨境业务通常依赖大量第三方库、云端仓库、API 网关、身份认证服务和支付 SDK。若 AI 编程代理在接入登录、订阅、收款、风控或数据同步功能时引用了幻觉包名，恶意依赖可能进入构建环境，进而窃取令牌、环境变量、API 密钥或会话凭据。对于运营海外平台账号的团队，这可能导致后台权限、广告账户、开发者账号或云资源被连带暴露。
支付环节同样敏感。很多团队会使用 AI 辅助生成结账页、Webhook 处理逻辑、订阅回调或对账脚本。若依赖来源未被验证，攻击者可借机植入篡改请求、截获密钥、伪造回调等能力。一旦影响到收款链路，问题可能从技术安全扩展为资金损失、订单异常与合规审计压力。
远程办公场景也会放大风险。分布式团队常通过云端开发环境、远程终端和自动化机器人完成构建部署，成员可能位于不同国家和网络环境中。访问慢、仓库镜像不一致、DNS 解析差异，都可能让团队更依赖自动补全和 AI 代理建议。此时，如果没有统一的依赖治理策略，个人设备或临时网络环境中的一次错误拉取，就可能进入共享流水线。
防护重点：在拉取前验证，而不是事后补救
ActiveState 提到的思路包括预拉取验证和受治理的依赖管理。换言之，组织应在代码进入流水线前确认包、仓库或域名是否真实、可信、符合策略，而不是等恶意代码已经被安装后再扫描。对使用 AI 开发工具的跨境团队，可重点关注以下做法：
- 禁止 AI 输出直接自动安装依赖：涉及 npm、PyPI、GitHub、容器镜像或私有仓库时，应由人工或策略系统确认来源。
- 建立允许列表或内部镜像：关键项目优先从受控仓库拉取依赖，减少临时从公网解析未知名称。
- 检查包名、仓库名和域名历史：对新出现、低维护、名称近似或刚注册的资源保持警惕。
- 把密钥与权限最小化：即使构建环境拉取到恶意依赖，也应限制其读取支付密钥、账号令牌和生产配置的能力。
- 记录 AI 生成变更：把由 AI 代理新增的依赖、脚本、配置纳入代码审查，而非视为普通自动补全。
访问环境也要纳入安全治理
跨境团队常使用代理、企业 VPN、零信任网关或远程桌面来访问海外代码平台和云服务。这些工具本身不是解决 Slopsquatting 的核心，但稳定、可审计的访问环境有助于减少“临时换源”“随手复制安装命令”“绕过公司镜像”等高风险操作。真正关键的是让开发、访问、账号与支付权限处在同一套可追踪规则下。
总体来看，这次报道提醒开发者：AI 编程代理提高效率的同时，也把“名称可信”变成了新的供应链边界。对跨境业务而言，代码依赖、域名解析、账号权限和支付通道已经高度连接。未来在引入 AI 自动化开发时，团队应把依赖验证前置，把未知包名、仓库名和域名视为需要审查的安全事件，而不是普通的开发细节。