权限控制

场景切入：当AI代码助手要访问生产数据库时，谁来按住暂停键？ 上周三晚9点17分，某电商平台的订单履约系统突发告警：orders, shipments, payments 三张核心表在37秒内被连续清空。DBA紧急熔断连接池后发现，罪魁祸首并非人为误操作，而是一次由Claude Code驱动的自动化SQL优化任务——它在分析慢查询日志时，基于一条模糊Prompt（“请优化这个JOIN性能，必要时可重建索引或清理冗余数据”），生成并自动执行了如下语句： DROP TABLE IF EXISTS orders_old; CREATE TABLE orders AS SELECT * FROM orders_backup WHERE updated_at > '2024-05-01'; -- 后续误将 orders_backup 识别为临时表，触发级联DROP... 更致命的是，该任务通过BrowserCat MCP（Model Control Protocol）直连了生产环境数据库连接池，且未启用任何运行时权限拦截。故障导致2.3万笔当日订单状态丢失，回滚耗时4小时。 这不是理论风险，而是正在发生的权限失控。所谓“安全红线”，从来不是写在OKR里的抽象原则，而是具体到每一行代码的边界： ✅ 允许：SELECT COUNT(*) FROM /analytics/daily_orders; ❌ 禁止：DELETE FROM /prod/orders WHERE status = 'pending'; ❌ 禁止：curl -X POST https://api.internal/payments/charge 当时团队的应急响应流程暴露了关键缺口： 检测滞后：依赖数据库审计日志（延迟>90s），而非MCP层实时策略拦截； 阻断失效：BrowserCat默认策略为allow_all，未声明resource_patterns约束； 溯源困难：日志中缺失原始Prompt哈希与模型输出ID的关联字段。 权限控制实战：用MCP Policy Engine定义“能做什么”与“不能做什么” BrowserCat MCP的policy.yaml是权限控制的第一道闸门。它采用声明式配置，将安全规则转化为可版本化、可测试的代码资产。我们摒弃了“先放行再审计”的被动模式，转而用action_whitelist和resource_patterns主动收口。 以下是我们在v1.2策略中落地的生产级配置（已脱敏）： # policy.yaml version: "1.2" rules: - id: "sql_read_only_analytics" description: "仅允许对/analytics/路径下表的只读SELECT" action_whitelist: ["SELECT"] resource_patterns: - "/analytics/.*" deny_if: - contains: ["INSERT", "UPDATE", "DELETE", "DROP", "TRUNCATE"] - regex: ".*;\\s*SELECT.*" # 禁止多语句 - id: "no_system_calls" action_whitelist: [] capability_whitelist: ["http_get", "file_read"] deny_if: - capability: "os_exec" - capability: "network_bind" 关键在于将策略注入模型认知层。我们在Claude Code的system prompt中嵌入策略摘要，并强制其输出携带合规性签名： ...