자율 AI 에이전트를 위한 행동 증명(Proof-of-behavior) 프로토콜.
모든 AI 에이전트는 약속을 합니다. "500달러 이상 송금하지 않겠다", "승인된 API에만 접근하겠다", "운영 데이터를 건드리지 않겠다"와 같은 약속들입니다. 하지만 오늘날 에이전트가 이러한 약속을 지켰는지 증명할 방법은 없습니다. 로그는 감사를 받는 바로 그 소프트웨어에 의해 작성됩니다. 규정 준수는 주장될 뿐, 결코 증명되지 않습니다.
Nobulex는 이를 바꿉니다. 행동 규칙을 정의하십시오. 실행 전에 강제하십시오. 신뢰가 아닌 암호학으로 규정 준수를 증명하십시오.
신경망을 감사할 수는 없습니다. 하지만 명시된 약속에 대한 행동은 감사할 수 있습니다.
verify(covenant, actionLog) → { compliant: boolean, violations: Violation[] }이는 항상 결정 가능하고, 항상 결정론적이며, 항상 효율적입니다. 머신러닝도, 휴리스틱도 아닌 수학적 증명입니다.
행동 증명이란 모든 자율 에이전트의 행동이 다음과 같음을 의미합니다:
선언됨 — 배포 전 공식 언어로 정의된 행동 규칙
강제됨 — 실행 전 런타임에 위반 사항 차단
증명됨 — 모든 행동이 제3자가 독립적으로 검증할 수 있는 위변조 방지 감사 추적에 해시 체인으로 연결됨
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);핸드셰이크는 계약 서명, 증명 서명, 로그 무결성, 규정 준수, 최소 기록, 필수 계약 등 6가지 항목을 순서대로 확인합니다. 검사 중 하나라도 실패하면 거래가 거부됩니다.
현재 존재하는 것 | 부족한 점 |
가드레일은 프롬프트와 출력을 필터링함 | 행동 계층에서 에이전트가 규칙을 따랐다는 증거 없음 |
모니터링은 사후에 에이전트의 행동을 관찰함 | 실행 전 강제 조치 없음 |
신원 확인은 에이전트가 누구인지 검증함 | 에이전트가 무엇을 했는지에 대한 검증 없음 |
거버넌스 플랫폼은 대시보드와 정책을 제공함 | 제3자가 독립적으로 검증할 수 있는 암호학적 증거 없음 |
행동 증명은 이 간극을 메웁니다: 선언 → 강제 → 증명.
covenant SafeTrader {
permit read;
permit transfer (amount <= 500);
forbid transfer (amount > 500);
forbid delete;
require counterparty.compliance_score >= 0.8;
}금지(forbid)가 우선합니다. 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: 렉서, 파서, 컴파일러 | |
머클 증명을 포함한 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 | |
검증 대상 | 금전적 송금 | 계약 실행 | 에이전트 행동 |
메커니즘 | 작업 증명(PoW) | 지분 증명(PoS) | 행동 증명(PoB) |
증명 내용 | 거래 유효성 | 상태 전환 | 행동 규정 준수 |
보장 | 신뢰가 필요 없는 화폐 | 신뢰가 필요 없는 계약 | 신뢰가 필요 없는 에이전트 |
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
