IRC-A

IRC-A: Zero-Trust Agent Gateway & Semantic Mesh on Google Cloud. Dynamic FAISS capability discovery, PASETO cryptographic access control, and enterprise governance for institutional AI fleets.

Comment

Inspiration

IRC-A was born from a simple observation: every multi-agent system I saw in production was repeating the same architectural mistakes we made twenty years ago with ESBs and monolithic orchestrators.

After two decades building mission-critical systems at Citibank and Bloomberg, I watched the AI agent space fall into three traps:

  1. The Orchestration Monolith — LangGraph, CrewAI, AutoGen forcing developers into rigid DAGs that required full redeployment when a single tool changed.
  2. The Prompt-Bloat Tax — Developers stuffing entire JSON schemas into system prompts, burning 679+ tokens per call just describing tools.
  3. The Privilege Escalation Nightmare — Conversational agents holding high-privilege credentials, ready to execute any prompt-injected command.

The spark came from three unlikely sources:

  • Alan Kay's Smalltalk — Isolated objects communicating via late-bound messages. An object does not know the internals of another; it only knows the message it wants to send. IRC-A applies this to AI agents: the Agent is the object, the Gateway is the message router, the MCP Server is the receiver.
  • Martin Fowler's Bounded Contexts — The #triage-general, #historial-medico, and #citas channels in IRC-A are not just ACL labels. They are anti-corruption layers between domains. The Gateway enforces these boundaries at the infrastructure layer.
  • The ESB Catastrophe — Enterprise Service Buses started as pipes and became distributed monoliths. IRC-A's BFA Gateway is intentionally not an ESB. It is a registry and customs office: it stamps your passport (the DET) and tells you which gate to use. It does not fly the plane.

The name itself — IRC-A: Internet Relay Chat for Agents — is a deliberate callback to the original IRC protocol. In 1988, IRC solved human-to-human discovery and communication across channels. In 2026, IRC-A solves agent-to-agent discovery and capability routing across semantic channels. Same philosophy, different intelligence.

What it does

IRC-A is a zero-trust agent gateway and semantic capability mesh that lets enterprise AI fleets self-discover, self-register, and communicate without hardcoded URLs or monolithic orchestration graphs.

The Four Pillars (Fortified Enterprise Fleet Track)

1. Discovery & Lifecycle (Agent Registry)

  • FastMCP tool servers self-register capabilities via /register with Ed25519 challenge-response
  • The Gateway embeds capability descriptions into a local FAISS index using all-MiniLM-L6-v2
  • Agents discover tools by sending natural-language intents to /discover — zero LLM tokens, pure cosine similarity
  • Synonyms work natively: "schedule a visit" and "book an appointment" route to the same tool

2. Security & Governance (Zero-Trust Identity & Model Armor)

  • Every node generates an Ed25519 keypair on boot
  • Registration is a cryptographic handshake, not a simple POST
  • DETs (Dynamic Ephemeral Tickets): PASETO v4.public tokens scoped to a specific function and parameter set, signed by the Gateway, validated offline by the target
  • Channel masking: Capabilities on #historial-medico are completely invisible to agents on #triage-general — not "403 Forbidden", but "capability not found"

3. Runtime & Concurrency (Agent Execution)

  • 100% non-blocking async architecture
  • Dual-LLM resilient fallbacks: OpenAI GPT-4o primary, Google Gemini 3.5 Pro fallback via the Google GenAI SDK
  • AsyncOpenAI + client.aio.models.generate_content — no thread ever blocks on I/O

4. Institutional Telemetry (Observability)

  • OpenTelemetry-aligned audit events: REGISTRATION, DISCOVERY (with semantic confidence scores), EXECUTION, LLM_FALLBACK
  • Real-time dashboard on Google Cloud Monitoring showing the live topology

The Dr. Cureta Healthcare Fleet (Reference Implementation)

A live multi-agent deployment on Google Cloud Run demonstrating zero-trust isolation in a regulated environment:

  • Triage Agent (#triage-general, #citas) — Books appointments, cannot see EHR
  • Pediatrics Agent (#pediatrics, #citas) — Pediatric care decisions
  • Oncology Agent (#oncology, #historial-medico) — Cancer protocols
  • EHR MCP (#historial-medico) — Holds PostgreSQL credentials, validates DETs offline
  • Appointments MCP (#citas) — Calendar management

How we built it

Architecture

User -> Triage Agent -> BFA Gateway (FAISS + Registry) -> DET + mTLS -> Appointments MCP -> PostgreSQL
                                     |
                                     +-- Channel Masking -> EHR MCP INVISIBLE to Triage Agent

Stack

Layer Technology
Gateway FastAPI, FAISS, sentence-transformers, PASETO v4.public
Agent SDK BFAAgent base class with AsyncOpenAI + Google GenAI SDK
MCP SDK BFAMCP base class with offline DET validation
Embeddings all-MiniLM-L6-v2 (local), text-embedding-3-small (Cloud Run)
Crypto Ed25519 keypairs, PASETO v4.public (PyNaCl)
Deployment Multi-stage Docker, Google Cloud Run
Telemetry OpenTelemetry, Google Cloud Monitoring

Key Design Decisions

  • Environment-aware embedders: Local models for dev, OpenAI API for Cloud Run (solves the 45-second cold-start problem)
  • Whitelist-style DET validation: Only Gateway-restricted params are verified; server-enriched defaults are ignored
  • Semantic confidence threshold: /discover rejects matches below 0.80 — a wrong answer confidently delivered is an incident

Challenges we ran into

1. Vector Space Semantic Ambiguity

Three tools (fetch_patient_history, fetch_appointment_schedule, fetch_billing_record) all contained the word "patient". FAISS returned confidence scores clustered between 0.72–0.78. The agent called all three. In healthcare, that is a HIPAA incident.

Fix: Redesigned capability cards with deterministic, non-overlapping semantic boundaries and introduced a 0.80 confidence threshold.

2. The Event Loop Starvation Bug

A synchronous openai.chat.completions.create() buried inside an async /discover route blocked the event loop for 2–3 seconds. With 20 concurrent agents, the health check died. Cloud Run panicked and spun up new instances, which also hung. Cascading failure.

Fix: Complete refactor to 100% non-blocking async I/O. AsyncOpenAI and google.genai.aio became mandatory. Any sync I/O in an async path is a P0 bug.

3. The DET Parameter Hash Mismatch

The validator enforced exact dictionary equality between restricted_params and runtime_args. When the MCP server enriched a call with include_inactive=False, the DET rejected a legitimate request.

Fix: Evolved to whitelist-style lockdown — only Gateway-restricted keys are verified. Server defaults are ignored.

4. Serverless Cold Start

The Gateway took 45 seconds to boot on Cloud Run because it downloaded a 400MB sentence-transformers model on every container spin-up.

Fix: Three-tier embedding initialization — local models for dev, OpenAI API for Cloud Run, MD5 hashing for CI. Cold start dropped to under 3 seconds.

Accomplishments that we're proud of

  • Zero-trust by invisibility, not rejection: The Triage Agent cannot discover the EHR server exists. Not "403 Forbidden". "Capability not found."
  • Offline DET validation: The MCP server validates PASETO tokens using only the Gateway's public key — no network round-trip, no single point of failure.
  • Semantic routing at zero token cost: FAISS cosine similarity routes intents to tools without ever calling an LLM.
  • The Hall of Mirrors Debate: A community challenge from @Nyx533 that forced us to articulate why authorization cannot audit intent — and why the banking analogy (SWIFT does not validate your cognitive plan) is the right boundary.
  • Dev.to Top 7 Post of the Week: The tutorial version of this project broke through the noise, validating that zero-trust architecture resonates with developers.

What we learned

  • Descriptions are routing logic, not documentation. In semantic routing, a capability card is an API contract. Writing it well is a design activity.
  • Zero-trust does not mean zero-pragmatism. A security model that breaks legitimate operations will be bypassed by engineers at 2 AM. Design for the 3 AM pager.
  • Serverless and ML models are natural enemies. The solution is not abandoning serverless — it is making the heavy infrastructure someone else's problem.
  • The event loop is a shared resource. Blocking it is a denial-of-service attack on yourself.
  • Community debate sharpens architecture. The best features in IRC-A — Cryptographic Intent Binding, provenance-aware resolution, whitelist validation — came from Dev.to comment threads, not whiteboard sessions.

What's next for IRC-A

  1. Google ADK Integration: Port the agent reasoning layer to the Google Agent Development Kit for native ecosystem integration while preserving zero-trust gateway semantics.
  2. Model Armor GA: Deepen integration with Google's Model Armor API for prompt injection filtering at the Gateway perimeter.
  3. Edge Embedding Optimization: Hardware-accelerated local transformers for air-gapped deployments.
  4. Cross-Language SDKs: Standardize the A2A handshake and DET format for Go and Rust execution nodes.
  5. Provenance-Aware Resolution: A hardening from @Nyx533 — gate capabilities through signed identity, publisher metadata, schema digest, and revocation state before FAISS ever scores them.

IRC-A is an open protocol. Full documentation, SDK, and the whitepaper live at irc-a.org.

Built With

  • a2a
  • asyncopenai
  • docker
  • ed25519
  • faiss
  • fastapi
  • gemini-3.5-pro
  • google-cloud-monitoring
  • google-cloud-run
  • google-genai-sdk
  • mtls
  • openai-gpt-4o
  • opentelemetry
  • paseto-v4.public
  • postgresql
  • python
  • sentence-transformers
Share this project:

Updates

Submission history