On CUI, Agentic Engineering, and Designing Governance Boundaries

I work mostly on systems in regulated environments where agents, today, simply cannot be connected to them. It's a problem of information policy: we can't allow third-party companies access to government data, or even its code. We've found workarounds, of course: we describe generic problem "shapes" to the model, then fill in the particulars ourselves. The problem is that the shapes aren't always perfect. The model reasons well about the generic case and can't see the specifics that break it, so when our particulars don't fit, the debugging lands back on a human — and by hand, that probably costs more time than if the LLM could simply have gotten it right the first time, because it knew the system we're actually tasked with developing and maintaining.

Thinking carefully about MCP, though, I'm not sure its use necessarily, or always, violates the constraints we're under.

In the strictest sense, an MCP server exposes a few levers that can be pulled to accomplish some tasks within our system, and the model is allowed to pull them. What the model can't do is access our code. It might be useful if you can ask the agent, "Can you tell me if user XYZ has access to resource ABC?", and you've built an interface that lets the model answer that question without ever seeing your database, or a single line of code. The tool layer moves the knowledge out of the model's context and into the tool implementation. The model doesn't need to know how permissions work — only that it may ask.

The question, of course, remains: what if the prompt, or its answer, still contains CUI? But that's a risk-tolerance-adjustable design surface, not a wall. Tool inputs and outputs are where we can apply some level of access minimization. We can return booleans instead of records, or identifiers instead of names. And now every question the model asks is a discrete, reviewable event. A smaller CUI footprint isn't the same as having none at all. But a small, enumerated, logged surface is something we can write policy around.

And that's kind of the point of all this: there's a specific set of policy changes it will take to get to our agentic future, and some level of risk tolerance. But that tolerance depends on having the right infrastructure in place first, both at the level of the LLM interface itself, and at the level of access the application grants the LLM.

The path forward that doesn't involve local LLMs still seems to be authorized models inside institutionally accepted boundaries — Bedrock in GovCloud, or an equivalent accredited endpoint. Reaching that boundary is itself a modernization project. I'm already being asked to work towards it for my clients: on-prem Jenkins to GitHub Actions, on-prem Oracle toward RDS. The infrastructure is the prerequisite for the tools we know we'll eventually want. Ok, we want them today, we just can't have them yet.

So, in the long run, I think this pattern could be useful in government software engineering. tertulia-mcp exists as a proof-of-concept: it exists to solve problems I have in an environment I control, against a codebase and data I'm allowed to share (my own, and nearly all of it public). One day it won't just be Tertulia.

I advise engineering teams on AI systems architecture, security boundaries, and high-reliability modernization. See my current advisory availability and engagement models.