Middleware vs Sidecar: two ways to govern AI agents

My background is in event streaming governance, with schema registries, contract validation and compliance layers for Kafka-based architectures. The job was always to sit between components, enforcing rules and keeping 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. However, none of them talk to each other, so there is neither a shared policy nor a 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. It is one Go binary with a YAML policy, centralized traces and per-agent identity, and it works with anything that speaks MCP or HTTP.

Four days ago, Microsoft dropped the Agent Governance Toolkit. It is open-source under MIT and addresses the same problem space with a 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. Its policy checks run in under a millisecond and the integration is deep, since 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. It requires no code changes, because your agent points to flux7-mesh instead of the real backend. flux7-mesh checks the policy and logs the trace, then forwards or denies the call.

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

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. None of Claude Code, Cursor, Gemini CLI, Cline or OpenCode expose Python callback hooks, so Microsoft AGT can't govern them. A sidecar proxy can, because it operates at the protocol level.

LangChain and CrewAI

LangChain has LangSmith Fleet, with agent identity, permissions and sandboxes. These are real features, but they are 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 is quality control rather than governance, because you can't block a dangerous action before it happens.

Neither provides cross-agent policy-as-code.

Kong, Gravitee and Apigee

Update, 29 September 2026. Gateways moved faster than this section. Kong's AI Gateway now reads the token of an MCP call and allows or refuses each tool from its scopes, and agentgateway writes the same rule in CEL. So a gateway does know which agent calls, and can say "create_issue yes, delete_repo no". However, it still does not look at the arguments, keep a call waiting for a human, or remember what was decided before. That is where flux7 now sits, behind the gateway rather than beside it; the demo runs mesh7 behind a Kong Konnect node, with Keycloak delegating a human's rights to the agent.

These are AI gateways that govern north-south traffic between your apps and LLMs, which is a different layer entirely. They handle rate limiting, PII redaction, semantic routing and model abstraction, which matters but is 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.

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)

Several observations follow from this table.

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 rather than 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, whereas flux7-mesh intercepts at the protocol boundary. Hence the coverage is the same, but the blast radius differs if the governance layer itself is compromised.

Gateways (Kong, Gravitee, Apigee) cover almost none of this, since they weren't designed for it. They govern LLM traffic rather than agent behavior, which is fine for a different layer. However, if someone tells you their AI gateway handles agentic security, check which ASIs it addresses.

The real question

The agentic ecosystem is splitting into two governance models:

1. Framework-level : deep and fast, but locked to one stack
2. Protocol-level : universal and free of code changes, 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.

---