Sovereign work infrastructure: the case beyond cloud-only software

Agents read work data and act on it, which moves the sovereignty question from where data is stored to where it is processed. That question splits across four boundaries, and holding one does not mean holding the others.

A program manager asks an agent to draft the release plan for the next launch.

It reads the open work items, their comments and history, the dependencies between them, the project documentation, previous release notes, linked incidents, and whatever engineering systems it can reach. After going through hundreds of work items, it has enough context to write something worth reading.

If the agent runs against a hosted model, that context went into prompts, retrieval calls, logs, and inference infrastructure outside the organization's environment. The processing boundary moved without anyone filing a ticket about it. The database stayed where it was.

Sovereignty for work software used to be a storage question with a contractual answer, which is why procurement owned it. Agents turned it into a processing question with an architectural answer, which is why a design review owns it now.

Sovereign work infrastructure is a work system in which the organization can control the four boundaries that matter to it: the software, the data, the runtime, and the model. They are separable. A deployment usually controls some and not others.

The project tracker got promoted

The earliest computerized project tools digitized plans and schedules. Issue trackers came later and gave software teams somewhere to put bugs, owners, and dates. When SaaS arrived, it took over the plumbing too.

The economic case was obvious. Running software in-house required hardware, specialists, backups, upgrades, and somebody willing to investigate why the tracker had stopped loading at 2 a.m. Nobody bought a tracker expecting it to differentiate the business. Renting it handed that work to the vendor, who could also deal with Tuesday's patch.

Nobody mistook the tracker for the company's brain. It was the system of record, and you went to it to find out what had already happened.

But these systems kept collecting things. Product decisions and the arguments behind them. Years of engineering history. Security remediation, customer requests, roadmaps, approvals, specifications, and all the institutional knowledge that never found a more respectable home. The tracker became a remarkably complete company archive, albeit one with inconsistent labels and several abandoned workflows.

For years, people mostly consulted that archive after something happened. AI changed its job. An agent can search across projects, connect a customer request to the work it triggered, summarize months of discussion, spot delivery risks, draft a plan, and update the same system it just read. The archive now participates in the work.

The old SaaS economics still hold for many companies. The product being evaluated, however, has changed. A tracker that records execution can live almost anywhere with decent uptime. A system that participates in execution sits wherever company context meets software with permission to act.

The contracts, deployment assumptions, and data-processing terms governing that meeting were usually written when the product was still keeping score.

Start with the workload

Every deployment model has a fit. Cloud, self-hosted, and air-gapped systems solve different problems. The workload decides which one.

Some organizations run more than one, though this is the exception rather than the pattern. Most standardize on a single deployment, and a second environment usually exists because a specific workload cannot legally or contractually sit in the first. A defense contractor may keep program delivery inside a restricted enclave while corporate functions use a managed service, because the two sit in different accreditation boundaries. A hospital may apply different controls to clinical systems than to administrative ones. The split follows the security domain, not the team.

Regulated is not another word for air-gapped. Regulation sets obligations. The workload, its classification, the network, the organization's risk decisions, and its contracts determine the architecture.

Still, some decisions are already made before procurement begins. Public SaaS falls outside the permitted architecture for a defense program operating inside a disconnected network. A contract that prohibits data egress also rules out regional cloud hosting. Self-hosting or air-gapping gives these teams a deployable system.

The four boundaries that matter

"Sovereign" can describe several different kinds of control. A company may run an application on its own servers while the vendor controls the license. It may store data in Europe while an external model processes prompts elsewhere. Looking at four separate boundaries makes those gaps visible.

The software boundary

Running an application on your own infrastructure gives you control over the machine. The vendor may still control the license, releases, support, upgrade eligibility, and how long the deployed version remains usable.

Ask what happens in less comfortable circumstances. Can you pin a version? Will security fixes reach that version? Can the system keep running if the vendor changes its pricing, license, or product strategy?

Server support ended in February 2024, and Atlassian has since published an end-of-life schedule for Data Center. New customers could no longer purchase after 30 March 2026; existing customers can purchase until 30 March 2028; and affected products reach end of life on 28 March 2029, at which point subscriptions expire and instances become read-only. Those customers ran the software on their own hardware for years and still had the timetable set for them.

The data boundary

The database is only the most obvious part of the data boundary. Data also ends up in:

• search indexes and retrieval systems
• backups, logs, and telemetry
• attachments and analytics
• prompts and model outputs
• integration payloads

AI adds more routes without moving the primary database. An organization can keep its stored data in-region while prompts, retrieved context, or model outputs are processed somewhere else. The product can be working exactly as designed.

The data-processing agreement may describe storage residency, while the model provider's terms determine processing location. Reviewing the first and overlooking the second leaves a fairly large hole in the architecture review.

The runtime boundary

With SaaS, the vendor handles infrastructure, deployment, scaling, patching, and availability. Self-hosting brings that work inside the organization. Someone now has to manage upgrades, respond to vulnerabilities, monitor the system, maintain backups, test recovery, connect identity systems, and handle incidents.

This is where teams tend to overestimate themselves. Acquiring the runtime looks like buying software. Operating it means having enough people and enough discipline to keep it healthy after the implementation team has moved on.

More control is useful only when the organization can carry the work that comes with it.

The model boundary

Work management software was designed when the most ambitious thing reading a backlog was usually a program manager with a filter and a strong coffee.

An agent needs more context than the work item in front of it. It may read project history, related work, documents, incidents, dependencies, and information from other systems. That context is useful because it reflects how the organization works. It is also sensitive enough that its route to the model deserves its own review.

Most older procurement checklists never had to ask:

• Where does inference happen?
• Which model receives the context?
• What gets logged, and where do those logs live?
• Who controls the endpoint, and can it be changed?
• Can inference run entirely inside the organization's network?

Sovereign AI requires control over how data is retrieved, where inference happens, what the agent can change, and where its actions are recorded. An open-weight model answers the inference question. Retrieval, action limits, and logging are separate decisions.

Agents widened the blast radius

Traditional integrations usually request a known object and perform a defined action. Agents often retrieve a much wider slice of context before deciding what to do.

Ask why a release is at risk, and the agent may inspect unfinished work, dependency chains, incident history, customer commitments, and the latest project update. A request to triage a security report may pull in earlier findings, ownership rules, service documentation, and past remediation decisions.

Disclosure is one risk among several. An agent may summarize a restricted document into a less restricted work item, or reproduce sensitive text in a log. It may also take a permitted action for the wrong reason, because the instruction was ambiguous or the retrieved context was incomplete.

Local deployment changes who can inspect and govern the path, but the agent still needs permissions, action limits, logs, review rules, and a way to stop it. The architecture also makes certain policies possible, including local-only inference and zero external calls.

Open standards such as MCP can reduce integration lock-in by giving tools a common way to exchange context and actions. Inference location and operator jurisdiction remain architecture and contract decisions.

Regulation asks for evidence and an exit

Regulators rarely prescribe one universal hosting model for every workload. They tend to ask whether the organization understands its dependencies, controls access, records important actions, can recover from failure, and has a credible way out of third-party arrangements.

The EU Data Act has applied since 12 September 2025. Its cloud-switching provisions require providers of data-processing services to remove obstacles to switching and support a move to another provider or to on-premises infrastructure. Switching charges are prohibited from 12 January 2027.

For financial institutions, DORA has applied since 17 January 2025. It requires financial entities to manage ICT third-party risk and maintain exit strategies for relevant arrangements.

Both rules allow organizations to keep using cloud services. They also make an unexamined third-party dependency harder to defend. A buyer should know what can be exported, how long a transition would take, what functionality would be lost, and where the system could run next.

That leads to practical requirements:

• exports that preserve work, comments, attachments, relationships, history, and configuration
• retrieval windows and transition support written into the contract
• a tested recovery and exit process
• clear ownership of encryption keys, logs, and backups
• a destination that can accept the workload

A folder full of CSV files may preserve rows while losing workflows, permissions, dependencies, and the record of how decisions were made.

Control comes with operating work

Self-hosting transfers responsibility along with control. Someone has to operate the infrastructure, apply security fixes, monitor the system, test backups, manage identity, plan capacity, and recover the service after a failure. Air-gapping adds artifact movement, internal registries, isolated integrations, and offline licensing on top of that. Run the models locally and you also own model serving, evaluations, and another update schedule.

Operational capacity belongs in the buying decision. A system the customer controls but cannot maintain may be less secure than a managed service. A capable SaaS provider can patch one environment quickly and apply the fix to every customer, and smaller teams often benefit from that concentration of expertise.

In October 2023, CISA, the FBI and MS-ISAC issued a joint advisory on CVE-2023-22515, a broken access control flaw in Confluence Data Center and Server that let unauthenticated attackers create administrator accounts. Atlassian patched on October 4; CISA added it to the Known Exploited Vulnerabilities catalog on October 5; public proof-of-concept code was circulating by October 10, and threat actors used it for initial access and data exfiltration. Atlassian Cloud sites were not affected.

The flaw sat in the self-managed product line. Finding the exposed instances and applying the fix was the customer's own work, with six days between the patch shipping and working exploit code in public. The deployment model decided who had to respond. A team without the capacity for that response has taken on work it cannot do.

Architecture sets the other constraint. A disconnected network rules out a managed service that depends on vendor connectivity. A policy requiring local inference rules out a vendor-controlled model endpoint.

Make the staffing decision at the same time as the deployment decision. Runtime control needs a named owner for each of those responsibilities before go-live. Air-gapped environments also need an approved offline process for moving signed software and model updates across the boundary.

What sovereignty looks like in Plane

In Plane, sovereignty means choosing where the application, work data, and AI run, and who operates each layer. That choice runs from Plane Cloud to customer-hosted and fully air-gapped deployments.

The right one depends on which boundaries the work can cross and who is going to operate it-

Same product across deployment

Commercial has feature parity with Plane Cloud. Airgapped carries the Commercial feature set into an isolated environment.

The editions follow separate release cycles, so not every feature arrives everywhere on the same day. Procurement teams should ask about update cadence, supported versions, and the maintenance process. Plane documents the differences between editions.

Self-hosted Commercial runs on infrastructure the customer controls. The customer sets the storage, network rules, upgrade schedule, and operating procedures.

These deployments make limited outbound calls for license and seat synchronization. The calls appear in the logs and can be inspected. This setup works for organizations that want control over the stack but still allow specific connections to Plane.

Here, air-gapped means air-gapped

Plane's Airgapped Edition removes those external calls. License validation happens through an uploaded file. Telemetry is off. Once the required images and artifacts are inside the environment, Plane does not need internet access to run.

Teams mirror Plane images and updates into an internal registry, then transfer them through their approved process. The application does not phone home for license checks or fetch updates from a public registry.

Internal integrations stay inside too. Plane can connect to self-hosted GitHub Enterprise, GitLab, identity providers, and other services available within the network. Authentication, API traffic, and webhooks remain there, with no fallback to public GitHub, GitLab, or Slack endpoints. The air-gapped architecture documentation covers the network paths and operating requirements.

Bring your own AI models

Plane's self-hosted AI configuration supports OpenAI, Anthropic, AWS Bedrock, and customer-defined OpenAI-compatible endpoints. Teams can connect a model served through Ollama, a LiteLLM proxy, or another compatible endpoint. Prompts, responses, and actions are logged locally.

The customer chooses the endpoint and supplies the credentials.

A commercial team can use a public model. A regulated organization can choose a private endpoint. A defense program can keep Plane, its work data, the model, and the logs inside one disconnected environment. In restricted defense environments, Plane AI and agents can run on customer infrastructure against local models, including in fully air-gapped deployments.

Someone still has to run it

Self-hosting gives the customer control. It also gives them the maintenance window.

Customers handle infrastructure, updates, backups, monitoring, and recovery. Air-gapped teams also need a controlled process for moving approved software and model updates into the network.

A team without the people to operate that stack should probably use Plane Cloud. Teams with a hard requirement for customer-controlled infrastructure or zero external connectivity can choose self-hosted Commercial or Airgapped Edition.

See Plane's cloud, self-hosted, and fully air-gapped deployment options.

If you are working through this for a regulated environment and want to know where Plane's boundaries break, tell us. That is how we find the gaps.

Ten questions enterprise buyers should ask before believing the word “sovereign”

A vendor can put “sovereign” on a slide in five minutes. Proving it takes a blocked firewall, a readable licence, and an export the customer can restore without help.

Ask these questions while the architects are still in the room.

“Supported” is not evidence. Ask the vendor to demonstrate it, document it, and put the parts that matter into the contract.

Run both tests: block the network, then read the termination clause. Whatever still works is what you control.

Talk to our sales team to discuss your deployment requirements.