DEV Community

Cover image for I proposed a rules layer for the A2A protocol. Here's why.
Tang Haoran
Tang Haoran

Posted on

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

#ai #security #llm #machinelearning

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.
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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))
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)