Middleware vs Sidecar: two ways to govern AI agents

Comparing Microsoft's Agent Governance Toolkit and flux7-mesh, two open-source architectures for the same problem, mapped against the OWASP Agentic Top 10.

My background is in event streaming governance: schema registries, contract validation, compliance layers for Kafka-based architectures. Always the same job: sit between components, enforce rules, keep a trace.

When I started using Claude Code and Cursor side by side, I noticed the same gap I'd seen before. Every agent has some permission model. None of them talk to each other. No shared policy. No unified trace. It felt like 2018 microservices all over again, before service meshes became a thing.

So I built flux7-mesh, a sidecar proxy for agent tool calls. YAML policy, centralized traces, per-agent identity. One Go binary, works with anything that speaks MCP or HTTP.

Four days ago, Microsoft dropped the Agent Governance Toolkit. Open-source, MIT. Same problem space. Different architecture.

Worth comparing honestly, especially now that OWASP gave us a shared vocabulary for what "agent security" actually means.

Full disclosure: Microsoft AGT dropped while I was already building flux7-mesh. I hadn't mapped against OWASP until I saw their claim of covering all 10. That comparison forced me to think harder about what a sidecar actually covers, and what it doesn't.

The two approaches

Microsoft AGT is a middleware. It runs inside your agent's process: Python callbacks for LangChain, decorators for CrewAI, plugins for ADK. Sub-millisecond policy checks. Deep integration. You add a few lines of code and your agent is governed.

flux7-mesh is a sidecar proxy. It runs next to your agents and intercepts tool calls at the MCP/HTTP level. No code changes. Your agent points to flux7-mesh instead of the real backend. flux7-mesh checks the policy, logs the trace, forwards or denies.

If you've worked with API gateways, you already know this pattern. Microsoft AGT is Express middleware. flux7-mesh is Envoy.

MIDDLEWARE — governance runs inside the agent process

SIDECAR — governance runs next to the agent, at the protocol boundary

When each approach wins

Middleware wins when:

You own the agent's code
You're all-in on one framework (LangChain, CrewAI, Semantic Kernel)
You want sub-millisecond overhead
Your agents are Python or .NET

Sidecar wins when:

You run heterogeneous agents (CLI tools + frameworks + custom bots)
You can't or won't modify agent code
You want one YAML policy for all agents
Your agents are Claude Code, Cursor, Gemini CLI, or anything MCP-native

That last point matters. Claude Code, Cursor, Gemini CLI, Cline, OpenCode: none of these expose Python callback hooks. Microsoft AGT can't govern them. A sidecar proxy can, because it operates at the protocol level.

What about LangChain and CrewAI?

LangChain has LangSmith Fleet with agent identity, permissions, sandboxes. Real features. But scoped to LangChain. If you also run Claude Code and a custom HTTP agent, LangSmith doesn't see them.

CrewAI has task guardrails, which validate after the agent produces output. That's quality control, not governance. You can't block a dangerous action before it happens.

Neither provides cross-agent policy-as-code.

What about Kong, Gravitee, Apigee?

Different layer entirely. These are AI gateways that govern north-south traffic between your apps and LLMs. Rate limiting, PII redaction, semantic routing, model abstraction. Important stuff, but not the same problem.

They don't know which agent made the call, don't enforce action-level policy (allow create_issue, deny delete_repo), and don't differentiate permissions per agent identity.

Gateways and governance meshes are complementary. You can run Gravitee in front for LLM routing and flux7-mesh behind for tool call governance. Different layers, different jobs.

Agent CLI / Framework
      |
  AI Gateway (Kong/Gravitee/Apigee)  ← LLM routing, PII, rate limits
      |
  Governance Mesh (flux7-mesh)       ← semantic policy, agent identity, trace
      |
  Tools (GitHub, DB, APIs)

Mapping to OWASP Agentic Top 10

OWASP published the Top 10 for Agentic Applications, the first serious attempt at cataloging what can go wrong when AI agents act in the real world. Peer-reviewed by 100+ security researchers. If you build or run agents, worth reading.

Here's how the landscape maps against it:

OWASP Risk	What it means	Who covers it
ASI01 — Goal Hijacking	Poisoned input redirects agent objectives	Prompt-level defenses (none of the governance tools)
ASI02 — Tool Misuse	Agent uses tools in unintended ways	flux7-mesh (semantic policy on params), Microsoft AGT (action interception)
ASI03 — Identity & Privilege Abuse	Agent abuses its tokens, roles, sessions	flux7-mesh (per-agent identity, temporal grants), Microsoft AGT (zero-trust Ed25519)
ASI04 — Delegated Trust	Blind trust between agents	flux7-mesh (policy-as-code between agents), Microsoft AGT (trust scoring)
ASI05 — Uncontrolled Autonomy	Critical decisions without human validation	flux7-mesh (human approval workflow), CLI tools (approval prompts)
ASI06 — Memory Poisoning	Persistent memory poisoned with malicious data	Not directly addressed — needs runtime sandboxing
ASI07 — Multi-Agent Comms	Inter-agent communication not secured	flux7-mesh (JWT auth on sidecar), Microsoft AGT (Agent Mesh component)
ASI08 — Cascading Failures	One agent failing triggers a chain reaction	flux7-mesh (rate limiting, loop detection), gateways (circuit breaking)
ASI09 — Emergent Behavior	Agent develops unanticipated behavior	Observability + traces (LangSmith, flux7-mesh, Microsoft AGT audit)
ASI10 — Rogue Agents	Compromised agent diverges from intended behavior	flux7-mesh (deny-by-default), Microsoft AGT (trust scoring)

A few things stand out:

No single tool covers everything. ASI01 (goal hijacking) is a prompt-level problem. No governance proxy or middleware can fix it. ASI06 (memory poisoning) needs runtime isolation, not policy.

The middleware vs sidecar split shows up clearly. Microsoft AGT and flux7-mesh cover roughly the same risks (ASI02-05, ASI07-08, ASI10), but from different positions in the stack. Microsoft intercepts inside the process. flux7-mesh intercepts at the protocol boundary. Same coverage, different blast radius if the governance layer itself is compromised.

Gateways (Kong, Gravitee, Apigee) cover almost none of this. They weren't designed for it. They govern LLM traffic, not agent behavior. That's fine, it's a different layer. But if someone tells you their AI gateway handles agentic security, check which ASIs it actually addresses.

The real question

The agentic ecosystem is splitting into two governance models:

Framework-level : deep, fast, but locked to one stack
Protocol-level : universal, zero code change, but adds a hop

My bet is that protocol-level wins long-term, the same way Envoy won over framework-specific circuit breakers. In practice, nobody runs just one framework. You'll have Claude Code for coding, a pipeline for data, a custom agent for ops. You need one policy layer that sees all of them.

But I'm biased. I built the sidecar.

flux7-mesh is open-source, written in Go. One binary, one YAML config. Works with any agent that speaks MCP or HTTP.

← back to log_