ARTEX（阿特克斯）是一款开源软件，通过连接大型语言模型（LLM）来协调安全检查的计划和工具执行。它并非模型本身的名称，而是一个将模型、执行工具和工作记录捆绑在一起的系统。最近，随着金融界个人信息泄露报道的出现，人们对它的关注度越来越高，但必须区分发现相关痕迹的事实与声称整个攻击由AI独立完成的主张。
在引入时也需要进行同样的区分。即使是辅助安全分析的软件，如果它读取文件、执行命令并向外部模型发送内容，使用该软件的组织也可能承担新的风险。本文通过阅读公开事件资料和官方存储库，解释ARTEX的结构、开发历史、内部审查时的风险以及外部评估中应遵守的界限。这不是基于安装、执行或性能测量的用户评论。
代表图片：AI生成概念图。并非实际的ARTEX界面或金融机构系统的再现。
1. 金融界事件中确认了哪些内容？
事件的存在、ARTEX相关观测、使用痕迹的报道以及最终技术验证是不同的层面。将资料发布日期一并阅读，可以减少初期报道与后续报道看似冲突的问题。
金融委员会在2026年10月2日的资料中表示，继新韩银行信息泄露事件之后，国民银行等也发生了额外损失，并在报告后正在进行现场调查和攻击IP、类型共享。它要求全面掌握所有对外暴露的服务，并检查认证和访问控制。这份官方资料中没有提及ARTEX的名称，也没有认定为完全自主的AI攻击。金融委员会发布
10月2日，首尔经济报道称，在据推测用于攻击的服务器的HTML标题中，观测到了ARTEX的中文渗透测试控制台标记。当时的报道中附带说明，尚未确认其是否实际用作攻击工具。这应被解读为表明相关环境可能存在的观测。首尔经济初期报道
10月3日，先驱经济援引金融安全院相关人士的话称，在新韩银行日志和攻击IP反向追踪中确认了ARTEX的使用痕迹。该相关人士解释说，攻击并非AI在没有人为干预的情况下独立完成。因此，忽视后续报道而声称完全没有使用依据也是不准确的。先驱经济后续报道
然而，本文并未获取公开的原始日志或最终技术报告并进行独立复现和验证。仅凭这些资料，无法确定使用了哪个版本和模型，哪个功能在哪个银行的事件中参与了多少，以及自动化程度如何。也缺乏足够的证据通过工具的中文界面或开发账户来推断攻击者的国籍。
| 资料 | 确认或传达内容 | 此资料无法确定的内容 |
| — | — | — |
| 金融委10月2日发布 | 金融界入侵、现场调查、威胁信息共享和访问控制检查 | ARTEX的参与和AI自动化程度 |
| 首尔经济10月2日报道 | 推测服务器的ARTEX控制台标记观测 | 在实际攻击过程中的作用 |
| 先驱经济10月3日报道 | 金融安全院相关人士说明确认了使用痕迹 | 原始证据的独立验证、使用的模型和整体自动化 |
这种区分并非为了缩小事件。要确定需要防御什么，就不能混淆已确认的损害和对工具的推测。对实际请求的服务器端访问控制和外部服务列表检查，无论是否涉及特定的AI工具，都是必要的。
2. 一个连接多个组件的系统，而非单一模型
本文分析的项目是GitHub上的Autumn-27/ARTEX。官方存储库将其介绍为一个结合了Go后端、Next.js前端、PostgreSQL数据库和多个LLM代理的系统。代理是连接模型响应与工具调用的程序。官方存储库
其宏观结构可以理解为：规划部分、执行任务部分、存储结果部分和人工审查部分。规划代理负责分解下一步要检查的工作，执行代理则使用工具处理分配的任务。界面显示进度和结果。“自动化”一词指的是这种重复，并不意味着人工目标指定、设置和审查的消失。
记录分为两个视角：资产图是表示存在哪些目标和服务的连接列表，而探索图是表示本次任务中思想、观测和发现如何连接的记录。了解目标和确认目标的内容是分开管理的。这两个图是相互连接的，但数据结构不同。
基于官方文档重构的概念图。根据README的系统架构和执行代理源代码简化。它不代表攻击路径。
公开源代码中的执行代理配置了文件读写、编辑和Bash等工具。Bash是执行操作系统命令的通道。虽然它为每个任务创建了专用目录，但仅仅划分目录并不能阻止进程访问其他文件或网络。因此，执行环境的权限是重要的审查对象。worker.go
3. 公开历史中的发展与安全修正
根据GitHub元数据，该存储库的创建时间是2026年7月26日，发布列表中也显示同日发布了v0.1.0。这是当前公开存储库和分发记录的起点，并非开发启动日期的证明。“竞赛获奖项目”的描述在存储库的自我介绍中，本文未独立验证竞赛结果原文。存储库元数据 · 发布列表
调查时点的最新正式发布是2026年9月24日发布的v0.3.14。本文分析的main分支是提交b55ceb1，其中包含了后续更改。因此，不应将main的当前行为直接描述为v0.3.14发布版本的行为。在实际审查中，应固定发布、提交和镜像标识符，并检查该版本的设置。
变更历史中包含了一些项目，表明安全控制为何需要持续验证。以下内容是项目记录的过去问题和修正，不应被解读为所有当前版本都存在漏洞或这些是事件原因的主张。官方CHANGELOG
| 版本·日期 | 历史记录的变更 | 待审查问题 |
| — | — | — |
| v0.3.10 · 9月13日 | 修复了其他任务资产混入目标查询的问题 | 任务目标分离是否实际保持？ |
| v0.3.11 · 9月15日 | 完善了模型审查结果的代码块处理 | 如果无法解释审查结果，如何处理？ |
| v0.3.12 · 9月17日 | 将记录代理的默认地址限制为localhost | 界面和代理暴露在哪个网络？ |
| v0.3.13 · 9月19日 | 缓解了因审查输出截断导致的错误允许路径，增加了任务特定的允许/阻止规则 | 失败时阻止和目标限制是否独立验证？ |
核心并非修正项的数量。模型输出解释、任务范围查询、网络暴露等不同层面都可能出现问题。更新是必要的改进，但一次更新的事实并不能保证整个执行环境的安全性。
4. 内部使用可能使组织成为攻击目标
引入安全工具的风险与特定项目存在后门的意思不同。本次阅读分析并未确认恶意后门。风险在同时考虑执行权限、外部连接、记录敏感性和供应链时会具体显现。
安装路径和供应链
供应链不仅指程序，还包括依赖项、容器、更新等获取可执行文件的路径。官方配置使用外部容器镜像和PostgreSQL，并将本地数据和技能目录连接到容器。如果基础镜像标签发生变化，即使重复使用相同的设置，可执行文件也可能不同。docker-compose.yml
即使在学习审查环境中，也建议检查来源、版本和哈希，并且不要在日常工作设备上直接运行未经审查的安装脚本。组织的源代码存储库、SSH密钥、云凭证和浏览器会话不应与学习执行环境共享。这并非声称ARTEX窃取此类信息，而是减少被篡改或获得过度权限的可执行文件损害范围的通用控制。
模型连接和详细记录
模型连接源处理API密钥和用户自定义API地址/代理设置。连接外部模型意味着请求中包含的内容可能会传输到选定的提供商或中继点。需要确认批准哪些提供商和地址，内容最小化程度如何，以及保留策略是什么。仅仅因为源代码具有连接功能，并不能确定特定安装的实际传输内容。provider.go
详细的LLM记录功能根据设置将请求、响应和原始通信正文存储在数据库中。正文记录和令牌使用量记录是分开的。执行过程中屏幕上不可见的信息也可能保留在记录中，因此需要单独制定保留期限、访问权限、删除和备份策略。llmrec.go
这就是为什么只使用合成数据，而不使用实际客户响应、操作日志、合同资料、账户和密钥的原因。仅仅关闭记录按钮并不能阻止内容发送到外部模型。外部传输和本地存储是不同的验证项。
工具权限和提示注入
提示注入是将要读取的资料中的句子视为对代理的命令的风险。当公共页面、存储库内容或工具响应是任务资料的一部分时，尤其需要注意。这并非ARTEX中重现的漏洞报告，而是在读取外部资料并调用实际工具的结构中需要考虑的威胁模型。
例如，即使学习资料中混入了诱导执行的句子，这些句子也不能替代人工批准或组织策略。应从外部限制文件、进程和网络权限，并在执行前验证批准和记录。在提示中写入注意事项是必要的说明，但无法创建操作系统的权限边界。
网页界面和网络边界
Compose示例为界面/API端口和限制为localhost的代理端口分别指定了端口。界面/API的暴露范围需要查看主机防火墙和部署设置。使用容器并不意味着默认会阻止外部通信或与组织网络隔离。学习网络应与业务网络分离，并应能够限制除已批准模型连接之外的通信。官方Compose设置
5. 即使有审批界面，也并非所有行为都会自动阻止
分析的main源代码包含允许、阻止或请求人工处理工具调用的规则。然而，其行为取决于应用规则的工具列表和审查功能设置。如果对于不符合规则的调用，模型审查已关闭或未连接，则存在允许路径；模型失败或无法解释的结果将遵循配置的失败策略。guard.go · intercept.go
因此，不应以“有审批功能就安全”的确认来结束。必须在隔离环境中验证哪些调用是审查对象，审批等待期间实际执行是否停止，审查失败和超时时会发生什么，以及中断后已开始的任务如何处理。本文不涉及如何禁用或绕过审查功能。
基于官方代码重构的运营审查图。审批源、模型连接、记录存储是依据。这并不意味着所有控制都默认提供或激活。
组织可以明确判断标准。如果验证需要连接到工作设备或操作账户，则应再次缩小范围；如果无法阻止未经授权的目的地通信，则应暂停执行审查。如果设计需要实际客户数据，则应首先确认是否可以使用合成数据替代。安全工具的便利性与其使用环境的安全性必须分开评估。
6. 如何将其用于外部渗透测试？
这里首先是工具的使用限制。README中的作者声明将允许范围仅限于个人学习、代码研究和本地隔离原理验证。它明确禁止对网站、在线服务、网络系统进行实际测试，以及进行实战渗透测试或在生产环境中使用，即使拥有资产或已获得许可。因此，本文不建议将ARTEX投入外部实际服务。README使用限制
存储库许可证是AGPL-3.0，README也区分了开源许可证本身和单独的作者使用声明。不应将两份不同的文档合并为一句话，从而得出所有商业用途都被禁止或只要获得书面许可就没问题的结论。单独声明的法律效力或适用关系超出本技术文章的判断范围。组织应在法务和安全审查中同时确认这两份文档。LICENSE原文
ARTEX结构中获得的一般操作原则可应用于外部评估任务。实际使用应在单独选择允许该目的的工具和合同后进行。以下是与工具无关的评估计划示例，并非在实际目标上执行ARTEX的指南。
- 书面确定范围。以文档形式固定资产所有者的批准、目标列表、时间、允许活动和排除活动、负责人以及中断权限。不应假定将合同客户的运营数据发送给模型的权限会自动包含在内。
- 隔离环境。不重复使用工作账户和设备；使用经批准的测试账户、合成数据和单独的工作空间。阻止访问不必要的文件和目的地。
- 执行前人工判断。区分模型建议和实际工具执行。仅执行经过范围和影响审查的操作，并将失败或不确定的结果转为中断或人工审查。
- 最小化证据保留。关联时间、目标、批准依据、观测结果以及修改后的重新确认结果。报告中不附带原始个人信息或不必要的通信内容。
- 首先确定中断条件。如果确认超出范围的目标、实际个人信息泄露、未经授权的通信、服务异常或日志缺失，则停止。将结果分为已验证、未确认或需要重新确认，并传达给负责人。
如果学习ARTEX本身，应将范围限制在本地隔离环境中使用合成资产和记录。学习目标可以包括验证操作边界，例如审批等待、阻止超出范围的请求、记录保留/删除和中断操作。没有必要为了学习其功能而针对实际金融机构或客户系统进行测试。
7. 金融界防御首先需要改变什么？
仅仅将特定工具的名称添加到黑名单中，很难解决问题。无论是人工使用还是自动化工具使用，服务器都必须判断请求者是否有权访问相关信息。认证是验证“谁”的过程，授权是验证该人是否可以使用特定信息或功能的过程。
金融委员会要求全面掌握外部服务并检查访问控制，这与这个基本问题相关。即使是员工或合作伙伴使用的服务，如果可以从外部访问，也属于管理对象。不应仅仅因为有正常登录就允许所有数据查询，而应同时审查不必要的响应信息和异常查询。这并非对个别事件最终原因的断定性说明，而是从实务角度解读公开应对方向。金融委应对方向
ARTEX的公开结构表明AI可以连接重复任务的规划和执行。然而，无论本次事件中具体哪些功能发挥了作用，防御组织都必须加强对外部资产的访问控制和对自动化请求的观测能力。内部研究该工具的组织必须减少模型数据和执行权限，并同时验证人工审批和独立隔离。区分这两个方向，可以在不夸大事件报道的同时，提出实际准备所需的关键问题。
参考资料和确认范围
- 金融委员会，金融界网络威胁应对发布：事件应对和外部系统检查的官方依据。
- 首尔经济，10月2日ARTEX控制台标记报道 · 先驱经济，10月3日使用痕迹报道：按日期区分观测和后续报道。
- Autumn-27/ARTEX · 发布 · 固定提交CHANGELOG：结构、部署历史和修正背景。
- 固定提交的源代码树：对文件、工具、模型、审批和记录连接的阅读分析。并非重现事件证据的资料。
- AGPL-3.0 LICENSE：与README中单独使用声明一并审查的原文。
仅使用了官方资料和公开存储库。未包含实际内部日志、客户归属资料、攻击命令或入侵程序。区分了发布版本和main分支，如果后续调查中事件的工具参与范围发生变化，本说明也应更新。
发表回复