在 AI 代理系统中，让大语言模型生成并执行代码是一个极具挑战性的安全命题。传统方案依赖完整的容器隔离，但这带来了显著的启动延迟和运维复杂性。Pydantic 团队开发的 Monty 解释器提供了一种创新的轻量级方案：通过 Rust 类型系统在编译期构建安全边界，结合显式的外部函数白名单，从根本上消除参数注入攻击面。本文将深入剖析这一安全架构的工程实现细节。
安全范式的根本转变
传统的代码执行安全模型通常采用「先执行、后隔离」的策略，即允许代码在受控环境中运行，再通过权限限制阻止危险操作。这种方法存在根本性的信任边界模糊问题 —— 运行时权限检查往往无法覆盖所有潜在的攻击向量，特别是在面对精心构造的参数注入时。
Monty 采用了完全不同的安全范式。与其试图在运行时阻止所有危险操作，不如在设计层面直接消除危险操作存在的可能性。这种理念体现在 Monty 的核心设计中：它不是一个带有安全限制的完整 Python 解释器，而是一个为特定用途设计的最小化解释器。
从攻击者视角来看，任何代码注入攻击都需要依赖某种「逃逸机制」—— 利用程序对输入参数的不当处理来执行任意代码。在标准 Python 环境中，攻击者可能尝试通过 os.system、subprocess.run 或文件操作来实现恶意目标。但在 Monty 的执行模型中，这些操作从一开始就不在语言能力范围内，因为所有外部操作都必须通过显式声明的外部函数进行。
Rust 类型系统作为安全边界
Monty 的安全性很大程度上源于其 Rust 实现带来的类型安全保障。Rust 的所有权模型和借用检查器在编译期确保了内存安全，这意味着即使面对恶意构造的输入，解释器本身也不会出现缓冲区溢出或 use-after-free 等典型安全漏洞。
在外部函数调用层面，Rust 的类型系统发挥了关键作用。当开发者将一个函数注册为外部函数时，必须明确定义其参数类型和返回值类型。这些类型信息在解释器初始化时就被固定，任何试图传递不符合类型要求的参数调用都会在执行前被拒绝。
以一个具体的外部函数注册场景为例，假设我们有一个用于获取天气的工具函数 get_weather(city: str) -> dict，在 Monty 中注册这个函数需要显式声明其签名。当 AI 生成的代码尝试调用 get_weather("Beijing") 时，解释器会将这个调用与已注册的函数签名进行匹配。只有完全匹配的情况下，调用才会被转发到宿主环境。如果攻击者试图通过 get_weather("; malicious_command() #") 这样的输入来注入代码，解释器会将其作为字符串字面量处理，而非可执行代码，因为类型检查确保了参数只能是字符串类型。
这种设计将类型安全从静态语言的特性延伸到了动态语言的运行时环境中。Monty 并不依赖 Python 的动态类型系统，而是利用 Rust 的强类型系统在解释器层面实现类型检查。这使得即使面对完全不受信任的输入，类型边界也能提供第一层防护。
参数白名单机制的实现
外部函数白名单是 Monty 安全架构的核心组件。与传统的黑名单机制不同，白名单采用「默认拒绝」的策略 —— 只有明确被添加到允许列表中的函数才能在代码执行过程中被调用。
从工程实现角度来看，白名单机制体现在 MontyRun::new 或 pydantic_monty.Monty 的构造函数参数中。开发者需要通过 external_functions 参数传入允许调用的函数名称列表。这个列表在解释器创建时就被固化，后续的代码执行只能引用这些已声明的函数。
白名单机制的另一个重要特性是其精确性。Monty 不支持通配符或正则表达式匹配来批量授权函数。每个可能的外部调用都必须单独列出，这看似繁琐，实则是安全设计的精妙之处。安全工程中有一条重要原则：最小权限原则 —— 系统应该只授予完成任务所需的最小权限集。白名单机制强制开发者思考并明确每个函数调用的必要性，从而减少不必要的攻击面。
在实际的 AI 代理场景中，白名单机制的应用模式通常如下：开发者首先梳理代理可能需要的所有操作，如数据查询、API 调用、格式化输出等，然后将对应的函数逐个注册到白名单中。例如，一个天气查询代理可能只需要 get_weather 和 format_response 两个外部函数，任何尝试调用其他函数的代码都将被拒绝。
这种设计有效防御了多种常见的代码注入攻击。命令注入攻击通常依赖于在系统调用中插入额外命令，但在 Monty 中，由于系统调用函数根本不在白名单中，攻击代码根本没有执行机会。路径遍历攻击利用文件操作尝试访问敏感文件，同样因为文件操作函数未被授权而无法实施。环境变量注入试图通过读取环境变量获取敏感信息，但在 Monty 的安全模型中，环境变量访问必须通过显式注册的函数进行，而默认配置下这类函数不会被包含在白名单中。
运行时资源控制与纵深防御
除了类型系统和白名单机制，Monty 还实现了多层次的运行时资源控制，作为纵深防御策略的重要组成部分。这些控制措施确保即使存在某些未知漏洞，资源耗尽攻击也能被及时阻止。
资源控制通过追踪器（Tracker）接口实现，开发者可以选择不同的追踪策略来限制解释器的资源消耗。内存使用追踪确保单个代码执行的内存分配不会超过预设阈值，这对于防止内存耗尽攻击至关重要。栈深度追踪防止递归调用导致的栈溢出，这在处理 AI 生成的深层嵌套代码时尤为重要。执行时间追踪确保代码不会无限运行，这对于可能包含无限循环的不可控代码提供了基本保障。
当任何资源指标超过预设限制时，追踪器会触发执行取消操作。这种设计将安全边界从「是否能执行」延伸到「执行多久、消耗多少资源」，提供了更全面的保护。
快照功能是另一个关键的安全特性。Monty 支持在外部函数调用时将解释器状态序列化到字节串，这个功能看似主要用于状态持久化，实际上也具有安全意义。通过快照，开发者可以在执行关键操作前保存状态，以便在检测到异常时回滚到安全点。更重要的是，快照机制强制执行了状态的有界性 —— 解释器状态不能无限增长，因为它必须能够被序列化和反序列化。
工程实践中的参数配置建议
将 Monty 集成到 AI 代理系统时，参数配置直接影响安全效果。以下是经过实践验证的参数设置原则和具体建议。
外部函数的设计应该遵循单一职责原则，每个函数只完成一个明确的任务，避免将多个操作合并到一个函数中。这不仅符合良好的软件设计原则，也能减少单个函数被滥用造成的影响范围。例如，与其提供一个通用的 execute_query(query: str) 函数，不如提供 get_user_data(user_id: str)、list_products(category: str) 等细粒度函数。
输入验证应该在外部函数层进行，而不是依赖 Monty 的类型检查。Monty 的类型检查确保参数类型正确，但不验证内容。例如，一个接受文件路径的函数，类型检查只能确保传入的是字符串，无法验证路径是否在允许范围内。因此，外部函数实现应该包含额外的业务逻辑验证。
资源限制的设置需要根据具体用例调整。对于需要处理大量数据的场景，可以适当提高内存限制，但应该同时实现数据量检查。对于需要复杂计算的场景，栈深度和执行时间的限制应该留有余量。监控和告警机制应该与资源限制配合使用，当执行被取消时记录详细信息用于后续分析。
白名单的维护应该像对待依赖项一样谨慎。每次添加新函数到白名单时，都应该进行安全评估，考虑该函数可能被滥用的方式。建立白名单变更的审批流程，确保没有单点失误导致安全防线崩溃。
架构设计的权衡与局限
理解 Monty 的安全边界需要认识其设计取舍。Monty 的安全性建立在语言能力受限的基础上 —— 它有意不支持类定义、match 语句以及大部分标准库。这种限制使得某些编程任务无法用 Monty 完成，但对于其目标场景 —— 运行 AI 代理生成的代码 —— 是足够的。
另一个需要考虑的因素是外部函数实现本身的安全性。Monty 只能控制解释器内部的执行逻辑，无法保护宿主环境中的函数实现。一个被注册到白名单中的函数如果存在安全漏洞，攻击者仍然可能利用它。因此，外部函数的安全实现是整体安全架构中不可忽视的一环。
白名单机制也带来了运维负担。每次需要新功能时，都需要修改白名单配置，这可能拖慢开发迭代速度。实践中建议建立标准化的白名单变更流程，在安全性和敏捷性之间找到平衡点。
总结
Monty 解释器通过 Rust 类型系统的编译期安全检查、显式的外部函数白名单机制以及运行时资源控制，构建了一个多层次的防御体系来对抗 Python 代码注入攻击。这种安全架构的核心思想不是试图事后阻止危险操作，而是在设计层面消除危险操作存在的可能性。
对于需要在 AI 系统中安全执行大语言模型生成代码的开发者而言，Monty 提供了一个介于完全信任和完全容器隔离之间的中间方案。它保留了 Python 代码的表达能力，同时通过严格的安全边界确保执行可控。在 AI 代理技术快速发展的今天，这类专门为 AI 用例设计的轻量级安全方案值得技术决策者认真考虑。
资料来源：本文技术细节参考自 Pydantic 官方 Monty GitHub 仓库及其安全架构设计文档。