自主 AI 代理的行为证明协议。
每个 AI 代理都会做出承诺——“我不会转账超过 500 美元”、“我只会访问已批准的 API”、“我不会触碰生产数据”。但目前，没有任何方法可以证明代理遵守了这些承诺。日志是由被审计的同一软件编写的。合规性只是被声明，从未被证明。
Nobulex 改变了这一点。定义行为规则。在执行前强制执行。用密码学而非信任来证明合规性。
你无法审计神经网络。但你可以根据既定的承诺审计其行为。
verify(covenant, actionLog) → { compliant: boolean, violations: Violation[] }这是始终可判定的、确定性的且高效的。没有机器学习，没有启发式方法——只有数学证明。
行为证明意味着每个自主代理的行为都是：
已声明 — 在部署前以形式化语言定义行为规则
已强制执行 — 在运行时、执行前拦截违规行为
已证明 — 每个行为都通过哈希链链接到防篡改的审计追踪中，第三方可以独立验证
Related MCP server: Agent Receipts
npm install @nobulex/sdkimport { createDID } from '@nobulex/identity';
import { parseSource } from '@nobulex/covenant-lang';
import { EnforcementMiddleware } from '@nobulex/middleware';
import { verify } from '@nobulex/verification';
// 1. Create an agent identity
const agent = await createDID();
// 2. Write behavioral rules
const spec = parseSource(`
covenant SafeTrader {
permit read;
permit transfer (amount <= 500);
forbid transfer (amount > 500);
forbid delete;
}
`);
// 3. Enforce at runtime
const mw = new EnforcementMiddleware({ agentDid: agent.did, spec });
// $300 transfer — allowed
await mw.execute(
{ action: 'transfer', params: { amount: 300 } },
async () => ({ success: true }),
);
// $600 transfer — BLOCKED before execution
await mw.execute(
{ action: 'transfer', params: { amount: 600 } },
async () => ({ success: true }), // never runs
);
// 4. Prove compliance
const result = verify(spec, mw.getLog());
console.log(result.compliant); // true
console.log(result.violations); // []在两个代理进行交易之前，它们会验证彼此的行为证明。没有证明，就没有交易。
import { generateProof, verifyCounterparty } from '@nobulex/sdk';
// Agent A generates its proof-of-behavior
const proof = await generateProof({
identity: agentA,
covenant: spec,
actionLog: middleware.getLog(),
});
// Agent B verifies Agent A before transacting
const result = await verifyCounterparty(proof);
if (!result.trusted) {
console.log('Refusing transaction:', result.reason);
return; // No proof, no transaction
}
// Safe to transact — Agent A is verified
await executeTransaction(proof.agentDid, amount);握手按顺序检查六项内容：契约签名、证明签名、日志完整性、合规性、历史记录最小值以及必需的契约。如果任何检查失败，交易将被拒绝。
现有技术 | 缺失内容 |
护栏过滤提示词和输出 | 无法证明代理在行为层遵循了规则 |
监控在事后观察代理的行为 | 无法在执行前进行强制执行 |
身份验证验证代理的身份 | 无法验证代理做了什么 |
治理平台提供仪表板和策略 | 缺乏第三方可独立验证的加密证据 |
行为证明填补了这一空白：声明 → 强制执行 → 证明。
covenant SafeTrader {
permit read;
permit transfer (amount <= 500);
forbid transfer (amount > 500);
forbid delete;
require counterparty.compliance_score >= 0.8;
}禁止优先。 如果任何 forbid 匹配，无论是否允许，该行为都会立即被拦截。对于未匹配的行为，默认拒绝。条件支持对数值、字符串和布尔字段使用 >, <, >=, <=, ==, !=。
三个关键字。没有配置文件。没有 YAML。没有 JSON 模式。只有规则。
┌─────────────────────────────────────────────────────────────┐
│ Platform │
│ cli · sdk · mcp-server │
├─────────────────────────────────────────────────────────────┤
│ Proof-of-Behavior Stack │
│ │
│ ┌──────────┐ ┌──────────────┐ ┌────────────┐ │
│ │ identity │ │ covenant-lang│ │ action-log │ │
│ │ (DID) │ │ (DSL) │ │(hash-chain)│ │
│ └──────────┘ └──────────────┘ └────────────┘ │
│ │
│ ┌────────────┐ ┌──────────────┐ ┌───────────────┐ │
│ │ middleware │ │ verification │ │ composability │ │
│ │(pre-exec) │ │ (post-hoc) │ │(trust graph) │ │
│ └────────────┘ └──────────────┘ └───────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ Foundation │
│ core-types · crypto · types │
└─────────────────────────────────────────────────────────────┘包 | 功能 |
使用 Ed25519 密钥创建 W3C DID | |
受 Cedar 启发的 DSL：词法分析器、解析器、编译器 | |
带有 Merkle 证明的 SHA-256 哈希链式防篡改日志 | |
执行前强制执行 — 在运行前拦截违规行为 | |
确定性合规性验证 | |
结合所有原语的统一 API | |
适用于任何兼容 MCP 的代理的 MCP 合规服务器 | |
命令行工具： | |
LangChain 中间件集成 (PyPI) |
npm — npm install @nobulex/sdk
PyPI — pip install langchain-nobulex
MCP — npx @nobulex/mcp-server (适用于 Claude Desktop, Cursor, VS Code)
LangChain — 即插即用的合规中间件
ElizaOS — 用于行为、评估器和提供程序的插件
比特币 | 以太坊 | Nobulex | |
验证内容 | 货币转账 | 合约执行 | 代理行为 |
机制 | 工作量证明 | 权益证明 | 行为证明 |
证明内容 | 交易有效性 | 状态转换 | 行为合规性 |
保证 | 无需信任的货币 | 无需信任的合约 | 无需信任的代理 |
npx tsx demo/covenant-demo.ts创建一个脚本，定义两个代理，设定行为规则，在运行时强制执行，拦截违规转账，并以加密方式验证合规性。
git clone https://github.com/arian-gogani/nobulex.git
cd nobulex
npm install
npx vitest run # 4,237 tests, 80 files, 0 failures行为证明规范 — 正式标准规范 (CC-BY-4.0)
白皮书 — 正式协议规范
入门指南 — 开发者指南
NIST RFI 回复 — 对 NIST AI 代理标准倡议的正式评论
网站: nobulex.com
npm: @nobulex
PyPI: langchain-nobulex
NIST: Docket NIST-2025-0035 (已提交公开评论)
MIT — 随意使用。
Check whether an action is allowed or blocked by the current covenant rules.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action name to check, e.g. 'delete_user' | |
| params | No | Optional parameters for the action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It implies a read-only check with no side effects, but does not disclose auth needs, rate limits, or behavior for missing actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no wasted words. The purpose is front-loaded with the verb 'Check'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is mostly complete. It could benefit from mentioning the return format (e.g., boolean or status), but the core behavior is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for both parameters. The description adds only an example ('e.g. delete_user'), which is marginally helpful but not necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether an action is allowed or blocked by covenant rules, using specific verb 'Check' and resource 'action'. It distinguishes from siblings like set_rules and verify_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The purpose implies use for permission checking, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full hash-chained audit trail of all compliance checks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and minimal description. 'Returns' implies read-only, but doesn't disclose potential size limits, authentication needs, or what 'full' means. Important behavioral traits unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence. Efficient but could be slightly more detailed without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, description adequately states scope ('full...all compliance checks'). However, lacks output structure hints. Sibling tools provide context but description doesn't leverage them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so baseline is 4. Description adds no parameter info, but not needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it returns the full hash-chained audit trail of compliance checks, clearly identifying the verb and resource. It distinguishes from siblings like 'check_action' and 'set_rules' which are action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'verify_log'. Lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set covenant rules using permit/forbid/require syntax. Each rule is a string like 'forbid delete_user' or 'permit read_data safe to read'.
| Name | Required | Description | Default |
|---|---|---|---|
| rules | Yes | Array of rule strings, e.g. ['forbid delete_user', 'permit read_data'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states 'Set covenant rules' but does not indicate whether this is a destructive or reversible operation, what permissions are needed, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no unnecessary words. Each sentence contributes meaning: the first states what it does, the second gives format examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, no enums, no output schema), the description covers the key aspects: purpose and parameter format. It could mention whether rules are appended or replaced, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is described in the schema. The description adds value by providing concrete syntax examples ('forbid delete_user', 'permit read_data safe to read'), which clarify the expected format beyond the generic schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set covenant rules using permit/forbid/require syntax.' It specifies the verb 'Set' and the resource 'covenant rules', and provides example syntax. This distinguishes it from siblings like check_action, get_audit_log, and verify_log, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides syntax examples but lacks explicit guidance on when to use this tool versus alternatives (e.g., check_action, get_audit_log). It does not mention prerequisites or when not to use it. The usage context is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Independently verify the integrity of the hash-chained audit log. Detects any tampering.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only says 'Detects any tampering' but does not disclose the tool's return value (e.g., boolean), side effects (if any), or whether it checks against a remote source. This lack of detail forces the agent to guess the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the purpose. It is front-loaded and contains no fluff. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is adequate but not fully complete. It lacks details about the return value (e.g., does it return a boolean, raise an exception, or log results?). The agent needs more context to know how to handle the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the input schema is fully covered. Baseline for 0 parameters is 4, and the description adds no param info (none needed). The agent can invoke the tool without any parameter confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it verifies the integrity of the hash-chained audit log and detects tampering. The verb 'verify' and resource 'audit log' are specific, and the tool is easily distinguished from siblings like 'check_action' or 'get_audit_log'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or typical use scenarios. Without explicit instructions, an agent may not know when verification is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0check_actionget_audit_logset_rulesverify_logEach tool has a clearly distinct purpose: checking actions, retrieving audit logs, setting rules, and verifying log integrity. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (check_action, get_audit_log, set_rules, verify_log).
Four tools is an appropriate scope for a compliance/auditing server; each tool serves a necessary function without redundancy.
Covers core operations: rule setting, action checking, audit log retrieval, and log integrity verification. Minor gap: no explicit rule deletion or modification beyond full replacement, but this is acceptable for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/arian-gogani/nobulex'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
