from signet_auth import SigningAgent

agent = SigningAgent.create("my-agent", owner="team")
receipt = agent.sign("github_create_issue", params={"title": "fix bug"})

assert agent.verify(receipt)
print(receipt.id)

如果你是新手，请从以下四条路径之一开始：

选择你的路径

Claude Code：最适合在编码代理中进行最快的首次运行。在 Claude Code 中运行 /plugin install signet@claude-plugins-official。5 分钟内，你将拥有已签名的工具调用和位于 ~/.signet/audit/ 的本地审计日志。
Codex CLI：最适合在 Codex 中签署 Bash 工具调用。将 plugins/codex/ 复制到 ~/.codex/plugins/signet 并添加一个 PostToolUse 钩子。5 分钟内，你将使用相同的审计跟踪在 Codex 中拥有已签名的 Bash 操作。
MCP 客户端：如果你控制 MCP 客户端或传输，这是最佳选择。使用 new SigningTransport(inner, secretKey, "my-agent") 包装你的传输。5 分钟内，你将拥有已签名的 tools/call 请求，并在 params._meta._signet 中包含收据。
MCP 服务器：如果你想在执行前进行验证，这是最佳选择。在你的工具处理程序中调用 verifyRequest(request, {...})。5 分钟内，你将在执行边界拥有签名者、新鲜度、目标绑定以及工具/参数检查。

查看它拒绝错误请求

运行最短的执行边界演示：

cd examples/mcp-agent
npm run execution-boundary-demo

查看 examples/mcp-agent/demo-execution-boundary.mjs 获取演示源码。

团队何时需要 Signet

你需要为编码代理、MCP 工具或 CI 自动化提供审计跟踪
你需要在事件发生后证明是哪个代理请求了操作
你需要无需依赖托管服务即可离线验证的收据
你想要已签名的工具调用证据，而无需在你的栈中添加代理或网关

Signet 是什么，不是什么

Signet 是代理操作的证明层：签名、审计和验证
Signet 旨在通过 SDK、插件和 MCP 中间件融入现有的代理栈
Signet 不是策略引擎、防火墙或操作拦截器
Signet 不是网关的替代品；它是预防和执行工具的补充

安装

# CLI
cargo install signet-cli

# Python
pip install signet-auth

# TypeScript (MCP middleware)
npm install @signet-auth/core @signet-auth/mcp

# TypeScript (MCP server verification)
npm install @signet-auth/mcp-server

# TypeScript (Vercel AI SDK middleware)
npm install @signet-auth/vercel-ai

快速入门

Claude Code 插件

在 Claude Code 中自动签署每个工具调用，无需配置：

# Option A: From the official Anthropic plugin marketplace
/plugin install signet@claude-plugins-official

# Option B: Add Signet as a marketplace source, then install
/plugin marketplace add Prismer-AI/signet
/plugin install signet@signet

每个工具调用都使用 Ed25519 签名，并记录到 ~/.signet/audit/ 的哈希链审计跟踪中。

其他安装方法：

# From Git
claude plugin add --from https://github.com/Prismer-AI/signet

# Via signet CLI
signet claude install

Codex 插件

在 Codex CLI 中自动签署每个 Bash 工具调用：

git clone https://github.com/Prismer-AI/signet.git
cp -r signet/plugins/codex ~/.codex/plugins/signet

然后将钩子添加到 ~/.codex/hooks.json：

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "node \"$HOME/.codex/plugins/signet/bin/sign.cjs\"",
        "timeout": 5
      }]
    }]
  }
}

或者使用 MCP 服务器进行按需签名工具：

codex mcp add signet -- npx @signet-auth/mcp-tools

CLI

# Generate an agent identity
signet identity generate --name my-agent

# Sign an action
signet sign --key my-agent --tool "github_create_issue" \
  --params '{"title":"fix bug"}' --target mcp://github.local

# Verify a receipt
signet verify receipt.json --pubkey my-agent

# Audit recent actions
signet audit --since 24h

# Verify log integrity
signet verify --chain

MCP 客户端集成 (TypeScript)

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";

// Generate an agent identity
const { secretKey } = generateKeypair();

// Wrap any MCP transport -- all tool calls are now signed
const inner = new StdioClientTransport({ command: "my-mcp-server" });
const transport = new SigningTransport(inner, secretKey, "my-agent");

const client = new Client({ name: "my-agent", version: "1.0" }, {});
await client.connect(transport);

// Every callTool() is now cryptographically signed
const result = await client.callTool({
  name: "echo",
  arguments: { message: "Hello!" },
});

每个 tools/call 请求都会将已签名的收据注入到 params._meta._signet 中。

MCP 服务器验证

如果你也控制 MCP 服务器，请在执行前验证请求：

import { verifyRequest } from "@signet-auth/mcp-server";

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const verified = verifyRequest(request, {
    trustedKeys: ["ed25519:..."],
    maxAge: 300,
  });
  if (!verified.ok) return { content: [{ type: "text", text: verified.error }], isError: true };
  console.log(`Verified: ${verified.signerName}`);
  // process tool call...
});

Vercel AI SDK 集成

import { generateText } from "ai";
import { generateKeypair } from "@signet-auth/core";
import { createSignetCallbacks } from "@signet-auth/vercel-ai";

const { secretKey } = generateKeypair();
const callbacks = createSignetCallbacks(secretKey, "my-agent");

const result = await generateText({
  model: openai("gpt-4"),
  tools: { myTool },
  ...callbacks,
  prompt: "...",
});

// Every tool call is now signed
console.log(callbacks.receipts);

参考 MCP 服务器

此仓库还包含一个最小的 MCP 参考服务器，演示了使用 @signet-auth/mcp-server 进行服务器端验证。

cd examples/mcp-agent
npm ci
npm run verifier-server

可用工具：

inspect_current_request — 如果当前 MCP 工具调用包含 params._meta._signet，则验证该调用
verify_receipt — 根据公钥验证原始 Signet 收据
verify_request_payload — 离线验证合成的 MCP tools/call 有效负载

环境变量：

SIGNET_TRUSTED_KEYS — 以逗号分隔的 ed25519:<base64> 公钥
SIGNET_REQUIRE_SIGNATURE — true 或 false（默认 false）
SIGNET_MAX_AGE — 收据最大有效期（秒，默认 300）
SIGNET_EXPECTED_TARGET — 可选的预期 receipt.action.target

独立 MCP 签名服务器

@signet-auth/mcp-tools 将 Signet 签名、验证和内容哈希作为 MCP 工具公开 — 插入任何兼容 MCP 的客户端：

npx @signet-auth/mcp-tools

可用工具：signet_generate_keypair, signet_sign, signet_verify, signet_content_hash。

Python (LangChain / CrewAI / AutoGen + 6 更多)

pip install signet-auth

from signet_auth import SigningAgent

# Create an agent identity (saved to ~/.signet/keys/)
agent = SigningAgent.create("my-agent", owner="willamhou")

# Sign any tool call -- receipt is auto-appended to audit log
receipt = agent.sign("github_create_issue", params={"title": "fix bug"})

# Verify
assert agent.verify(receipt)

# Query audit log
for record in agent.audit_query(since="24h"):
    print(f"{record.receipt.ts} {record.receipt.action.tool}")

LangChain 集成

from signet_auth import SigningAgent
from signet_auth.langchain import SignetCallbackHandler

agent = SigningAgent("my-agent")
handler = SignetCallbackHandler(agent)

# Every tool call is now signed + audited
chain.invoke(input, config={"callbacks": [handler]})

# Async chains supported too
from signet_auth.langchain import AsyncSignetCallbackHandler

CrewAI 集成

from signet_auth import SigningAgent
from signet_auth.crewai import install_hooks

agent = SigningAgent("my-agent")
install_hooks(agent)

# All CrewAI tool calls are now globally signed
crew.kickoff()

AutoGen 集成

from signet_auth import SigningAgent
from signet_auth.autogen import signed_tool, sign_tools

agent = SigningAgent("my-agent")

# Wrap a single tool
wrapped = signed_tool(tool, agent)

# Or wrap all tools at once
wrapped_tools = sign_tools([tool1, tool2], agent)

LangGraph 集成

LangGraph 使用 LangChain 的回调系统 — 相同的处理程序可以直接工作：

from signet_auth import SigningAgent
from signet_auth.langgraph import SignetCallbackHandler

agent = SigningAgent("my-agent")
handler = SignetCallbackHandler(agent)

result = graph.invoke(input, config={"callbacks": [handler]})

LlamaIndex 集成

from signet_auth import SigningAgent
from signet_auth.llamaindex import install_handler

agent = SigningAgent("my-agent")
handler = install_handler(agent)

# All tool call events are now signed
index = ... # your LlamaIndex setup
response = index.as_query_engine().query("What is Signet?")

# Access receipts
print(handler.receipts)

Pydantic AI 集成

from signet_auth import SigningAgent
from signet_auth.pydantic_ai_integration import SignetMiddleware

agent = SigningAgent("my-agent")
middleware = SignetMiddleware(agent)

@middleware.wrap
def my_tool(query: str) -> str:
    return f"result: {query}"

Google ADK 集成

from signet_auth import SigningAgent
from signet_auth.google_adk import SignetPlugin

agent = SigningAgent("my-agent")
plugin = SignetPlugin(agent)

# Pass as callback to ADK agent

Smolagents 集成

from signet_auth import SigningAgent
from signet_auth.smolagents import signet_step_callback

agent = SigningAgent("my-agent")
callback = signet_step_callback(agent)

bot = CodeAgent(tools=[...], model=model, step_callbacks=[callback])

OpenAI Agents SDK 集成

from signet_auth import SigningAgent
from signet_auth.openai_agents import SignetAgentHooks

agent = SigningAgent("my-agent")

oai_agent = Agent(
    name="assistant",
    hooks=SignetAgentHooks(agent),
    tools=[...],
)

注意： 工具调用参数在钩子 API 中尚不可用（issue #939）。仅签署工具名称。

低级 API

from signet_auth import generate_keypair, sign, verify, Action

kp = generate_keypair()
action = Action("github_create_issue", params={"title": "fix bug"})
receipt = sign(kp.secret_key, action, "my-agent", "willamhou")
assert verify(receipt, kp.public_key)

双边收据（服务器共同签名）

from signet_auth import generate_keypair, sign, sign_bilateral, verify_bilateral, Action

# Agent signs the tool call
agent_kp = generate_keypair()
action = Action("github_create_issue", params={"title": "fix bug"})
agent_receipt = sign(agent_kp.secret_key, action, "my-agent")

# Server co-signs with the response
server_kp = generate_keypair()
bilateral = sign_bilateral(
    server_kp.secret_key, agent_receipt,
    {"content": [{"type": "text", "text": "issue #42 created"}]},
    "github-server",
)
assert verify_bilateral(bilateral, server_kp.public_key)
assert bilateral.v == 3  # v3 = bilateral receipt

工作原理

Your Agent
    |
    v
SigningTransport (wraps any MCP transport)
    |
    +---> Signs each tool call (Ed25519)
    +---> Appends Action Receipt to local audit log (hash-chained)
    +---> Forwards request to MCP server (unchanged)

仅代理端。MCP 服务器无需更改。

操作收据

每个工具调用都会产生一个已签名的收据：

{
  "v": 1,
  "id": "rec_e7039e7e7714e84f...",
  "action": {
    "tool": "github_create_issue",
    "params": {"title": "fix bug"},
    "params_hash": "sha256:b878192252cb...",
    "target": "mcp://github.local",
    "transport": "stdio"
  },
  "signer": {
    "pubkey": "ed25519:0CRkURt/tc6r...",
    "name": "demo-bot",
    "owner": "willamhou"
  },
  "ts": "2026-03-29T23:24:03.309Z",
  "nonce": "rnd_dcd4e135799393...",
  "sig": "ed25519:6KUohbnSmehP..."
}

签名涵盖整个收据主体（操作 + 签名者 + 时间戳 + 随机数），使用 RFC 8785 (JCS) 规范 JSON。修改任何字段都会使签名失效。

CLI 命令

命令	描述
`signet identity generate --name <n>`	生成 Ed25519 身份（默认加密）
`signet identity generate --unencrypted`	生成不加密的身份（用于 CI）
`signet identity list`	列出所有身份
`signet identity export --name <n>`	将公钥导出为 JSON
`signet sign --key <n> --tool <t> --params <json> --target <uri>`	签署操作
`signet sign --hash-only`	仅存储参数哈希（非原始参数）
`signet sign --output <file>`	将收据写入文件而不是 stdout
`signet sign --no-log`	跳过审计日志追加
`signet verify <receipt.json> --pubkey <name>`	验证收据签名
`signet verify --chain`	验证审计日志哈希链完整性
`signet audit`	列出最近的操作
`signet audit --since <duration>`	按时间过滤（例如 24h, 7d）
`signet audit --tool <substring>`	按工具名称过滤
`signet audit --verify`	验证所有收据签名
`signet audit --export <file>`	将记录导出为 JSON
`signet claude install`	安装 Claude Code 插件 (PostToolUse 签名钩子)
`signet claude uninstall`	卸载 Claude Code 插件

通过交互式提示或 SIGNET_PASSPHRASE 环境变量（用于 CI）传递密码。

文档

文档	描述
架构	系统设计、组件概述、数据流
安全	加密原语、威胁模型、密钥存储
MCP 集成指南	使用 SigningTransport 进行 MCP 设置的分步指南
CI/CD 集成	GitHub Actions 示例，CI 的密钥管理
[审计日志指南](docs

Available Tools

4 tools

signet_content_hashA

Compute SHA-256 hash of canonical JSON (RFC 8785 JCS). Accepts any JSON value.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	JSON content to hash (object, array, string, number, boolean, or null)

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It transparently states the computation (SHA-256 hash) and the canonicalization method (RFC 8785 JCS). It discloses no side effects or permissions needed, which is acceptable for a pure computation tool. However, it could mention that the output is a hex-encoded string.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences. It front-loads the action ('Compute SHA-256 hash') and the specification ('RFC 8785 JCS'). Every word contributes meaningfully without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 parameter, no nested objects, no output schema), the description is mostly complete. It covers the input and the core operation. However, it could mention that the return value is a hex-encoded hash string, as this is not obvious from the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the baseline is 3. The description adds 'any JSON value' which is already in the schema's parameter description. No additional semantics are provided beyond what the schema already conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Compute SHA-256 hash of canonical JSON (RFC 8785 JCS). Accepts any JSON value.' It specifies the algorithm (SHA-256), the canonicalization standard (JCS), and the accepted input types. This distinctly sets it apart from sibling tools like signet_sign and signet_verify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the tool's purpose is clear, the description does not provide guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contexts where hashing is preferred over signing/verification. Usage is implied but not explicitly guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

signet_generate_keypairA

Generate a new Ed25519 keypair. Returns only the public key. Use Signet CLI to manage secret keys securely.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that the secret key is not returned and points to CLI for secure management, providing critical behavioral context beyond the schema. No annotations present, so description carries full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no redundancy, front-loading the key action and outcome.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose and output limitation. Lacks detail on public key format or usage, but adequate for a simple key generation tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in schema; description adds no parameter info but baseline is 4 for zero-parameter tools. Sufficient for the tool's simplicity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Generate a new Ed25519 keypair' and specifies it returns only the public key, distinguishing it from siblings like sign, verify, and content_hash.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using Signet CLI for secret key management, giving implicit guidance on when not to use this tool. Lacks explicit alternatives but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

signet_signA

Sign an action (tool call) with an Ed25519 key, producing a cryptographic receipt. Uses SIGNET_SECRET_KEY env var if set, otherwise requires secret_key argument.

ParametersJSON Schema

Name	Required	Description
`secret_key`	No	Base64 secret key (optional if SIGNET_SECRET_KEY env is set)
`tool`	Yes	Tool name being called
`params`	No	Tool parameters (any JSON value)
`signer_name`	Yes	Agent name
`signer_owner`	No	Agent owner (optional)
`target`	No	Target MCP server URI

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It mentions key sources but omits edge cases (e.g., both env and arg provided), error behavior, and the receipt format, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with verb and resource, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters and no output schema, the description explains the signing action but omits the return value (cryptographic receipt structure), which is needed for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3). The description adds value by explaining the secret_key's optionality via env var fallback, which is not fully captured in the schema description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Sign' and resource 'action (tool call)' with Ed25519 key, clearly distinguishing it from sibling tools like verification or key generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains two key sourcing methods (env var vs argument) but lacks explicit guidance on when to use signing versus other tools or prerequisites like key availability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

signet_verifyA

Verify a Signet receipt signature. Returns {valid: true/false}. Accepts both bare base64 and ed25519:-prefixed public keys.

ParametersJSON Schema

Name	Required	Description	Default
`receipt_json`	Yes	Receipt JSON string
`public_key`	Yes	Public key (base64 or ed25519:base64)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite lacking annotations, the description discloses the return format and key format flexibility, providing sufficient behavioral context for a read-only verification operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is succinct, with two sentences that front-load the primary purpose and add key detail without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple verification tool with no output schema, the description covers the return structure and key parameter details, making it sufficiently complete for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for both parameters, and the description adds value by explaining the accepted public key formats (bare base64 or ed25519:base64), enriching the schema's simple type definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies a Signet receipt signature, explicitly lists the return value as {valid: true/false}, and specifies accepted key formats, distinguishing it from sibling tools that deal with content hashing, key generation, and signing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for verifying signatures but does not provide explicit guidance on when to use this tool vs siblings, nor does it mention prerequisites or error conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.10.0May 12, 2026
- Addedsignet_content_hash
- Addedsignet_generate_keypair
- Addedsignet_sign
- Addedsignet_verify

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-05-12 04:55 across 4 tools

Disambiguation5/5

Each tool performs a distinct cryptographic operation: hashing, key generation, signing, and verification. No overlap in purpose reduces ambiguity.

Naming Consistency4/5

Tools follow a 'signet_' prefix pattern. Most use verb_noun (generate_keypair, sign, verify), but 'content_hash' is noun_noun. Minor inconsistency but still clear.

Tool Count5/5

Four tools is well-scoped for a cryptographic signing server. Each tool is essential, covering the core workflow without bloat.

Completeness5/5

The tool set covers the full signing lifecycle: input representation (hash), key generation, signing, and verification. No obvious gaps for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Security
111
AccordTrace A
io.github.Kosta1985
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Security AI & Machine Learning
91
CipherHUB Cryptography Toolkit A
io.github.bowenerchen
Production-grade cryptography toolkit with 31 MCP tools for classical, PQC, and KMS workflows.
Security Developer Tools
552
runtime
com.formatho
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Developer Tools Blockchain Security
1

Related MCP Servers

aip-identity
Autonomous Agents Security
The-Nexus-Guard
A
license
A
quality
D
maintenance
MCP server for AI agent identity — verify agents with Ed25519 signatures, check trust scores, sign and verify content, exchange encrypted messages. Built on the Agent Identity Protocol (AIP).
Updated 6 months ago (2026-03-09 12:03 UTC)
8
MIT
agent-services-mcp
Security Testing & QA Tools
Gareth1953
A
license
A
quality
F
maintenance
A thin MCP server that wraps provenance-receipts and quality-gate services as tools, enabling AI agents to certify content origin and score quality via Ed25519-signed receipts.
Updated 3 months ago (2026-06-22 05:35 UTC)
5
55 npm
MIT
touchstone-mcpofficial
Security Autonomous Agents
Touchstone-CV
A
license
Not graded
quality
C
maintenance
Local MCP server that signs and records agent actions into a tamper-evident log using Ed25519 keys for frictionless integration with Touchstone.
Updated 19 days ago (2026-09-03 09:51 UTC)
24 npm
Apache 2.0
fallimmig-us-mcp
Autonomous Agents Developer Tools
sjgant80-hub
A
license
Not graded
quality
C
maintenance
A sovereign, MIT-licensed MCP server for professional-service workflows, providing offline-capable, Ed25519-signed tools for autonomous agents and human developers.
Updated a month ago (2026-08-17 17:08 UTC)
MIT

为什么选择 Signet

30 秒内试用

选择你的路径

查看它拒绝错误请求

团队何时需要 Signet

Signet 是什么，不是什么

安装

快速入门

Claude Code 插件

Codex 插件

CLI

MCP 客户端集成 (TypeScript)

MCP 服务器验证

Vercel AI SDK 集成

参考 MCP 服务器

独立 MCP 签名服务器

Python (LangChain / CrewAI / AutoGen + 6 更多)

LangChain 集成

CrewAI 集成

AutoGen 集成

LangGraph 集成

LlamaIndex 集成

Pydantic AI 集成

Google ADK 集成

Smolagents 集成

OpenAI Agents SDK 集成

低级 API

双边收据（服务器共同签名）

工作原理

操作收据

CLI 命令

文档

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

touchstone-mcpofficial