The proof of concept went well. An AI agent read incoming referral letters, extracted the clinical details, checked them against the hospital’s scheduling rules, and drafted appointment proposals for staff to confirm. Clinicians liked it. The operations director wanted it live by the next quarter.
Then the security review came back. The agent framework was fine and the model ran on approved infrastructure, but the orchestration service that kept the agent’s workflows running was a multi-tenant SaaS product. Every step of every run, including the referral content, would be stored on the vendor’s servers. The answer was no.
If you work in healthcare, government, defense, critical infrastructure or a heavily regulated European enterprise, you’ve probably seen a version of this story. The AI part is increasingly solvable on your own terms: models can be hosted privately or run on approved cloud regions. The part that keeps getting stuck is everything around the model, the infrastructure that makes agents reliable enough for production.
Why the orchestration layer is the hidden data problem
When people think about AI and data residency, they think about the model: where prompts are sent and where outputs are generated. That matters, but it’s only part of the picture.
Production agents need an orchestration layer to survive crashes, retries, long waits and human approvals. Whether you call it a workflow engine or a durable execution platform, it works by persisting the agent’s state and history: the inputs and outputs of every model call and tool call, every intermediate decision, every pause.
For a clinical or citizen-services agent, that history is sensitive data. It includes:
- Extracted patient or citizen details
- Copies of documents the agent read
- Results of lookups in internal systems
- Draft decisions and the reasons behind them
So even if the model never leaves your network, a SaaS orchestration service can quietly become the largest store of sensitive AI data in your architecture, and one you don’t control.
The usual workarounds and their costs
Teams blocked by this tend to try one of three things.
Strip the agent down. Remove durability and run the agent as a simple, stateless request. That passes security review, but the agent then fails silently whenever a pod restarts or an internal API times out, which is not acceptable for referrals, benefits claims or case management.
Build orchestration in-house. A small team writes its own state machine on top of a database. It works for the first use case and then turns into a permanent maintenance burden that nobody budgeted for.
Negotiate exceptions. Sometimes a data processing agreement and a long risk assessment get a SaaS product approved. That can take months, and it often comes with conditions that limit what the agent is allowed to see, which in turn limits what it can do.
None of these scales to the dozens of agentic use cases most public-sector and healthcare organizations are now exploring.
What “sovereign” agent infrastructure needs to look like
The alternative is to run the full agent stack, including durable orchestration, inside infrastructure you control. In practice that means checking for five things.
- Self-hosted or bring-your-own-cloud deployment. The orchestration runtime and its state run in your own cloud account, private data center or government cloud region.
- State in your own databases. Execution history is stored in a database you already operate and secure, such as PostgreSQL, rather than in a proprietary store.
- Air-gap compatibility. For defense, intelligence and some healthcare environments, the platform must run with no outbound internet connectivity at all, including for licensing, telemetry and updates.
- Zero-trust networking by default. Agents, tools and services authenticate with workload identities and talk over mutual TLS, so a compromised component can’t impersonate another.
- An auditable record. Every step the agent takes is recorded in a form you can export and show to an auditor, ideally with tamper evidence.
How open-source building blocks help
One reason this is more achievable now than a few years ago is the maturity of open-source distributed-application runtimes. Dapr, a graduated project in the Cloud Native Computing Foundation, includes a durable workflow engine that runs as a sidecar next to your application and stores state in pluggable databases. It can be deployed on Kubernetes, on virtual machines or on bare metal, with no dependency on any external service.
Because Dapr workflows can wrap existing agent frameworks such as LangGraph, CrewAI or Microsoft Agent Framework, teams can keep the agent logic they’ve already built and change only the runtime underneath. Each model call and tool call becomes a recorded, recoverable step. Human approvals become durable waits that can last days without holding compute. Calls between services are encrypted with mTLS using identities issued by Dapr’s own certificate authority, which you can root in your organization’s PKI.
Where a commercial platform fits
Open source gets you the building blocks. What it doesn’t give you is someone to call at 2 a.m., hardened distributions, or the higher-level capabilities regulated teams increasingly ask for.
Several vendors build on Dapr for these environments. One example is Diagrid, whose Catalyst platform can be run in a customer’s own cloud account, on-premises or fully air-gapped, with state kept in the customer’s databases. It adds capabilities such as cryptographically signed execution history, which lets an auditor verify that an agent’s record hasn’t been altered, alongside the reliability features of the underlying workflow engine. For public bodies, that can be the difference between “AI pilot” and “AI service”: the same agent, with the same model, but a runtime the security team can sign off.
As with any vendor, verify the deployment claims in your own environment. Ask specifically what, if anything, phones home, and test an installation with outbound traffic blocked.
A realistic path to production
For a healthcare or public-sector team with a promising pilot and a blocked security review, a practical sequence looks like this:
- Map the data flow end to end. Document every place agent data is stored or transmitted, including orchestration state, logs and traces, not just the model endpoint.
- Pick a self-hostable durable runtime. Choose an orchestration layer that runs entirely inside your boundary and stores state in a database you already govern.
- Keep your agent framework. Wrap the existing agent instead of rewriting it, so the pilot’s logic and evaluation results carry over.
- Bring identity in-house. Issue workload identities from your own certificate authority, and require mTLS for every agent-to-tool and agent-to-agent call.
- Make human oversight a real step. Model clinical or caseworker approval as a durable wait, so it’s recorded and attributable rather than happening in email.
- Test the air gap. Even if production will have controlled egress, prove the stack works with none. It’s the simplest way to show the security team exactly what leaves the network.
- Hand the auditor a record. Before go-live, ask an internal auditor to reconstruct one complete agent run from the stored history alone.
Conclusion
For organizations whose data can’t leave the building, the barrier to production AI agents is rarely the model anymore. It’s the infrastructure that makes agents dependable, and the assumption that such infrastructure has to be someone else’s SaaS. It doesn’t. With self-hosted durable execution, workload identity and an auditable execution history, healthcare providers, government agencies and regulated enterprises can run agentic workflows on their own terms, inside their own network, and still get the reliability that production demands.
