This server provides AI agent behavioral governance through covenant-based rules, runtime enforcement, and cryptographically verifiable audit trails.
Set Covenant Rules (set_rules): Define behavioral policies using permit, forbid, and require syntax (e.g., 'forbid delete_user', 'permit read_data'), establishing what actions are allowed or blocked.
Check Action Compliance (check_action): Evaluate whether a specific action (with optional parameters) is permitted or blocked under the active rules, enabling pre-execution enforcement before an action runs.
Retrieve Audit Log (get_audit_log): Fetch the full hash-chained audit trail of all compliance checks, providing a tamper-evident history of every action evaluation.
Verify Log Integrity (verify_log): Independently verify the cryptographic integrity of the audit log to detect any tampering, ensuring the trustworthiness of the agent's behavioral history.
Provides GitHub repository hosting for the Nobulex project, including source code, documentation, and issue tracking for the proof-of-behavior protocol.
Hosts the Nobulex repository with CI/CD workflows, documentation, and community collaboration features for the proof-of-behavior protocol development.
Provides drop-in compliance middleware for LangChain, allowing behavioral rule enforcement and cryptographic proof of agent actions within LangChain applications.
Provides npm package distribution for the Nobulex SDK and related packages, enabling installation and integration via npm ecosystem.
Provides PyPI distribution for langchain-nobulex package, enabling Python developers to integrate proof-of-behavior verification into LangChain applications.
Provides TypeScript SDK and packages for implementing proof-of-behavior protocol, with strict TypeScript support for type-safe behavioral rule definition and verification.
This repository is a prior direction, kept rather than deleted.
Nobulex is now the independent reliability registry for agent tools. The current work is at arian-gogani/nobulex-registry and nobulex.com.
Same name, different thing. This one was a protocol for agents to earn a trust score through verified behavior, which answers "can this agent be trusted with more access." The question that turned out to matter was one layer down: when an agent calls a tool, did the tool tell it the truth? A receipt proving that an agent faithfully acted on a wrong answer is a receipt for a wrong answer.
Nothing below is retracted. The code runs, the spec draft says what it says, and the published packages do what they claim. It is simply not what is being built now, and a repository that goes on quietly describing a live product nobody is building is doing the exact thing the current project exists to grade.
Every person has a credit score. Every business has one. AI agents have nothing.
Nobulex is the credit and trust protocol for autonomous AI agents. Agents earn trust score through verified behavior. Higher trust, more access. Autonomy earned, not granted.
Website · Try it live · Quickstart · Spec · PyPI · npm
Reference implementation of the OWASP Agentic Skills Top 10 — AST09 execution-receipt pattern · listed in the OWASP solutions catalog · in the Microsoft Agent Governance Toolkit adopters · merged to the Dify marketplace
Break the AI. Win $7,400.
Five AI agents, each with rules they must not break. Make them violate their own rules. Beat Level 5 to claim the bounty. 2,847 attempts, 0 winners so far.
pip install nobulexnpm install @nobulex/corefrom nobulex.agent import Agent
agent = Agent("my-agent")
receipt = agent.act("send_email", scope="user@example.com")
assert receipt.verify() # tamper-proofRelated MCP server: Agent Receipts
Every agent action produces a cryptographic receipt -- Ed25519 signed before and after execution, hash-chained for tamper evidence. A third party can verify the full history without trusting the agent or the operator.
Here is the whole idea in one run (python -m nobulex demo):
generated 3 receipts
allow: 141ca2947a7e819b8bdebbf8... verified=True
allow: f3377758ac94d812535cbb99... verified=True
deny: 85b2dfd6b87f2678795726e4... verified=True
trust score: 23.26
tamper test:
modified receipt verified=False (tamper detected)Change one byte of a receipt and verification fails. That is the whole guarantee.
Performance: ~13,683 signed receipts/sec at p50 (Python SDK, single core). Full signed-and-chained receipt takes ~73 μs end-to-end. See BENCHMARKS.md for the full breakdown; reproduce with python3 scripts/benchmark.py.
Receipts accumulate into trust score -- a credit score for the agent.
Tier | trust score | Access Level |
Restricted | 0 -- 30 | Read-only, sandboxed execution |
Standard | 30 -- 60 | Financial ops up to $500, API access |
Trusted | 60 -- 85 | Cross-org operations, regulated markets |
Sovereign | 85+ | Full autonomy, self-directed |
Agents that create more value earn more access. Agents that deviate get cut off automatically. Not as punishment -- as math.
pip install nobulexOne line to add receipts to any function:
from nobulex import track
@track(agent_id="my-agent")
def send_email(to, subject, body):
# your existing code, unchanged
return smtp.send(to, subject, body)
# Every call now produces a signed receipt automatically
send_email("user@example.com", "Hello", "Report attached")
# Success = receipt. Exception = DENY receipt. Trust score accumulates.
print(send_email.receipts) # signed, tamper-evident
print(send_email.trust_score) # earned over timeOr use the Agent API directly:
from nobulex import Agent
agent = Agent("my-agent")
receipt = agent.act("send_email", scope="user@example.com")
assert receipt.verify() # any third party can check
print(agent.trust_score) # builds with every actionfrom nobulex.integrations.langchain import NobulexAuditHandler
handler = NobulexAuditHandler(agent_id="my-agent")
agent.invoke({"input": "..."}, config={"callbacks": [handler]})
handler.export("audit.json") # signed, hash-chained audit trailfrom nobulex.integrations.crewai import NobulexCrewAudit
audit = NobulexCrewAudit(agent_id="my-crew")
audit.record_task("credit_check", "loan-app-4821")
audit.export("audit.json")from nobulex.integrations.google_adk import NobulexADKCallback
cb = NobulexADKCallback(agent_id="my-agent")
@cb.wrap_tool("web_search")
def search(query):
return do_search(query)
cb.export("audit.json")from nobulex.integrations.pydantic_ai import NobulexPydanticAIAudit
audit = NobulexPydanticAIAudit(agent_id="typed-agent")
audit.record_tool("get_weather", {"city": "Berlin"}, {"temp": 22})
audit.export("audit.json")from nobulex.integrations.haystack import NobulexHaystackAudit
audit = NobulexHaystackAudit(agent_id="my-pipeline")
audit.record_component("Retriever", {"query": "test"}, {"docs": 5})
audit.export("audit.json")from nobulex.integrations.llama_index import NobulexLlamaIndexAudit
audit = NobulexLlamaIndexAudit(agent_id="llama-agent")
audit.record_tool("web_search", {"query": "test"}, {"results": 5})
audit.export("audit.json")from nobulex.chain import verify_audit_trail
report = verify_audit_trail("audit.json", authorized_keys=AGENT_PUBLIC_KEY)
assert report["chain_intact"] and report["authenticated"]npm install @nobulex/core
npx tsx examples/trust-capital-demo.tsAgent starts at RESTRICTED tier (trust score: 0)
Action 1: read_data - ALLOWED (trust score: 12)
Action 2: read_data - ALLOWED (trust score: 24)
Action 3: process_payment - BLOCKED (insufficient trust)
Action 4: read_data - ALLOWED (trust score: 36)
Action 5: read_data - ALLOWED (trust score: 48)
Agent promoted to STANDARD tier
Action 6: process_payment - ALLOWED (trust score: 65)
Agent promoted to TRUSTED tier (trust score: 89)
Action 8: approve_contract - ALLOWEDAn agent key is free to generate. So if the score lives on the key, the score is theater: an agent with a bad record deletes the key, makes a new one, and starts clean in thirty seconds. A human can't do that with a credit score, because the SSN is scarce. That scarcity is what makes a score mean anything.
So the file doesn't live on the key. It lives on the operator: the legal entity accountable for the agent. Agents inherit trust from their operator the way a corporate card inherits its limit from the company rather than from the plastic.
from nobulex import Agent, OperatorRegistry, VerificationLevel
registry = OperatorRegistry()
registry.register("acme", "Acme Corporation", VerificationLevel.KYB)
registry.bind_agent("acme", agent.public_key)
# The question a relying party actually asks:
registry.is_accountable(agent.public_key, VerificationLevel.KYB) # True
registry.operator_for(agent.public_key).legal_name # "Acme Corporation"Burning a key doesn't escape the record:
before the burn | after | |
agent's own score | 8.0 | 0.0 (fresh key) |
operator score | 8.0 | 3.4 (history survived) |
churn ratio | 0.0 | 0.5 (the burn is visible) |
new agent starts at | 2.72, not 0 |
And the attack doesn't work one level up either: an unverified operator
can claim a score of 99 and passes exactly 0.0 to a new agent, so
registering fake operators to farm trust fails by construction.
Meanwhile the honest operator gets paid for it. Acme at 90 with zero churn means their next agent starts at 60 instead of 0. That's the reason to bind keys rather than stay anonymous.
python packages/python/examples/sybil_resistance.pyDECLARE ──► ENFORCE ──► PROVE ──► ACCUMULATE
Covenant Pre-execution Receipt chain trust score
defines receipt blocks verified by earned over
the rules violations third parties time
before they
happen ──► more access
──► more receipts
──► higher trustThe flywheel: more trust score leads to more valuable work, which produces more receipts, which builds higher trust score. Accountability becomes the most profitable strategy.
import { createDID, parseSource, EnforcementMiddleware, verify } from '@nobulex/core';
const agent = await createDID();
const spec = parseSource(`
covenant SafeTrader {
permit read;
permit transfer (amount <= 500);
forbid transfer (amount > 500);
forbid delete;
}
`);
const mw = new EnforcementMiddleware({ agentDid: agent.did, spec });
await mw.execute(
{ action: 'transfer', params: { amount: 300 } }, // allowed
async () => ({ success: true }),
);
await mw.execute(
{ action: 'transfer', params: { amount: 600 } }, // BLOCKED before execution
async () => ({ success: true }), // never runs
);
const result = verify(spec, mw.getLog());
console.log(result.compliant); // trueIndependent, verifiable signals (each links to evidence):
What | Evidence | |
OWASP Agentic Skills Top 10 (AST09) | Bilateral receipt pattern merged as normative guidance (PR #35). Vendor listing in the solutions catalog (PR #38). Fixture-corpus proposal (PR #46, merged as a discussion doc, not a normative spec). All merged by project lead Ken Huang, Jun-Jul 2026. The | |
IETF Conformance | draft-farley-acta-signed-receipts: 4/4 vectors pass. Implementation PR #12 filed | |
OWASP CheatSheetSeries | Sections 8-11 (JCS canonicalization, cross-agent accountability, sanctions-list freshness, regulatory mapping) merged into master by Jim Manico, Jun 2026 (PR #2210) | |
Dify Plugin Marketplace | Plugin merged into official dify-plugins repository (PR #2500). Nobulex receipts available to 90K+ star Dify ecosystem | |
Microsoft AI Agents for Beginners | PR open to add nobulex as the Python production receipt library in Lesson 18 - Securing AI Agents with Cryptographic Receipts (PR #571) | |
AgentAudit AI | Design-partner conversation. A signed specimen receipt verifies end-to-end in 10 lines of Python (fixture) | |
Microsoft AGT | Listed in ADOPTERS (PR merged by Microsoft maintainers) | |
builderz-labs / mission-control | Cross-session trust score RFC accepted as open issue; TypeScript reference implementation delivered |
EU AI Act Article 12 enforcement: December 2, 2027.
Receipts verify offline with the SDK today — no server, no network, no callback:
from nobulex.agent import Agent
agent = Agent("billing-bot")
receipt = agent.act("charge", scope="invoice:042")
assert receipt.verify() # recomputes action_ref + checks the Ed25519 signature, offlineThe hosted verification layer is the paid product — rate-limited tiers,
agent trust scores, and regulator-ready compliance reports. It is implemented in
packages/verify-api/ (Flask + Dockerfile) and is
not yet deployed to nobulex.com.
Endpoint | What it does | Tier |
| Verify signature + recompute action_ref | Free |
| Verify chain integrity | Pro |
| Compliance report for regulators | Pro |
| Trust score (A-F grade) | Free |
| Live tamper detection demo | Free |
Planned pricing: Free 100/day · Pro ($99/mo) 10K/day · Scale ($499/mo) unlimited.
AI agents are being deployed into production with no accountability infrastructure.
86% of AI agents deployed without security approval (CSA, 2026)
UUMit launched the first A2A marketplace with zero identity verification
$138B+ committed to physical AI with zero accountability layer
Top models score 10-15% on real problems (LemmaBench) with zero traceability on failure
The agents are deployed. The money is flowing. The accountability infrastructure doesn't exist yet. We're building it.
Standard | Status |
Proof-of-Behavior spec | |
Microsoft AGT | Listed in ADOPTERS (PR merged) |
CTEF v0.3.2 | 14/14 byte-match conformance |
A2A Protocol | Receipt row proposed; URN scheme |
NIST RFI | Formal comments submitted |
git clone https://github.com/arian-gogani/nobulex.git
cd nobulex && npm install
npx vitest run # tests
npx tsx examples/demo.ts # end-to-end
npx tsx benchmarks/bench.ts # benchmarksWebsite · Try it · npm · Spec · X @nobulexlabs
Curated resource: Awesome AI Agent Accountability — standards, regulations, and tools for verifiable agent behavior.
Star this repo to follow the project
MIT License
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
