1. 项目概述为AI代理行动构建不可篡改的“数字指纹”在AI代理Agent日益深入我们工作流的今天一个核心的信任问题变得前所未有的尖锐当你的AI助手替你创建了一个GitHub Issue、执行了一条数据库删除命令或者批准了一笔交易时你如何向第三方比如审计员、客户或者仅仅是事故复盘时的你自己证明这件事确实是“它”干的并且内容没有被篡改过传统的解决方案是日志。但日志有个根本性的缺陷它依赖于记录者的可信度。平台告诉你“代理执行了X操作”你只能选择相信这个平台。如果日志服务器被入侵、日志文件被恶意修改或者平台自身存在内部错误你几乎无法察觉。这就像让一个球员自己记录比赛得分缺乏独立的、可验证的证据。这正是Signet要解决的问题。它不是一个日志系统而是一个独立的、密码学驱动的验证层。它的核心思想很简单却非常有力为AI代理的每一次工具调用Tool Call生成一份密码学收据Cryptographic Receipt。这份收据由代理的私钥签名并通过哈希链Hash Chain与前序收据链接形成一个不可篡改、可离线验证的审计轨迹。无论这个代理运行在谁的服务器上使用了哪个供应商的API证明收据都牢牢掌握在你手里。简单来说Signet让AI代理的每一次行动都像签署了一份具有法律效力的数字合同任何人都可以拿着公开的公钥在任何时间、任何地点独立验证这份合同的完整性和签署者身份而无需连接任何中心化的服务。这对于需要满足合规要求如SOC 2, ISO 27001, 欧盟AI法案、构建高可信度企业级应用或是在多代理协作场景中建立互信提供了坚实的技术基础。2. 核心设计思路从“信任平台”到“验证证据”Signet的设计哲学源于一个根本性的转变将信任从中心化的平台转移到可验证的密码学证据上。让我们拆解一下这背后的几个关键设计决策。2.1 为什么是“收据”而非“日志”传统日志和Signet收据的本质区别可以用一个生活场景来类比传统日志像餐厅服务员手写的点菜单。你相信他写对了但如果他事后修改了金额你很难发现。Signet收据像一台连接了税控机的POS机打出的发票。每一笔交易都带有唯一的、由税控机生成的防伪码签名并且交易序列号是连续的哈希链。任何对金额、时间的篡改都会导致防伪码失效任何缺失的发票都会破坏序列的连续性。具体到技术层面Signet收据v1版本通常包含以下核心字段所有这些字段都被包含在签名范围内action: 记录了具体的工具名称如github_create_issue、调用参数params、参数哈希params_hash、目标资源target如mcp://github和传输方式transport。signer: 明确标识了签署者包括其公钥pubkey、名称name和所有者owner。ts和nonce: 时间戳和随机数共同防止重放攻击Replay Attack。即使攻击者截获了一份有效的收据也无法在过期时间后或使用相同的随机数重放它。sig: 最关键的部分即使用代理私钥Ed25519算法对整个收据体经过JCS规范化计算出的数字签名。这个设计确保了数据的完整性任何字段的修改都会使签名失效和行为的不可否认性只有持有对应私钥的代理才能生成有效的签名。2.2 哈希链构建不可篡改的审计轨迹单个收据可以防篡改但攻击者仍然可以删除或调换整个收据文件。Signet通过哈希链来解决这个问题。其原理是每一份新生成的收据都会将前一份收据的ID或哈希值包含进来并计算进自己的哈希中。收据1 [ID: hash1 内容: Action A] - 签名 收据2 [ID: hash2 内容: Action B, 前序ID: hash1] - 签名 收据3 [ID: hash3 内容: Action C, 前序ID: hash2] - 签名这就形成了一条环环相扣的链。如果你试图删除“收据2”那么“收据3”中记录的“前序ID: hash2”就会找不到对应的收据链就断了。如果你试图调换“收据2”和“收据3”的顺序那么它们的哈希和前后关联关系就会全部错乱。通过signet verify --chain命令或仪表盘的“链完整性”检查可以快速定位任何断裂点。2.3 离线验证信任的终极形态Signet最强大的特性之一是离线验证。验证一份收据的有效性你只需要三样东西收据文件本身。签署者对应的公钥。一个能运行Ed25519签名验证算法的程序Signet CLI或SDK。你不需要连接Signet的服务器它本身也没有中心服务器不需要调用任何API甚至不需要网络。这意味着抗审查即使服务提供商中断服务你的历史证据依然有效。第三方审计你可以将收据和公钥交给完全独立的第三方如审计机构他们可以在隔离环境中自行验证无需访问你的内部系统。法律证据这种自包含、可独立验证的特性使得收据更容易作为电子证据被采信。2.4 执行边界验证与双向签名对于安全性要求更高的场景Signet提供了更进阶的模式执行边界验证Execution Boundary Verification和双向签名Bilateral Signing。执行边界验证意味着接收工具调用的服务器例如一个提供GitHub操作的MCP服务器在真正执行危险操作如git push、rm -rf之前可以先验证请求附带的Signet收据。服务器可以检查签名是否有效请求是否来自可信的代理收据是否新鲜时间戳是否在可接受的窗口内如5分钟目标是否匹配收据中声明的target如mcp://production-db是否与服务器自身标识符一致 如果任何一项检查失败服务器可以在执行业务逻辑之前就拒绝该请求从而在入口处建立一道安全防线。双向签名v3收据则更进一步。当服务器处理完一个由可信代理发来的、已验证的请求后它可以用自己的私钥对“代理的请求收据 服务器的响应结果”进行联合签名生成一份v3收据。这份收据不仅证明了“代理请求了X”还证明了“服务器响应了Y”构成了一个完整的、双方确认的事务记录。这对于需要明确权责的金融交易或合同履行场景至关重要。2.5 授权链与策略证明在复杂的组织架构中代理的行动权限往往来自上级的授权。Signet v4收据引入了授权链Delegation Chain的概念。例如一个组织管理员alice可以签发一个授权令牌将“执行Bash命令”的权限委托给一个部署机器人deploy-bot并限制其目标范围和有效期。当deploy-bot执行操作时它生成的v4收据会附带整个授权链的证明。验证者不仅能看到“deploy-bot执行了git pull”还能通过密码学验证这条授权链确认“alice授权了deploy-bot在指定范围和时间内执行此操作”。这实现了权限的细粒度、可验证的传递。策略证明Policy Attestation则是将安全策略与密码学证明绑定。你可以定义一个YAML策略文件规定“允许Read工具”、“禁止包含rm -rf的Bash命令”。当代理请求签名时Signet会先根据策略检查行动。如果允许它会在收据中嵌入一个经过签名的PolicyAttestation证明“此行动符合策略#XYZ的第N条规则”。这为合规审计提供了机器可读、不可篡改的策略遵循证据。3. 实战集成为你的AI应用穿上“防弹衣”理解了原理我们来看看如何将Signet集成到不同的AI开发栈中。Signet的设计非常注重“可插拔”力求以最小的改动为现有应用增加可验证性。3.1 快速开始Python SDK与LangChain集成对于大多数Python开发者从signet-authPython SDK开始是最快的路径。它提供了高级的SigningAgent类并内置了对主流框架的钩子支持。第一步安装与基础使用pip install signet-authfrom signet_auth import SigningAgent # 创建一个名为“deploy-bot”的代理身份私钥会自动加密保存在 ~/.signet/keys/ 下 agent SigningAgent.create(deploy-bot, ownerengineering-team) # 模拟一个工具调用创建GitHub Issue action_params {title: Security patch required, body: Fix for CVE-2024-12345, repo: myorg/api-server} # 签名这会生成一份v1收据并自动追加到本地审计日志 (~/.signet/audit/) receipt agent.sign(github_create_issue, paramsaction_params, targetmcp://github.company.com) print(fReceipt ID: {receipt.id}) print(fSigned by: {receipt.signer.name}) # 验证这份收据通常用于后续审计或传递给第三方验证 assert agent.verify(receipt) # 验证通过第二步集成到LangChain如果你已经在使用LangChain集成几乎是无缝的。Signet提供了一个回调处理器Callback Handler可以挂载到任何Chain或Agent上。from signet_auth import SigningAgent from signet_auth.langchain import SignetCallbackHandler from langchain.agents import initialize_agent, AgentType from langchain_openai import ChatOpenAI # 1. 创建Signet代理和处理器 signet_agent SigningAgent(langchain-agent) signet_handler SignetCallbackHandler(signet_agent) # 2. 准备你的工具这里用占位符示例 def search_web(query: str) - str: # 实际调用搜索API return fResults for {query} tools [Tool(nameweb_search, funcsearch_web, descriptionSearches the web)] # 3. 创建LangChain Agent并传入Signet回调 llm ChatOpenAI(modelgpt-4, temperature0) agent initialize_agent( tools, llm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, verboseTrue, # 关键在这里注入Signet处理器 callbacks[signet_handler] ) # 4. 运行Agent。所有通过此Agent执行的工具调用都会被自动签名。 result agent.invoke(Whats the latest news about AI safety?) # 在后台web_search工具的调用已经生成了一份Signet收据。 # 5. 你可以查看本次会话生成的所有收据 for receipt in signet_handler.receipts: print(f- Tool: {receipt.action.tool}, Receipt ID: {receipt.id}) # 6. 事后审计查询过去1小时的所有操作 for record in signet_agent.audit_query(since1h): print(f{record.receipt.ts}: {record.receipt.action.tool} - {record.receipt.id})实操心得回调处理器的局限性这种基于回调的集成方式非常轻量但有一个关键点需要注意它是在工具被调用后才捕获信息进行签名的。这意味着它无法阻止一个未经验证的调用发生尽管事后可以发现。对于需要“执行前验证”的高安全场景你需要使用MCP代理signet proxy或服务器端验证模式它们能在调用到达工具逻辑前进行拦截。3.2 为MCP工具调用上锁SigningTransport与代理模式MCPModel Context Protocol正在成为AI代理与工具交互的标准协议。Signet为MCP提供了深度集成这是实现“执行边界验证”的关键。方案A客户端签名透明代理如果你控制的是调用MCP工具的客户端如一个自定义的AI Agent应用你可以使用SigningTransport包装任何现有的MCP传输层。import { Client } from modelcontextprotocol/sdk/client/index.js; import { StdioClientTransport } from modelcontextprotocol/sdk/client/stdio.js; import { generateKeypair } from signet-auth/core; import { SigningTransport } from signet-auth/mcp; // 1. 生成代理密钥对 const { secretKey, publicKey } generateKeypair(); // 保存publicKey供后续验证使用 const agentName my-mcp-client; // 2. 创建原始传输层例如连接到一个本地的Git MCP服务器 const innerTransport new StdioClientTransport({ command: npx, args: [modelcontextprotocol/server-git], }); // 3. 用SigningTransport进行包装 const signingTransport new SigningTransport( innerTransport, secretKey, // 代理的私钥 agentName // 代理名称 ); // 4. 像往常一样使用MCP客户端 const client new Client({ name: agentName, version: 1.0 }, {}); await client.connect(signingTransport); // 5. 现在每一次client.callTool()都会自动签名 // 签名收据会被注入到请求的 params._meta._signet 字段中。 const result await client.callTool({ name: git_commit, arguments: { message: Fix security vulnerability, addAll: true }, });这种方式对MCP服务器是透明的服务器甚至不需要知道Signet的存在。签名纯粹发生在客户端用于事后审计和证明。方案B服务端验证执行边界如果你同时控制MCP服务器你可以在服务器端验证请求实现执行前的安全拦截。import { Server } from modelcontextprotocol/sdk/server/index.js; import { verifyRequest } from signet-auth/mcp-server; const server new Server( { name: secure-git-server, version: 1.0.0 }, { capabilities: { tools: {} } } ); // 假设我们信任以下公钥对应的代理 const TRUSTED_PUBLIC_KEYS [ed25519:0CRkURt/tc6r...]; server.setRequestHandler(CallToolRequestSchema, async (request) { // 1. 在执行业务逻辑前先验证请求 const verification verifyRequest(request, { trustedKeys: TRUSTED_PUBLIC_KEYS, maxAge: 300, // 收据有效期最多5分钟防重放 expectedTarget: mcp://git-server, // 可选检查目标是否匹配 }); // 2. 根据验证结果决定是否继续 if (!verification.ok) { // 签名无效、过期或格式错误 console.error(Request verification failed: ${verification.error}); return { content: [{ type: text, text: Request verification failed: ${verification.error} }], isError: true, }; } if (!verification.trusted) { // 签名有效但签署者不在信任列表中 console.warn(Request from untrusted signer: ${verification.signerName}); return { content: [{ type: text, text: Agent not authorized. }], isError: true, }; } // 3. 验证通过可以安全地执行业务逻辑 console.log(Executing tool ${request.params.name} for trusted agent: ${verification.signerName}); // ... 实际执行git操作 ... // 4. (可选) 服务器进行双向签名生成v3收据 // const bilateralReceipt signResponse(serverSecretKey, verification.receipt, response, git-server); // 将bilateralReceipt返回或记录到审计日志 });这种模式将安全防线推进到了工具执行的最后一刻非常适合处理高风险操作。方案C零代码集成 - Signet Proxy如果你不想修改任何客户端或服务器代码Signet CLI提供了一个强大的proxy命令。它作为一个透明的stdio代理运行在MCP客户端和服务器之间。# 假设你有一个通过stdio通信的MCP服务器 # 原本的启动命令可能是npx modelcontextprotocol/server-git # 使用Signet Proxy进行包装 signet proxy \ --key my-agent \ # 使用本地存储的my-agent密钥对请求签名 --target npx modelcontextprotocol/server-git # 指定目标服务器命令 # 现在任何连接到这个代理端口的MCP客户端其发出的工具调用都会被自动签名。 # 你还可以添加策略检查 signet proxy \ --key my-agent \ --policy ./security-policy.yaml \ # 拒绝不符合策略的请求 --target npx modelcontextprotocol/server-git代理模式是快速为现有MCP工具栈增加审计能力的绝佳方式尤其适合Claude Code、Cursor等内置MCP客户端的AI编码助手。3.3 在CI/CD流水线中自动签名在自动化部署CI/CD流水线中使用AI代理时签名同样重要。你需要确保流水线中的机器人生成的操作是可验证的。关键在于安全的密钥管理。# .github/workflows/deploy.yml 示例 name: Deploy with Signed Actions on: push: branches: [ main ] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Install Signet CLI run: | curl -L https://github.com/Prismer-AI/signet/releases/latest/download/signet-cli-x86_64-unknown-linux-gnu.tar.gz | tar xz sudo mv signet /usr/local/bin/ - name: Import Deployment Agent Key # 绝对不要将私钥明文存放在仓库或日志中 # 使用GitHub Actions的加密Secret存储加密后的私钥和密码。 run: | echo ${{ secrets.SIGNET_ENCRYPTED_KEY }} /tmp/agent-key.enc echo ${{ secrets.SIGNET_KEY_PASSPHRASE }} | signet identity import --encrypted-file /tmp/agent-key.enc --name ci-agent --force # 或者对于无头CI环境可以使用未加密的密钥风险较高需严格隔离 # run: echo ${{ secrets.SIGNET_UNENCRYPTED_KEY }} | signet identity import --unencrypted --name ci-agent --force - name: Run Deployment Script (with Signing) run: | # 你的部署脚本可能调用了一些工具现在我们用signet包装它 # 假设 deploy.sh 内部会调用一些命令行工具 ./deploy.sh # 但更佳实践是在脚本内部对关键操作显式签名 # signet sign --key ci-agent --tool kubectl_apply --params {file:deployment.yaml} --target k8s://production - name: Upload Audit Trail as Artifact if: always() # 即使失败也上传用于故障排查 run: | signet audit --export audit-${GITHUB_RUN_ID}.json # 也可以只导出本次运行期间的记录 signet audit --since 1h --export audit-latest.json # 将审计日志上传到工作流产物或安全的日志存储关键安全实践CI环境密钥管理避免未加密密钥尽管Signet支持--unencrypted选项以方便CI但任何能访问Runner环境的进程都可能读取该密钥。首选使用加密密钥并通过环境变量SIGNET_PASSPHRASE传递密码。使用短寿命的授权令牌对于CI机器人使用signet delegate create --ttl 1h为其创建仅限1小时有效的授权令牌而不是直接使用主密钥。即使令牌泄露影响范围也有限。隔离审计日志将CI生成的审计日志上传到与CI Runner隔离的、不可篡改的存储中如AWS S3 Object Lock或类似的WORM存储防止攻击者在篡改操作后也删除日志证据。4. 高级特性与最佳实践解析4.1 授权链的实际应用构建分层信任体系在大型组织中权限管理是核心。Signet的授权链v4收据允许你构建一个清晰的、可验证的权限委托体系。假设一个场景基础设施团队主管infra-lead需要授权一个自动化的“数据库备份机器人”backup-bot在每周日凌晨访问生产数据库执行备份。第一步主管创建授权# infra-lead 在安全的机器上执行 # 创建一个授权令牌允许 backup-bot 使用 mysql_dump 工具目标限定于生产数据库有效期7天下次备份前。 signet delegate create \ --from infra-lead \ # 授权者身份 --to backup-bot \ # 被授权代理的公钥或名称如果密钥已存在 --to-name Production Backup Bot \ # 代理的可读名称 --tools mysql_dump \ # 允许的工具列表 --targets mcp://prod-db:3306 \ # 限定的目标资源 --max-depth 0 \ # 不允许该代理进一步转授权 --ttl 168h \ # 有效期7天 --output backup-delegation.json这条命令会生成一个包含授权信息的JSON令牌文件。这个令牌本身是公开的因为它只包含授权声明和授权者的签名。第二步机器人使用授权进行签名# backup-bot 在执行备份任务时 signet delegate sign \ --key backup-bot \ # 使用自己的私钥 --tool mysql_dump \ --params {database:orders, output:/backup/orders.sql} \ --target mcp://prod-db:3306 \ --chain backup-delegation.json \ # 附上授权令牌 --output backup-receipt.json生成的backup-receipt.json是一个v4收据。它内部不仅包含了backup-bot对本次行动的签名还完整地嵌入了来自infra-lead的授权链。第三步任何人进行验证# 审计员或安全系统可以离线验证 signet delegate verify-auth backup-receipt.json --trusted-roots infra-lead验证过程会检查backup-bot的签名是否有效。检查授权链infra-lead的签名是否有效授权是否在有效期内ttl检查授权范围本次行动使用的工具mysql_dump和目标mcp://prod-db:3306是否在授权令牌允许的范围内检查授权链的根infra-lead是否在--trusted-roots列表中。只有所有检查都通过验证才会成功。这实现了一种“最小权限”和“可验证授权”的完美结合。4.2 策略即代码将合规要求嵌入签名过程策略引擎允许你将安全规则定义为代码YAML并在签名时自动执行。这比事后在日志中筛选违规行为要主动得多。一个综合性的策略文件示例# security-policy.yaml version: 1 name: production-agent-policy default_action: deny # 默认拒绝白名单模式 rules: # 规则1允许只读操作 - id: allow-read-operations match: tool: Read # 可以添加更细粒度的params匹配例如 path 以 /var/log/ 开头 action: allow description: Allow all read operations for auditing # 规则2允许在特定仓库执行Git操作 - id: allow-git-to-core-repos match: tool: Git params: repository: one_of: [https://github.com/myorg/core-api, https://github.com/myorg/core-web] command: not_contains: force push # 禁止强制推送 action: allow description: Allow git operations on core repositories, but no force pushes # 规则3严格限制Bash命令 - id: allow-safe-bash match: tool: Bash params: command: # 只允许明确列出的安全命令 one_of: [ls -la, df -h, cat /etc/hostname, docker ps] action: allow description: Only allow a predefined set of safe bash commands # 规则4明确拒绝危险操作即使前面的规则可能允许deny优先级更高需注意规则顺序 - id: deny-any-rm-rf match: tool: Bash params: command: contains: rm -rf action: deny reason: Destructive rm -rf command is prohibited globally # 可以设置 metadata记录到收据中 metadata: severity: CRITICAL policy_reference: SEC-OPS-001在签名时应用策略signet sign --key deploy-bot \ --tool Bash \ --params {command:ls -la /tmp} \ --policy ./security-policy.yaml # 此命令会被 allow-safe-bash 规则允许成功签名。 signet sign --key deploy-bot \ --tool Bash \ --params {command:rm -rf /home/user} \ --policy ./security-policy.yaml # 此命令会被 deny-any-rm-rf 规则拒绝签名失败命令不会执行。当行动被允许时生成的收据会包含一个PolicyAttestation字段其中记录了匹配的策略ID、规则ID和策略内容的哈希值。这为“操作符合某策略”提供了密码学证明。策略设计心得顺序与默认动作策略规则的评估通常是顺序的第一条匹配的规则决定最终动作。将deny规则放在前面allow规则放在后面是一种常见的安全实践类似防火墙规则。同时明确设置default_action: deny可以确保任何未明确允许的操作都会被拒绝遵循“最小权限原则”。4.3 审计、追溯与仪表盘生成收据只是第一步如何有效地管理和分析它们同样重要。Signet CLI提供了强大的审计功能。基础查询与过滤# 查看所有审计记录默认最近100条 signet audit # 查看过去24小时内的记录 signet audit --since 24h # 查看特定工具相关的记录 signet audit --tool git # 查看特定签署者的记录 signet audit --signer deploy-bot # 组合过滤查看deploy-bot在过去一周执行的所有“Bash”操作 signet audit --since 7d --tool Bash --signer deploy-bot # 以JSON格式导出便于用jq等工具进行二次分析 signet audit --since 30d --export monthly-audit.json链完整性验证这是审计的核心用于确保日志没有被篡改。signet verify --chain这条命令会读取~/.signet/audit/目录下的所有审计日志文件逐条计算哈希检查每条收据的id是否与根据前一条收据计算出的哈希一致。如果链是完整的你会看到✓ Chain integrity verified的输出。如果链被破坏例如文件被手动编辑或删除了一行它会明确指出断裂发生在哪个文件的哪一行。可视化仪表盘对于喜欢图形界面的用户signet dashboard命令会启动一个本地Web服务器默认 http://localhost:5173在浏览器中打开一个交互式仪表盘。时间线视图按时间顺序展示所有工具调用清晰展示“谁在什么时候做了什么”。详情面板点击任一记录可以查看完整的收据JSON、签名信息、策略证明如果有等。统计视图按工具、签署者、收据版本进行聚合统计快速了解代理活动分布。链完整性检查图形化展示哈希链直观定位任何断裂点。仪表盘完全运行在本地所有数据都不会离开你的机器满足了安全审计的隔离性要求。5. 常见问题、排查与架构考量5.1 密钥管理安全存储与轮换问题私钥应该存储在哪里如何保护个人开发环境默认使用~/.signet/keys/目录并使用用户提供的口令对私钥进行加密基于scrypt和AEAD。这是安全且方便的方式。服务器/生产环境推荐使用硬件安全模块HSM或云服务商的密钥管理服务KMS如AWS KMS, GCP Cloud KMS, Azure Key Vault。Signet的核心库Rust可以通过FFI接口集成这些服务来执行签名操作私钥永不离开安全硬件。次选如果无法使用HSM/KMS可将加密后的私钥存储在安全的机密管理工具中如HashiCorp Vault, AWS Secrets Manager在应用启动时动态解密并加载到内存。确保服务器磁盘加密并严格控制对机密管理工具的访问权限。避免将未加密的私钥放在环境变量、配置文件或代码仓库中。问题如何轮换密钥密钥轮换是安全最佳实践。Signet的身份是密钥对无关的你可以为一个“代理名称”更换密钥。生成新密钥对signet identity generate --name my-agent-new更新信任配置在所有验证此代理的服务器上将信任的公钥列表更新为新的公钥。切换代理代码更新你的AI代理应用使其使用新的密钥对my-agent-new进行签名。重叠期在一段时间内服务器端同时信任新旧两个公钥以确保正在进行的请求不会失败。废弃旧密钥重叠期结束后从服务器信任列表中移除旧公钥并安全地销毁旧私钥。5.2 性能与开销考量问题签名/验证会带来多少延迟Ed25519签名算法非常高效。在标准硬件上一次签名或验证操作通常在几十到几百微秒内完成对于单次工具调用来说这个开销几乎可以忽略不计。主要的开销可能来自序列化/反序列化JSON和哈希计算但整体上对AI代理的交互体验影响极小。问题审计日志会占用多少空间一份典型的v1收据大小约为500字节到2KB取决于params的大小。如果你选择--hash-only模式只存储参数的哈希不存储原始参数体积会更小。对于一个每天执行10万次工具调用的活跃系统一天的日志量大约在50MB到200MB。建议配置日志滚动策略Signet默认按大小或时间分割文件并定期将旧的审计日志归档到成本更低的存储中。5.3 与其他安全措施的关系Signet不是银弹它需要与其他安全实践结合使用网络隔离与访问控制Signet证明“谁做了什么”但不能替代防火墙和网络策略。仍然需要将MCP服务器或工具后端部署在安全的网络环境中限制访问来源。沙箱与权限限制即使一个请求被有效签名执行它的进程也应该运行在最小权限的沙箱中。例如执行Bash命令的容器应该没有root权限不能访问敏感文件。输入验证与清理Signet不验证params的业务逻辑正确性。服务器端仍需对参数进行严格的验证和清理防止注入攻击等。监控与告警Signet审计日志是监控的黄金数据源。应该建立监控系统对异常模式如来自同一代理的高频删除操作、在非工作时间执行特权命令进行告警。5.4 故障排查指南问题signet verify失败提示“Invalid signature”。检查公钥是否匹配确保验证时使用的公钥与签名时使用的私钥对应。使用signet identity list和signet identity export确认。检查收据是否被篡改即使是空格或换行符的改动也会导致签名失效。可以尝试用jq . receipt.json格式化收据确认其内容。Signet使用JCSJSON Canonicalization Scheme进行规范化签名确保序列化的一致性。检查时间戳和随机数如果服务器端验证失败检查服务器的系统时间是否准确以及maxAge参数设置是否合理。问题MCP服务器收不到tools/call请求。检查SigningTransport包装确保在创建MCP Client时正确地将原始Transport包装在了SigningTransport中。检查params._meta._signet使用调试工具查看发出的MCP请求确认_meta._signet字段已被正确注入。有些MCP服务器可能对未知字段敏感但标准MCP协议应允许额外字段。检查代理signet proxy日志如果使用代理模式查看代理进程的标准输出/错误看是否有连接目标服务器失败或策略拒绝请求的日志。问题审计日志链验证失败。确认文件是否被手动编辑审计日志文件是纯文本JSON行格式JSON Lines。任何手动编辑都会破坏哈希链。恢复的唯一方法是从备份中找回原始文件。检查日志滚动Signet会自动滚动日志文件。确保没有外部进程意外删除或移动了旧的日志文件。验证时signet verify --chain会扫描整个审计目录包括历史文件。检查磁盘错误极少数情况下磁盘错误可能导致文件损坏。可以考虑定期对审计目录进行校验和备份。5.5 架构扩展与自定义Signet的核心库Rust crates被设计为可嵌入的组件。如果你有特殊需求可以考虑以下扩展方向自定义存储后端默认审计日志存储在本地文件系统。你可以实现AuditStoretrait将收据存储到数据库如PostgreSQL、SQLite或分布式日志系统如Apache Kafka中以便于集中管理和查询。与现有日志系统集成除了独立的审计日志你也可以将Signet收据作为结构化字段输出到你现有的日志聚合系统如ELK Stack, Datadog, Splunk中。这样可以将密码学证据与你现有的监控仪表盘关联起来。开发自定义策略引擎除了YAML文件你可以将Signet的策略评估逻辑与你现有的策略即代码平台如Open Policy Agent, AWS IAM集成实现统一的策略管理。实现密钥管理接口为signet-core实现Keystoretrait使其能够从你的HSM或云KMS中获取私钥进行签名而不是从本地文件加载。Signet作为一个开源项目其模块化设计鼓励社区根据具体场景进行扩展和集成。它的目标不是成为一个大而全的平台而是成为一个专注、可靠、可组合的“信任基元”嵌入到现代AI应用架构的各个层面为每一次智能体的行动提供无可辩驳的证据。