企业级AI Agent安全架构：超越“人在回路”的纵深防御实践
·
想象一下这个场景：你部署了一个企业级的AI Agent，它被授权访问公司的数据库、邮件系统和内部文档。理论上，它每次执行敏感操作前，都会弹出一个确认框，等待“Human in the Loop”（人在回路）的批准。但现实是，你的员工小王，每天要处理上百个这样的弹窗。从最初的谨慎审核，到后来的快速浏览，再到最后，他几乎是在“闭着眼睛点确认”——因为流程太繁琐，信任被滥用，安全机制形同虚设。
这不是危言耸听，而是许多企业在引入AI Agent后，正在或即将面临的真实困境。当“人在回路”这个最后的安全防线，因为用户体验、流程设计或认知负荷问题而失效时，企业的核心资产和数据安全，还能依靠什么？
本文将深入探讨企业级AI Agent安全架构中，“Human in the Loop”机制为何会失灵，以及当它失灵后，我们必须构建哪些更深层、更自动化的安全防线。我们将从一个开发者和架构师的视角出发，不仅分析问题，更会提供一套可落地的安全增强方案，包括 权限沙箱、行为审计、意图验证和动态策略引擎 等核心组件的设计与实现思路。
如果你正在规划或已经部署了企业内部的AI Agent，那么这篇文章将帮助你重新审视安全体系，避免让“安全确认”沦为一次毫无意义的鼠标点击。
1. “Human in the Loop”为何会失灵？—— 从安全机制到流程负担
“Human in the Loop”（HITL）被广泛认为是AI系统，尤其是自主Agent（智能体）的安全基石。其理想模型是：AI负责分析和建议，人类负责最终决策和批准。然而，在企业级高频、复杂的应用场景中，这个理想模型极易崩塌。
失灵原因一：警报疲劳与认知超载 这是最直接的原因。当Agent需要处理的日常任务（如数据查询、报告生成、邮件分类）数量巨大时，与之对应的确认请求也会呈指数级增长。员工面对源源不断的弹窗，会产生“警报疲劳”，从认真审核变为机械式点击“同意”。心理学上的“决策疲劳”在此体现得淋漓尽致——人的判断力会随着决策次数的增加而下降。
失灵原因二：确认信息模糊与决策支持不足 许多系统的确认弹窗设计简陋，仅显示“Agent将执行XXX操作，是否继续？”。缺乏上下文（如为什么要执行、依据什么数据、潜在影响是什么），人类审核者根本无法做出有效判断。这相当于让一个保安在不清楚访客目的和背景的情况下决定是否放行，其决策质量可想而知。
失灵原因三：流程延迟与效率悖论 企业引入Agent的初衷往往是提升效率。但如果每个操作都需要人工确认，尤其是在跨时区协作中等待负责人批准，可能会造成严重的流程阻塞。这迫使团队为了“效率”而放宽安全策略，甚至设置共享账号进行“一键审批”，完全背离了HITL的初衷。
失灵原因四：过度信任与责任分散 当Agent在大多数情况下都表现可靠时，人类会产生过度信任，认为“系统通常是对的”。同时，“反正是系统提议，我只是点个确认”的想法会导致责任分散，削弱个体的责任感，使得审核环节流于形式。
因此，我们不能将企业Agent的安全完全寄托在一个可能失效的“确认按钮”上。必须构建一个 纵深防御体系 ，即使HITL环节被绕过或误操作，系统本身仍具备强大的内生安全能力。
2. 超越“确认按钮”：企业Agent安全架构的四大核心支柱
当HITL不可全信时，我们需要在Agent的架构层面嵌入更稳固的安全控制。以下四大支柱构成了一个健壮的企业级Agent安全框架：
支柱一：最小权限与沙箱环境（执行隔离） 这是最根本的原则。Agent不应该拥有其完成任务所需之外的任何权限。
- 身份与访问管理（IAM） ：为每个Agent实例分配独立的、权限最小的服务账号或API密钥。避免使用高权限的共享账号。
- 操作沙箱 ：对于文件操作、代码执行等高风险动作，必须在隔离的沙箱环境（如Docker容器、轻量级虚拟机）中运行。沙箱应限制网络访问、文件系统读写范围和对宿主机的影响。
- 资源配额 ：限制Agent单次或周期内可调用的API次数、消耗的CPU/内存、访问的数据行数等，防止资源滥用或无限循环。
支柱二：持续的行为审计与异常检测（全景监控） 所有Agent的操作都必须被完整、不可篡改地记录下来，并实时分析。
- 结构化日志 ：记录
时间戳、Agent ID、操作类型、目标资源、请求参数、执行结果、审批人（如果有）。日志应输出到专用的、Agent无法访问的安全日志平台。 - 行为基线建模 ：通过机器学习或规则引擎，为每个Agent建立正常行为模式基线（例如，财务Agent通常在上班时间访问A数据库的表B）。任何偏离基线的操作（如下班后访问、访问未授权表、高频重复操作）都应触发高等级告警。
- 关联分析 ：将多个Agent的行为或单个Agent的多个步骤关联起来，识别复杂的攻击模式或内部威胁。
支柱三：意图验证与输入/输出过滤（内容安全） 确保Agent接收的指令和产出的内容是安全的、符合预期的。
- 指令注入防御 ：对用户或上游系统发给Agent的指令进行清洗和验证，防止通过精心构造的指令诱骗Agent执行恶意操作（类似SQL注入）。
- 输出内容过滤与审查 ：对Agent生成的文本、代码、SQL语句等进行安全检查。
- 敏感信息检测 ：防止Agent在输出中泄露身份证号、手机号、密钥等。
- 恶意代码检测 ：如果Agent生成代码，需进行静态扫描。
- 策略符合性检查 ：确保输出符合公司合规要求（如不包含歧视性言论）。
- 动态上下文校验 ：在执行动作前，Agent应能根据最新上下文（而非仅凭历史记忆）对操作的必要性和安全性做一次自我复核。
支柱四：动态策略引擎与自适应控制（智能管控） 安全策略不应是静态的配置，而应根据上下文动态调整。
- 基于风险的动态授权 ：将操作按风险分级（低、中、高）。低风险操作（如查询公开信息）可设置为自动执行并事后审计；中风险操作（如修改非核心配置）触发轻量级确认或二次验证；高风险操作（如删除数据、转账）则必须强制HITL，且确认界面需提供详尽的风险分析报告。
- 上下文感知 ：策略引擎应能感知上下文，例如，在常规办公时间 vs. 深夜，从公司内网 vs. 公网IP发起请求，其安全策略的严格程度应自动调整。
- 熔断与降级 ：当检测到异常行为激增或系统自身出现故障时，策略引擎应能自动触发熔断机制，暂停所有或特定Agent的操作，或将其切换到仅限查询的“安全模式”。
这四大支柱与HITL的关系是 互补与增强 。HITL作为一道重要的、尤其是针对极高风险操作的“手动阀门”，而其他支柱则构建了自动化的、无处不在的“安全管网”和“监测仪表盘”。
3. 从设计到实现：构建一个具备内生安全的Agent系统
让我们以一个“企业数据分析Agent”为例，它被允许查询数据库并生成报告。我们将展示如何为其实现上述安全支柱。
3.1 系统架构概览
[用户/系统] -> (指令) -> [网关/代理层] -> (安全校验、意图解析) -> [安全策略引擎] -> [Agent核心]
|
v
[权限服务] [审计日志中心] [沙箱执行环境]
|
v
[数据库/邮件/API等外部资源]
3.2 核心组件实现示例
示例一：基于角色的权限控制与沙箱（支柱一）
我们为Agent定义一个权限模型，并在执行数据库查询时使用连接池隔离。
# agent-security-policy.yaml (策略配置文件)
agents:
- id: "data-analyst-agent-01"
name: "财务数据分析助手"
role: "data_analyst"
permissions:
- resources: ["db://finance/readonly_sales", "db://finance/readonly_customer"]
actions: ["SELECT"]
conditions: "work_hours(9,18) AND row_limit(1000)"
- resources: ["api://internal/report/generate"]
actions: ["POST"]
sandbox:
type: "docker"
image: "company/python-data:3.9-safe"
network_policy: "deny-external" # 禁止外网
volume_mounts:
- source: "/tmp/agent-output"
target: "/output"
read_only: false
# permission_middleware.py (权限检查中间件)
import re
from datetime import datetime
from functools import wraps
class PermissionDeniedError(Exception):
pass
class AgentPermissionChecker:
def __init__(self, policy_config):
self.policy = self._load_policy(policy_config)
def check(self, agent_id, action, resource, context=None):
"""检查Agent是否有权限执行操作"""
agent_policy = self.policy.get(agent_id)
if not agent_policy:
raise PermissionDeniedError(f"Agent {agent_id} not found in policy.")
for perm in agent_policy['permissions']:
# 1. 资源匹配 (支持通配符)
if not self._match_resource(resource, perm['resources']):
continue
# 2. 操作匹配
if action not in perm['actions']:
continue
# 3. 条件匹配 (动态上下文)
if not self._eval_conditions(perm.get('conditions', ''), context):
continue
# 所有检查通过
return True
raise PermissionDeniedError(f"Agent {agent_id} is not allowed to {action} on {resource}.")
def _match_resource(self, target, pattern_list):
for pattern in pattern_list:
if pattern.endswith('*'):
if target.startswith(pattern[:-1]):
return True
elif target == pattern:
return True
return False
def _eval_conditions(self, condition_str, context):
if not condition_str:
return True
# 简单实现：解析条件如 work_hours(9,18) AND row_limit(1000)
# 实际项目应使用更强大的规则引擎，如 OPA (Open Policy Agent)
try:
hour = datetime.now().hour
if "work_hours(9,18)" in condition_str:
if not (9 <= hour < 18):
return False
if "row_limit" in condition_str and context:
# 假设context中包含查询的预估行数
limit = int(re.search(r'row_limit\((\d+)\)', condition_str).group(1))
if context.get('estimated_rows', 0) > limit:
return False
return True
except Exception:
# 条件解析失败，出于安全考虑，拒绝
return False
# 使用装饰器保护Agent的关键方法
def require_permission(action, resource_key_fn):
def decorator(func):
@wraps(func)
def wrapper(self, *args, **kwargs):
resource = resource_key_fn(self, *args, **kwargs)
context = {'estimated_rows': kwargs.get('limit', 100)} # 示例上下文
self.permission_checker.check(
agent_id=self.agent_id,
action=action,
resource=resource,
context=context
)
return func(self, *args, **kwargs)
return wrapper
return decorator
# 在Agent类中使用
class DataAnalystAgent:
def __init__(self, agent_id):
self.agent_id = agent_id
self.permission_checker = AgentPermissionChecker.load_from_yaml('agent-security-policy.yaml')
@require_permission(action="SELECT", resource_key_fn=lambda self, db, table: f"db://{db}/{table}")
def query_database(self, db, table, sql_where, limit=100):
# 只有权限检查通过后，才会执行到这里
# 此处连接的是该Agent专属的、只读的数据库连接池
connection = self._get_sandboxed_db_connection(db)
# ... 执行查询
return results
示例二：结构化审计日志（支柱二）
所有操作，无论成功与否，都必须记录。
# audit_logger.py
import json
import time
from datetime import datetime
from elasticsearch import Elasticsearch # 示例使用ES，也可用其他日志系统
class AuditLogger:
def __init__(self, es_host='localhost:9200'):
self.es = Elasticsearch([es_host])
self.index_prefix = "agent-audit-"
def log_operation(self, agent_id, operation, resource, status, details, user_context=None):
"""记录一次操作审计日志"""
log_entry = {
"@timestamp": datetime.utcnow().isoformat() + "Z",
"agent.id": agent_id,
"event.action": operation, # 如 QUERY, UPDATE, SEND_EMAIL
"event.resource": resource,
"event.outcome": status, # success, failure, denied
"event.duration": details.get('duration_ms', 0),
"user": user_context or {},
"request": details.get('request'),
"response": details.get('response'),
"risk_level": details.get('risk_level', 'medium'),
"policy_decision": details.get('policy_decision'), # 记录策略引擎的决策结果
"host.name": details.get('hostname'),
"source.ip": details.get('source_ip')
}
# 移除可能过大的字段或敏感信息（在details中已处理）
index_name = f"{self.index_prefix}{datetime.utcnow().strftime('%Y.%m.%d')}"
try:
self.es.index(index=index_name, document=log_entry)
except Exception as e:
# 审计日志失败是严重事件，应降级到本地文件并告警
self._fallback_log_to_file(log_entry, e)
def _fallback_log_to_file(self, log_entry, error):
with open('/var/log/agent-audit-fallback.log', 'a') as f:
f.write(json.dumps({
**log_entry,
"_fallback_reason": str(error),
"_local_timestamp": time.time()
}) + '\n')
# 在权限检查中间件和Agent方法中集成审计
def require_permission(action, resource_key_fn):
def decorator(func):
@wraps(func)
def wrapper(self, *args, **kwargs):
start_time = time.time()
resource = resource_key_fn(self, *args, **kwargs)
context = kwargs.get('context', {})
status = "denied"
details = {'request': {'args': args, 'kwargs': kwargs}}
try:
self.permission_checker.check(self.agent_id, action, resource, context)
status = "success"
result = func(self, *args, **kwargs)
details['response'] = {'type': 'success', 'data_summary': f"rows: {len(result) if result else 0}"}
return result
except PermissionDeniedError as e:
status = "denied"
details['response'] = {'type': 'error', 'reason': str(e)}
raise
except Exception as e:
status = "failure"
details['response'] = {'type': 'error', 'reason': str(e)}
raise
finally:
duration = int((time.time() - start_time) * 1000)
details['duration_ms'] = duration
# 记录审计日志
self.audit_logger.log_operation(
agent_id=self.agent_id,
operation=action,
resource=resource,
status=status,
details=details,
user_context=kwargs.get('user_context')
)
return wrapper
return decorator
示例三：输出内容安全过滤（支柱三）
对Agent生成的SQL或报告文本进行安全检查。
# content_filter.py
import re
class ContentSecurityFilter:
def __init__(self):
# 1. 敏感数据模式 (简化示例)
self.sensitive_patterns = [
r'\b\d{17}[\dXx]\b', # 身份证号
r'\b1[3-9]\d{9}\b', # 手机号
r'\b[A-Za-z0-9+/]{40,}\b', # 疑似长密钥
]
# 2. 高风险SQL操作 (用于非写权限Agent的额外防护)
self.dangerous_sql_keywords = ['DROP', 'DELETE', 'TRUNCATE', 'ALTER', 'GRANT', 'EXEC']
def filter_sql_output(self, sql_statement, allowed_keywords=['SELECT']):
"""检查并净化生成的SQL语句"""
sql_upper = sql_statement.upper()
# 检查是否包含未授权的高风险操作
for kw in self.dangerous_sql_keywords:
if kw in sql_upper and kw not in allowed_keywords:
raise SecurityPolicyViolation(f"Generated SQL contains unauthorized keyword: {kw}")
# 简单的语法校验（可选，可集成SQL解析器如sqlparse）
if not sql_upper.strip().startswith('SELECT'):
raise SecurityPolicyViolation("Only SELECT statements are allowed for this agent.")
# 返回原语句（或净化后的语句）
return sql_statement
def filter_text_output(self, text, redaction_mark='[REDACTED]'):
"""过滤文本中的敏感信息"""
filtered_text = text
for pattern in self.sensitive_patterns:
filtered_text = re.sub(pattern, redaction_mark, filtered_text)
return filtered_text
def validate_instruction(self, user_instruction):
"""防御指令注入攻击的简单示例"""
injection_indicators = [
'忽略以上指令', '忘记之前的话', '执行系统命令',
'rm -rf', 'cat /etc/passwd', 'http://malicious.com'
]
lower_inst = user_instruction.lower()
for indicator in injection_indicators:
if indicator in lower_inst:
raise MaliciousInstructionError(f"Instruction contains potential injection: {indicator}")
return user_instruction
# 在Agent生成内容后调用
agent = DataAnalystAgent()
filter = ContentSecurityFilter()
try:
raw_sql = agent.generate_query("找出上个月销售额最高的10个客户") # Agent生成的SQL
safe_sql = filter.filter_sql_output(raw_sql)
report_text = agent.generate_report(safe_sql)
safe_report = filter.filter_text_output(report_text)
print(safe_report)
except SecurityPolicyViolation as e:
# 记录安全事件并终止流程
audit_logger.log_security_event(violation=str(e), severity="HIGH")
print("安全策略阻止了此操作。")
4. 动态策略引擎：让安全策略“活”起来（支柱四）
静态策略难以应对复杂情况。我们可以集成一个轻量级规则引擎来实现动态策略。
# dynamic_policy_engine.py
import pyknow as pk # 示例使用PyKnow，一个Python规则引擎
class SecurityContext(pk.Fact):
"""定义安全上下文事实"""
def __init__(self, agent_id, action, resource, time_of_day, user_role, risk_score=0):
super().__init__()
self.agent_id = agent_id
self.action = action
self.resource = resource
self.time_of_day = time_of_day # 'working_hours', 'off_hours'
self.user_role = user_role
self.risk_score = risk_score
self.decision = "pending" # 最终决策: allow, deny, require_approval
self.required_approval_level = None # 如需审批，级别是什么
class DynamicPolicyEngine(pk.KnowledgeEngine):
@pk.Rule(SecurityContext(action='DELETE',
resource=pk.MATCH.r & pk.TEST(lambda r: 'customer' in r),
time_of_day='off_hours'))
def rule_high_risk_delete(self, ctx):
"""非工作时间删除客户数据属于极高风险"""
self.modify(ctx, decision="deny", risk_score=95)
print(f"[Policy] DENY: High-risk delete operation detected.")
@pk.Rule(SecurityContext(action='SELECT',
resource=pk.MATCH.r & pk.TEST(lambda r: 'finance' in r),
risk_score=pk.BETWEEN(30, 70)))
def rule_medium_risk_finance_query(self, ctx):
"""中等风险的财务查询需要经理审批"""
self.modify(ctx, decision="require_approval", required_approval_level="manager")
print(f"[Policy] REQUIRE APPROVAL (Manager): Medium-risk finance query.")
@pk.Rule(SecurityContext(action='SELECT',
resource=pk.MATCH.r & pk.TEST(lambda r: 'public' in r),
risk_score=pk.LT(30)))
def rule_low_risk_public_query(self, ctx):
"""低风险的公开数据查询自动放行"""
self.modify(ctx, decision="allow")
print(f"[Policy] ALLOW: Low-risk public data query.")
@pk.Rule(SecurityContext(risk_score=pk.GE(70)))
def rule_high_risk_general(self, ctx):
"""任何高风险操作都需要高级别审批或直接拒绝"""
if 'admin' in ctx.user_role:
self.modify(ctx, decision="require_approval", required_approval_level="director")
else:
self.modify(ctx, decision="deny")
print(f"[Policy] High-risk general rule triggered.")
# 使用示例
engine = DynamicPolicyEngine()
engine.reset()
# 模拟一个上下文：非工作时间，Agent尝试删除客户数据
context = SecurityContext(
agent_id="agent-01",
action="DELETE",
resource="db://prod/customer_table",
time_of_day="off_hours",
user_role="analyst",
risk_score=60 # 初始风险分
)
engine.declare(context)
engine.run()
print(f"Final Decision: {context.decision}")
print(f"Approval Level: {context.required_approval_level}")
# 输出可能为: Final Decision: deny
这个简单的规则引擎可以根据丰富的上下文（时间、资源、用户角色、历史行为风险分）做出动态决策，决定是自动放行、要求审批还是直接拒绝。在实际系统中，你可以集成更强大的引擎如 Drools 或 Open Policy Agent (OPA) 。
5. 部署与运维：将安全能力融入CI/CD与监控体系
安全不是一次性功能，而是贯穿始终的流程。
1. Agent镜像安全
- 使用最小化基础镜像。
- 定期扫描镜像中的漏洞（CVE）。
- 对镜像进行签名，确保部署的是可信版本。
2. 安全配置即代码
- 将上述的
agent-security-policy.yaml等策略文件纳入Git版本控制。 - 任何策略变更都需要通过Pull Request和代码审查。
- 可以使用类似Kubernetes ConfigMap或Hashicorp Vault来管理敏感配置。
3. 持续监控与告警
- 聚合审计日志到SIEM（安全信息与事件管理）系统，如Elasticsearch SIEM、Splunk。
- 设置关键告警：
- 任何权限拒绝事件。
- 高风险操作（无论是否被批准）。
- Agent行为严重偏离基线。
- 审计日志服务不可用。
- 仪表盘：可视化展示Agent活动地图、风险热力图、审批吞吐量等。
4. 定期红队演练与审计
- 定期模拟攻击，尝试诱导Agent执行越权操作，测试整个安全体系的有效性。
- 对审计日志进行定期的人工或自动化审查，寻找异常模式。
6. 常见问题与排查思路
在企业Agent安全实践中，以下是一些典型问题及应对方法：
| 问题现象 | 可能原因 | 排查步骤 | 解决方案 |
|---|---|---|---|
| Agent操作被频繁拒绝 | 1. 权限策略过严。 2. Agent行为模式改变，触发新的风险规则。 3. 上下文信息（如时间、IP）获取错误。 |
1. 查看审计日志中的 policy_decision 和 denied 事件。 2. 分析被拒绝操作的共同模式。 3. 检查策略引擎的输入上下文是否正确。 |
1. 审查并细化权限策略，区分风险等级。 2. 调整行为基线模型或风险评分规则。 3. 修复上下文收集逻辑。 |
| HITL审批请求积压，员工抱怨 | 1. 中低风险操作未正确分类，全部走审批。 2. 审批流程繁琐，缺少批量或模板化审批。 3. 审批人不在岗。 |
1. 分析审批请求的类型和风险分布。 2. 调研审批流程中的耗时环节。 3. 检查审批人配置和通知机制。 |
1. 优化动态策略，将更多低风险操作设为“自动审计”模式。 2. 实现审批模板、批量审批和紧急通道。 3. 设置审批人备份和自动升级机制。 |
| 审计日志体积增长过快 | 1. 日志级别设置过低，记录了过多调试信息。 2. Agent数量或活动激增。 3. 日志字段包含过大报文。 |
1. 分析日志索引大小和增长趋势。 2. 检查日志配置，确认字段是否必要。 3. 抽样查看日志内容。 |
1. 调整日志级别，对高频、低风险操作进行采样记录。 2. 对 request / response 等大字段进行截断或摘要记录。 3. 设置日志生命周期策略（如ES的ILM），自动滚动和删除旧索引。 |
| 疑似Agent被恶意指令注入 | 1. 用户输入未经验证直接拼接给Agent。 2. Agent提示词（Prompt）存在漏洞。 |
1. 审查审计日志中操作前后的原始指令。 2. 检查是否有异常模式（如包含“忽略之前”、“系统命令”等）。 |
1. 强化输入验证层（如 ContentSecurityFilter.validate_instruction ）。 2. 在Prompt中强化系统角色和边界设定。 3. 对可疑会话进行实时中断和人工复核。 |
| 沙箱环境性能开销大 | 1. 为每个操作启动独立沙箱，冷启动耗时。 2. 沙箱资源限制过严，影响正常任务。 |
1. 监控沙箱创建/销毁时间和资源使用率。 2. 对比任务在沙箱内外的执行时间。 |
1. 使用沙箱连接池，复用预热好的环境。 2. 根据任务类型调整沙箱规格（CPU/Memory）。 3. 对可信度高的内部任务使用轻量级隔离（如namespace）。 |
7. 最佳实践与工程建议
- 安全左移，设计即安全 ：在Agent项目立项和架构设计阶段，就必须将安全作为核心需求，而不是事后补丁。威胁建模（Threat Modeling）是一个很好的起点。
- 默认拒绝，最小权限 ：所有Agent的初始权限应为零。任何权限都必须经过申请、评审和显式授予。定期进行权限审计和回收。
- 审计不可关闭，日志不可篡改 ：审计日志系统必须独立于Agent运行环境，Agent自身应无权限删除或修改日志。考虑使用WORM（一次写入，多次读取）存储。
- HITL作为关键路径，而非唯一路径 ：将HITL设计为处理高风险、高价值决策的“关键路径”。为它提供充分的决策支持信息（如差异对比、影响分析、历史类似案例），提升其有效性。同时，用自动化策略处理大量中低风险操作。
- 定期演练与更新 ：安全策略和威胁模型不是一成不变的。应定期（如每季度）进行红蓝对抗演练，并根据业务变化、新的攻击手段更新安全规则。
- 培养团队的安全意识 ：最终用户（点击确认按钮的人）、Agent开发者和运维人员都需要接受安全培训，理解风险所在，成为安全体系中的积极一环。
回到我们开头的问题：当“Human in the Loop”变成“闭着眼睛点确认”，企业Agent安全还能靠谁？答案很明确： 靠一个从架构层面设计的、多层次、纵深防御的安全体系。 这个体系将人的判断与自动化的监控、强制性的技术控制（权限、沙箱）和智能化的策略引擎相结合。
HITL依然重要，但它应该是这个安全交响乐中的“首席小提琴手”，而不是唯一的演奏者。通过本文介绍的核心支柱—— 最小权限、行为审计、意图验证和动态策略 ——你可以构建一个即使在人因环节出现疏漏时，仍能保持韧性的Agent系统。
真正的安全，不在于增加多少个确认弹窗，而在于将安全能力内化到每一个操作、每一次交互和每一行代码之中。开始行动吧，从为你下一个Agent项目设计第一份安全策略文件开始。
更多推荐
7
0- 0
已为社区贡献35条内容
所有评论(0)