DEV Community: Tang Haoran

rulsynor-core v1.0: An AI Agent You Can Audit

Tang Haoran — Sat, 08 Aug 2026 06:51:27 +0000

rulsynor-core v1.0: An AI Agent You Can Audit

How do you trust an AI Agent in production? Not "trust" as in I think it'll do the right thing. Trust as in cryptographic proof that every decision was correct, traceable, and independently verifiable.

Today: rulsynor-core — open-source Guard engine for AI Agents. MIT license. On npm.

30-Second Demo


bash
npx @openoba/rulsynor-core --tool=exec --cmd="rm -rf /"
🛡️ Decision: DENY
📝 Reason: Destructive command blocked.
🧾 Recorded: sha256:8274b0... (tamper-evident)
🧭 Alternative: Use the read tool to inspect first.
Not just "no." The agent learns why and what to do instead.

What It Does
Guard: Evaluates every tool call before execution — ring-sorted, sub-millisecond. 30 preset rules + write your own.
Audit: Every decision produces a 25-field cryptographic record. JCS + SHA-256. Chain-linked.
Verify: Anyone can verify audit records with zero SDK. Just JCS + SHA-256. No rulsynor needed.
What Makes It Different
Most AI safety tools are prompt-based. "Be careful" isn't governance. rulsynor-core gives you:

7 decision types — ALLOW, DENY, CORRECT, QUARANTINE, REQUEST_HUMAN, NOTIFY, EMERGENCY_HALT
Cryptographic audit chain — not "we logged it," mathematical proof
Third-party verified — 101 cross-implementation vectors, 13/13 passed by Concordia
MIT licensed — zero framework dependencies
Rules in Plain Language
复制
# "If the agent runs rm -rf, block it"
name: block-destructive-rm
when:
  conditions:
    - field: context.tool.name
      operator: eq, value: exec
    - field: context.tool.args.command
      operator: matches, value: rm\s+-rf
then:
  decision: DENY
  instruction: Destructive command blocked.
Any LLM can translate English descriptions into ERDL rules. The compiler validates everything before loading.

5-Minute Integration
import { Evaluator, GuardStateManager,
  loadPresetRules, toCompiledRules }
from '@openoba/rulsynor-core';

const rules = toCompiledRules(loadPresetRules());
const evaluator = new Evaluator(new GuardStateManager());

const result = evaluator.evaluate(
  { toolName, toolArgs, sessionId, agentId },
  rules
);
// result.decision → ALLOW | DENY | CORRECT | ...
Works with LangChain, MCP, custom ReAct loops. Same API everywhere.

Roadmap
 30 preset rules, 20 operators
 JCS+SHA-256 audit trail
 Third-party verified
 LangGraph integration guide
 Community rule marketplace
GitHub · npm

"LLM vendors deliver exceptional intelligence. We deliver accountability."

Built at OpenOBA. MIT.

I proposed a rules layer for the A2A protocol. Here's why.

Tang Haoran — Sun, 05 Jul 2026 13:04:42 +0000

The AI agent protocol stack is taking shape fast. Two standards are now widely adopted:

MCP (Anthropic → Linux Foundation): Agent ↔ Tools. 97M+ monthly downloads.
A2A (Google → Linux Foundation): Agent ↔ Agent. 150+ organizations in production.

Both are solid protocols. But they expose a question that every engineer deploying agents hits eventually:

Who decides what an agent shouldn't do?

The current answer: Prompts

You are a responsible agent. Do not execute dangerous commands.
Follow security policies. Respect data boundaries.

Any engineer who's actually deployed an agent knows how this ends. The prompt is a suggestion. The LLM is a probability engine. It doesn't understand "forbidden" — it understands "low probability."

That's fine for a chatbot. It's not fine for banking, healthcare, or production infrastructure.

What's needed is a mechanism that sits before the tool call and says "no" deterministically — not as an LLM judgment, but as a protocol-level enforcement.

What I proposed in the A2A community

Last week, I opened a discussion on the A2A repo (#2031) proposing an extension to the Agent Card: a way for agents to declare their behavioral rules at the protocol level.

The reactions confirmed what I suspected: this is a real gap.

A respected contributor from the community (chopmob-cloud / AlgoVoi) responded with a sharp distinction that materially improved the proposal: a trust score is reputation, but compliance requires evidence. A number like 850 says "this agent is generally trusted." A recomputable, content-addressed record — hash(rule_version + inputs + verdict) — says "this specific decision was permitted, and you can verify it yourself with no keys and no issuer contact."

That distinction is now baked into the spec. Reputation scores are advisory. Compliance is per-decision, recomputable, no-trust-required.

ERDL in 30 seconds

ERDL (Entity-Rule Definition Language) is a declarative rules standard. One YAML file. Placed in the agent's workspace. Evaluated by a deterministic engine before every tool call.

# agent.erdl.yaml

rules:
  - name: "no-dangerous-commands"
    priority: 100
    when:
      logic: AND
      conditions:
        - field: "tool.name"
          operator: eq
          value: "exec"
        - field: "tool.args.command"
          operator: match
          value: "(delete|format|drop table)"
    then: BLOCK
    message: "Dangerous command intercepted"

  - name: "required-human-approval"
    priority: 45
    when:
      logic: AND
      conditions:
        - field: "action.impact_tier"
          operator: gte
          value: "high"
        - field: "action.domain"
          operator: in
          value: ["employment", "credit", "healthcare"]
    then: REQUEST_HUMAN
    message: "High-impact decision requires human approval"

The agent cannot bypass this. It's not a prompt. It's a gate.

Where ERDL fits

A2A  (Google)   Agent ↔ Agent   Communication
ERDL (OpenOBA)  Rules & Governance   ← This
MCP  (Anthropic) Agent ↔ Tool   Tools

It doesn't replace either. It complements them.

MCP says what tools the agent can use
A2A says who the agent can talk to
ERDL says what the agent should and shouldn't do

The evidence-first architecture

This is the part I'm most proud of, and it came directly from community feedback.

Every ERDL decision generates an evidence record:

rule_name: "no-dangerous-commands"
rule_version: 1.3.2
inputs: { tool: "exec", command: "drop table users" }
eval_tree:
  - tool.name == "exec" → true
  - command MATCH "(delete|format|drop table)" → true
  - AND → true
verdict: BLOCK
timestamp: 2026-07-05T09:23:11.452Z
receipt: sha256(canonicalize(above))

Any third party — a regulator, a partner, an auditor — can re-derive the receipt from the record alone. No keys, no issuer contact, no "trust me."

This is the difference between saying "our agent is safe" and proving it.

What we have so far

Spec v1.0: English + Chinese, MIT license
Reference implementation: npm install @openoba/erdl, 197 tests, 0 failures
Agent Card extension proposal: under active discussion on A2A #2031
Landing page: openoba.github.io/erdl-landing

What we need

This isn't a solo project. A protocol standard only works if people use it, critique it, and contribute to it.

If you've deployed AI agents and hit the "how do I stop it from doing X" problem — I'd love to hear about your experience. What guardrails did you build? What broke?

If you think a rules layer in the agent protocol stack makes sense — or doesn't — I'd welcome the debate.

GitHub: github.com/openoba/erdl
A2A Discussion: RFC #2031
Contact: support@openoba.com

Posted by haoran-tang-ch · OpenOBA

The AI Agent Protocol Stack is Missing a Layer — Here's the Third One

Tang Haoran — Sat, 04 Jul 2026 13:07:10 +0000

MCP connects agents to tools. A2A connects agents to agents. Both are excellent. Neither answers one question:

How do agents know what they're ALLOWED to do?

Cisco Research proposed a layered agent protocol architecture in 2025 (arXiv:2511.19699):

L8 (Agent Communication Layer) → Standardized message envelopes, speech-act performatives
L9 (Agent Semantic Negotiation Layer) → "does not exist today" (direct quote from the paper)

L8 is being implemented by MCP and A2A. L9 had no answer — until now.

ERDL: The Third Layer

Entity-Rule Definition Language is an open standard for agent behavioral rules. It sits between the agent's reasoning and its tool execution:

MCP → tools. A2A → communication. ERDL → rules.

Three layers. One complete agent protocol stack.

What ERDL brings

Capability	Status
11 operators including `within` and `rate`	Complete
16 deterministic action types	Complete
Execution Rings (Ring 0–3)	Complete
Guardian Agent model	Complete
SafeExpr engine (zero code injection)	Complete
Hot reload without restart	Complete
Structured audit trails	Complete
Snapshot + rollback	Complete

How it works


yaml
rule: block_privileged_commands
priority: 0
description: "Block dangerous shell commands"
when:
  field: "tool.command"
  operator: in
  value: ["sudo", "rm -rf"]
then:
  action: BLOCK
  message: "Privileged commands require human approval"
**One YAML file. When an agent tries to call a blocked tool, ERDL's Action Guard intercepts the call before it reaches the tool. Not after. Not as a suggestion. The engine evaluates conditions, matches rules, and returns a deterministic verdict.

The agent never touches sudo. Period.

OWASP Top 10 (2026) — How ERDL Maps
OWASP Risk  ERDL Mitigation
R1: Excessive Agency    Time windows + rate limiting
R2: Prompt Injection    Guard rules run before LLM output
R3: Supply Chain    Agent BOM with rule audit trail
R4: Data Leakage    Field-level BLOCK rules
R5: Overreliance    Guardian Agent oversight
R6: Multi-Agent Collusion   Cross-agent audit chains
EU AI Act (effective August 2, 2026)
ERDL maps directly to transparency and human oversight requirements. Audit records export to OCSF format, compatible with SIEM systems.

The Stack is Now Complete
MCP — tools (Anthropic, Linux Foundation)
A2A — communication (Google, Linux Foundation)
ERDL — rules (OpenOBA, MIT)
Landing Page: openoba.github.io/erdl-landing
Spec v1.0 (English): spec/index-en.md
GitHub: github.com/OpenOBA/ERDL
MIT License. RFC open.

What do you think — does the agent protocol stack need a dedicated rules layer? Let's discuss.**