Function Calling 权限怎么收工具裁剪、参数校验与沙箱在给大语言模型集成 Function Calling 工具时由于模型具备触发数据库读写、内部 API 调用及代码执行的能力若缺乏严格的工程隔离与权限控制会带来显著的安全风险。Prompt 注入Prompt Injection攻击常常利用非可信输入尝试诱导模型调用高危工具。若后端系统直接信任并执行模型返回的 Tool Call 决策而缺乏确定性的权限隔离与参数校验容易引发越权访问与恶意指令执行。大模型本身是非确定性的绝对不能把安全防御押宝在 Prompt“请你不要调用高危函数”的软约束上。必须在工程层面建立包括Tool 切片权限隔离、二次 Schema 硬校验与人工确认以及代码执行沙箱在内的三重确定性硬防线。flowchart TD UserPrompt[用户 Prompt 输入 / 外部网页文本] -- LLM[大语言模型 LLM] subgraph DefenseLayer1[防线一: RBAC 动态 Tool Schema 裁剪] RBACFilter[根据当前 User Role 过滤权限] RBACFilter --|仅提供当前用户授权的 Tools| SystemPromptSchema[构造发送给 LLM 的 Tools 定义] end LLM --|输出 Tool Call 决策| ToolInterceptor[Function Call 安全拦截器] subgraph DefenseLayer2[防线二: Pydantic 参数硬校验 高危闸门] ToolInterceptor -- SchemaCheck{Pydantic 类型与正则边界校验} SchemaCheck --|校验失败| Reject1[拒绝执行并反馈 Error 给 LLM] SchemaCheck --|校验通过| AuditCheck{是否为高危操作?\n如: 扣款 / 删除 / 发送邮件} AuditCheck --|是| HumanInLoop[Human-in-the-loop 人工二次确认闸门] end subgraph DefenseLayer3[防线三: 代码/Shell 物理沙箱] AuditCheck --|否 / 人工通过| Sandbox[Restricted Docker Sandbox 离线容器] Sandbox -- ExecResult[受限资源执行并返回产物] end1. 第一道防线基于 RBAC 的动态 Tool Schema 裁剪最安全有效的方法就是根本不让未授权的 Tool Schema 暴露在大模型的视野里。很多开发者图省事把系统里几十个工具包括查询接口、管理员删除接口、转账接口全部丢进系统 Prompt 的tools列表里试图靠 Prompt 叮嘱大模型“普通用户询问时不要调用管理员工具”。这简直是把家门钥匙直接挂在了大门口。Prompt 注入攻击可以非常轻松地绕过这种提示词拦截。工程上的标准做法是在构造 LLM 请求前首先校验当前 HTTP 请求用户的 RBAC 身份。根据用户权限动态剪裁tools数组。对于普通普通权限用户管理员级别的工具在请求阶段就被完全剔除。模型即使想被诱导调用也根本不知道该工具的存在。from typing import List, Dict, Any from pydantic import BaseModel class ToolDefinition(BaseModel): name: str description: str required_role: str # 所需最低角色权限: USER, OPERATOR, ADMIN parameters: Dict[str, Any] # 全局工具注册表 SYSTEM_TOOLS_REGISTRY: List[ToolDefinition] [ ToolDefinition( namequery_user_balance, description查询当前登录用户的账户余额, required_roleUSER, parameters{type: object, properties: {user_id: {type: string}}} ), ToolDefinition( namerefund_user_order, description针对特定订单发起退款, required_roleOPERATOR, parameters{type: object, properties: {order_id: {type: string}}} ), ToolDefinition( namedrop_database_table, description危险: 删除特定数据库表, required_roleADMIN, parameters{type: object, properties: {table_name: {type: string}}} ) ] def filter_tools_for_user(user_role: str) - List[Dict[str, Any]]: 根据用户角色动态切片裁剪暴露给 LLM 的 Tools 列表 role_hierarchy {USER: 1, OPERATOR: 2, ADMIN: 3} current_level role_hierarchy.get(user_role, 0) allowed_tools [] for tool in SYSTEM_TOOLS_REGISTRY: required_level role_hierarchy.get(tool.required_role, 99) # 仅放行当前角色有权限调用的 Tool if current_level required_level: allowed_tools.append({ type: function, function: { name: tool.name, description: tool.description, parameters: tool.parameters } }) return allowed_tools如果一个普通用户的user_role是USER那么发送给 LLM 的 HTTP 载荷里就只有query_user_balance这一个工具。大模型从物理层面丧失了执行高危操作的可能性。2. 第二道防线参数 Pydantic 校验与高危操作二次确认即便用户具有相关权限大模型生成的参数也可能存在越权或者逻辑漏洞。例如模型可能生成了一个user_id../../etc/passwd的恶意路径参数或者把扣款金额传成了负数-1000。拦截器必须对模型导出的 JSON 参数进行严密的 Pydantic 类型与正则表达式校验。同时对于具有破坏性或资金变更的 Tool Call如删除数据、支付转账引入Human-in-the-loop人工在环确认机制。系统拦截该调用向用户前端弹出确认对话框只有用户点击确认后方可真正触发后台执行。from pydantic import BaseModel, Field, field_validator import re class RefundOrderSchema(BaseModel): order_id: str Field(..., description退款订单 ID) amount: float Field(..., gt0, le10000, description退款金额必须大于 0 且不超过 10000) reason: str Field(..., min_length5, description退款原因说明) field_validator(order_id) def validate_order_id_format(cls, v: str) - str: # 强制格式校验防止 SQL 注入与路径穿越 if not re.match(r^ORD-\d{8}-\w{4}$, v): raise ValueError(订单 ID 格式非法必须符合 ORD-YYYYMMDD-XXXX 规范) return v class SecureToolExecutor: 工具安全执行拦截器 staticmethod def execute_refund(raw_args_json: str, is_human_confirmed: bool False) - Dict[str, Any]: # 1. 强制 Pydantic Schema 校验 try: args RefundOrderSchema.model_validate_json(raw_args_json) except Exception as e: return {success: False, error: fLLM 生成参数拦截失败: {str(e)}} # 2. 高危操作 Human-in-the-loop 硬拦截 if not is_human_confirmed: return { success: False, status: REQUIRES_HUMAN_CONFIRMATION, pending_action: { tool: refund_user_order, details: args.model_dump() }, message: 高危退款操作已挂起请在前端界面点击确认。 } # 3. 执行真正的业务扣款逻辑 return {success: True, transaction_id: TX_9901823, refunded_amount: args.amount}3. 第三道防线代码执行工具的 Docker 物理沙箱隔离如果你的 Agent 需要运行 Python 代码或者 Shell 指令如 Data Interpreter 类型 Agent绝不能直接在主机上执行exec()或subprocess.run()。攻击者可以通过一行import os; os.system(rm -rf /)直接摧毁宿主机。对于代码执行类 Tool必须将其投递到资源受限的微型 Docker 沙箱容器中执行。沙箱容器必须具备以下硬约束禁用网络连接NetworkMode: none限制 CPU 核心数与内存最大上限如 256MB防止死循环吃满 CPU 资源将根文件系统设置为只读ReadOnlyRootfs: true仅挂载受限的/tmp目录。通过动态权限切片限制工具暴露范围借助 Schema 硬校验拦截非法参数并利用物理沙箱隔离代码执行环境能够构建安全可控的 Function Calling 工程防护体系。
Function Calling 权限怎么收工具裁剪、参数校验与沙箱在给大语言模型集成 Function Calling 工具时由于模型具备触发数据库读写、内部 API 调用及代码执行的能力若缺乏严格的工程隔离与权限控制会带来显著的安全风险。Prompt 注入Prompt Injection攻击常常利用非可信输入尝试诱导模型调用高危工具。若后端系统直接信任并执行模型返回的 Tool Call 决策而缺乏确定性的权限隔离与参数校验容易引发越权访问与恶意指令执行。大模型本身是非确定性的绝对不能把安全防御押宝在 Prompt“请你不要调用高危函数”的软约束上。必须在工程层面建立包括Tool 切片权限隔离、二次 Schema 硬校验与人工确认以及代码执行沙箱在内的三重确定性硬防线。flowchart TD UserPrompt[用户 Prompt 输入 / 外部网页文本] -- LLM[大语言模型 LLM] subgraph DefenseLayer1[防线一: RBAC 动态 Tool Schema 裁剪] RBACFilter[根据当前 User Role 过滤权限] RBACFilter --|仅提供当前用户授权的 Tools| SystemPromptSchema[构造发送给 LLM 的 Tools 定义] end LLM --|输出 Tool Call 决策| ToolInterceptor[Function Call 安全拦截器] subgraph DefenseLayer2[防线二: Pydantic 参数硬校验 高危闸门] ToolInterceptor -- SchemaCheck{Pydantic 类型与正则边界校验} SchemaCheck --|校验失败| Reject1[拒绝执行并反馈 Error 给 LLM] SchemaCheck --|校验通过| AuditCheck{是否为高危操作?\n如: 扣款 / 删除 / 发送邮件} AuditCheck --|是| HumanInLoop[Human-in-the-loop 人工二次确认闸门] end subgraph DefenseLayer3[防线三: 代码/Shell 物理沙箱] AuditCheck --|否 / 人工通过| Sandbox[Restricted Docker Sandbox 离线容器] Sandbox -- ExecResult[受限资源执行并返回产物] end1. 第一道防线基于 RBAC 的动态 Tool Schema 裁剪最安全有效的方法就是根本不让未授权的 Tool Schema 暴露在大模型的视野里。很多开发者图省事把系统里几十个工具包括查询接口、管理员删除接口、转账接口全部丢进系统 Prompt 的tools列表里试图靠 Prompt 叮嘱大模型“普通用户询问时不要调用管理员工具”。这简直是把家门钥匙直接挂在了大门口。Prompt 注入攻击可以非常轻松地绕过这种提示词拦截。工程上的标准做法是在构造 LLM 请求前首先校验当前 HTTP 请求用户的 RBAC 身份。根据用户权限动态剪裁tools数组。对于普通普通权限用户管理员级别的工具在请求阶段就被完全剔除。模型即使想被诱导调用也根本不知道该工具的存在。from typing import List, Dict, Any from pydantic import BaseModel class ToolDefinition(BaseModel): name: str description: str required_role: str # 所需最低角色权限: USER, OPERATOR, ADMIN parameters: Dict[str, Any] # 全局工具注册表 SYSTEM_TOOLS_REGISTRY: List[ToolDefinition] [ ToolDefinition( namequery_user_balance, description查询当前登录用户的账户余额, required_roleUSER, parameters{type: object, properties: {user_id: {type: string}}} ), ToolDefinition( namerefund_user_order, description针对特定订单发起退款, required_roleOPERATOR, parameters{type: object, properties: {order_id: {type: string}}} ), ToolDefinition( namedrop_database_table, description危险: 删除特定数据库表, required_roleADMIN, parameters{type: object, properties: {table_name: {type: string}}} ) ] def filter_tools_for_user(user_role: str) - List[Dict[str, Any]]: 根据用户角色动态切片裁剪暴露给 LLM 的 Tools 列表 role_hierarchy {USER: 1, OPERATOR: 2, ADMIN: 3} current_level role_hierarchy.get(user_role, 0) allowed_tools [] for tool in SYSTEM_TOOLS_REGISTRY: required_level role_hierarchy.get(tool.required_role, 99) # 仅放行当前角色有权限调用的 Tool if current_level required_level: allowed_tools.append({ type: function, function: { name: tool.name, description: tool.description, parameters: tool.parameters } }) return allowed_tools如果一个普通用户的user_role是USER那么发送给 LLM 的 HTTP 载荷里就只有query_user_balance这一个工具。大模型从物理层面丧失了执行高危操作的可能性。2. 第二道防线参数 Pydantic 校验与高危操作二次确认即便用户具有相关权限大模型生成的参数也可能存在越权或者逻辑漏洞。例如模型可能生成了一个user_id../../etc/passwd的恶意路径参数或者把扣款金额传成了负数-1000。拦截器必须对模型导出的 JSON 参数进行严密的 Pydantic 类型与正则表达式校验。同时对于具有破坏性或资金变更的 Tool Call如删除数据、支付转账引入Human-in-the-loop人工在环确认机制。系统拦截该调用向用户前端弹出确认对话框只有用户点击确认后方可真正触发后台执行。from pydantic import BaseModel, Field, field_validator import re class RefundOrderSchema(BaseModel): order_id: str Field(..., description退款订单 ID) amount: float Field(..., gt0, le10000, description退款金额必须大于 0 且不超过 10000) reason: str Field(..., min_length5, description退款原因说明) field_validator(order_id) def validate_order_id_format(cls, v: str) - str: # 强制格式校验防止 SQL 注入与路径穿越 if not re.match(r^ORD-\d{8}-\w{4}$, v): raise ValueError(订单 ID 格式非法必须符合 ORD-YYYYMMDD-XXXX 规范) return v class SecureToolExecutor: 工具安全执行拦截器 staticmethod def execute_refund(raw_args_json: str, is_human_confirmed: bool False) - Dict[str, Any]: # 1. 强制 Pydantic Schema 校验 try: args RefundOrderSchema.model_validate_json(raw_args_json) except Exception as e: return {success: False, error: fLLM 生成参数拦截失败: {str(e)}} # 2. 高危操作 Human-in-the-loop 硬拦截 if not is_human_confirmed: return { success: False, status: REQUIRES_HUMAN_CONFIRMATION, pending_action: { tool: refund_user_order, details: args.model_dump() }, message: 高危退款操作已挂起请在前端界面点击确认。 } # 3. 执行真正的业务扣款逻辑 return {success: True, transaction_id: TX_9901823, refunded_amount: args.amount}3. 第三道防线代码执行工具的 Docker 物理沙箱隔离如果你的 Agent 需要运行 Python 代码或者 Shell 指令如 Data Interpreter 类型 Agent绝不能直接在主机上执行exec()或subprocess.run()。攻击者可以通过一行import os; os.system(rm -rf /)直接摧毁宿主机。对于代码执行类 Tool必须将其投递到资源受限的微型 Docker 沙箱容器中执行。沙箱容器必须具备以下硬约束禁用网络连接NetworkMode: none限制 CPU 核心数与内存最大上限如 256MB防止死循环吃满 CPU 资源将根文件系统设置为只读ReadOnlyRootfs: true仅挂载受限的/tmp目录。通过动态权限切片限制工具暴露范围借助 Schema 硬校验拦截非法参数并利用物理沙箱隔离代码执行环境能够构建安全可控的 Function Calling 工程防护体系。
