Your data does not have to be the first target. A trusted supplier can be enough.

A company can keep its servers updated, train its staff and restrict document access — and still be affected by a supplier’s compromised infrastructure. An attack does not have to start in your office. Sometimes changing a component your system already trusts is enough.

Local AI for business can reduce the number of external systems that receive corporate information. But installing a model on your own server does not automatically create a secure environment. You also need to know where updates come from, what permissions an agent has and where it can send data. The Coder registry incident shows why these questions belong at the beginning of an AI project.

According to Coder’s September 4, 2026 report, an attacker compromised a Cloudflare API key on August 31 and redirected some registry.coder.com traffic to a server they controlled. Between 07:35 and 21:45 UTC — 14 hours and 10 minutes — that server delivered modified registry modules. Coder said its own codebase and Google Cloud infrastructure were not compromised. Coder · Registry Security Incident ↗

Terraform modules are reusable infrastructure definitions used to set up working environments. The altered modules contained code designed to find and exfiltrate secrets. Coder’s security advisory identifies potentially accessible cloud and AI API keys, CI/CD credentials and, in certain scenarios, user tokens and SSH keys. Which secrets were accessible depended on configuration and the operation performed. Coder · GHSA-vx42-ghc9-gw65 ↗

Coder reported no indication of impact to customer data maintained by Coder itself. It also said it could not conclusively identify every affected deployment because some communication took place with a server it did not control. These statements address different scopes: no detected impact in one environment does not establish the absence of exposure in every customer environment.

The broader lesson is that a trusted download address does not, by itself, prove the authenticity of what it delivers. This is also not evidence that “all of Cloudflare was hacked”: Coder describes a compromised key and infrastructure configuration serving its own registry. Facts were checked on September 8, 2026. Affected users should consult Coder’s maintained advisory for current technical remediation guidance.

Suppose you trust a carrier to deliver a sealed package. Checking the seal at the warehouse is useful, but you still need to establish what actually arrived. Software distribution channels, module registries and routing administration create comparable trust relationships.

An enterprise AI service may depend on a model provider, a cloud platform, identity services, monitoring and document recognition. Separately, it depends on libraries, containers and updates. These are not a universal linear chain through which every document travels. Some dependencies participate in each request; others matter during installation and maintenance.

Business owners need to distinguish two questions. Who receives the content of a contract when someone asks for a summary? And who can change the software that processes that contract? Even if documents never leave the office, a compromised update may gain access to them inside the company.

Supply chain risk therefore needs its own management process. NIST addresses it throughout a system’s lifecycle, from supplier selection and acquisition to operation. Strong protection at one participant does not remove the need to assess the system’s other dependencies. NIST · Cybersecurity Supply Chain Risk Management ↗

A general assistant can answer a question such as “How should I prepare for a meeting?” A useful enterprise assistant receives a different kind of context: customer history, contract terms, costs, internal correspondence and business constraints. Without it, the answer may be too generic to help.

In retrieval-augmented generation, or RAG, a system searches a knowledge base and passes relevant extracts to a model. Those extracts may contain confidential information. If generation uses a cloud model, storing the original file locally does not mean its contents remain local. The full path matters: recognition, embedding, indexing, retrieval, generation and logging.

The more useful enterprise AI becomes, the more sensitive context it needs.

Tool access adds another dimension. Reading a commercial proposal and sending it to a customer are different levels of authority. An agent that can read every document, access email and change the CRM connects several business processes. The consequences of an error depend on its permissions as well as the model’s quality.

This does not make every AI service riskier than every SaaS product. Risk depends on data, permissions and integrations. But a general-purpose assistant can connect information that used to sit in separate systems. Its security design needs to account for those new connections.

In a cloud workflow, the request and approved context are sent to an external AI API. Retention, provider staff access, subcontractors and logging depend on the particular service and contract. Do not assume every cloud provider trains on corporate data, or assume the opposite without checking the selected product’s terms.

In a local workflow, the model, knowledge base and request processing can operate on company infrastructure. The request then does not require sending its content to an external model provider. This reduces external data transfer and lets the company define access, update and retention rules. Document recognition, embeddings and diagnostics must also be local or separately approved.

The diagram shows a local system’s cloud connection separately. It can be useful when a task exceeds the selected local model’s capabilities. But the transfer should be explicit: what information leaves, who receives it, why and under which rules. An unnoticed fallback to an external API undermines the intended boundary.

The term private AI does not describe the architecture by itself. It can refer to an owned server or a dedicated provider environment. Discuss actual data flows, rather than relying on a product label. “AI without the cloud” is a property of a specific workflow that can be checked, not a consequence of having a compact computer in the office.

We use Corporate Sovereignty to describe a company’s ability to make and verify decisions about its own information environment. Storage location matters, but is insufficient. A server in the next room offers limited control if an unknown account administers it or backups cannot be recovered without the vendor.

Practical control starts with clear answers:

• Where are originals, search indexes, conversation history and backups stored?
• Which models and external services receive request content?
• Which documents are indexed, and who approved their inclusion?
• How do employee permissions constrain knowledge searches?
• Which actions can agents take independently, and which require approval?
• Can the company disconnect an integration, revoke a key and export its data?

This does not require isolating the business from the world. Public website copy might use an approved cloud model while customer margin calculations remain local. The distinction should follow business policy and be enforced in the system, rather than depending on every employee’s caution.

The AI Office concept centres on a compact local AI station. Core corporate information, the RAG knowledge base, agent history and management context can remain on company infrastructure. The actual configuration, integrations and security controls are defined for each project and verified during a pilot.

The following are design principles and implementation requirements. They are not a claim that every delivery configuration already implements every control automatically.

• Local-first: where possible, tasks run locally, including document preparation and retrieval. Any required external processing should be identified in advance.
• Cloud optional: cloud models are connected for agreed scenarios and permitted data. A failure must not silently bypass the restriction.
• Least privilege: agents receive only the documents, tools and permissions their tasks need. Access to everything “just in case” should not be the default.
• Human approval: external communication, deletion and other critical actions require confirmation that explains the consequences.
• Audit everything: significant data access and agent actions should be traceable — who initiated a request, which tool was called and what happened. Secrets should be excluded from logs, and access to the logs restricted.
• Encrypted backups: copies are encrypted, stored separately from the main station and regularly tested through restoration. Responsibility for the copies and decryption keys must be assigned.

The value is the ability to set boundaries around actual work. A sales assistant may need an approved price list and its customer’s history. It does not automatically need payroll, accounting credentials or every contract in the group. That permission decision must then be verified technically.

A local model remains a software system. It needs updates, protected administration, controlled integrations and maintained hardware. Stolen credentials, malicious components, configuration mistakes, device loss and excessive employee permissions remain possible.

The Coder case is useful precisely because a customer-hosted deployment can still depend on an external registry. If a local AI station freely downloads and runs new components, its location does not remove supply chain risk. Agreed sources, authenticity checks where available, pinned reviewed versions, update testing and rollback procedures still matter.

Language models also face prompt injection: a document can contain text attempting to impersonate an instruction to the agent. Local execution does not prevent a model from following it incorrectly. OWASP recommends combining least privilege, tool-call validation, monitoring and human involvement in high-risk operations. A single filter or system prompt does not replace those controls. OWASP · Prompt Injection Prevention ↗

Operational independence requires preparation too. If the station becomes unavailable, the company needs to know which processes continue manually, how to restore the knowledge base and where decryption keys are held. A backup on a drive permanently attached to the same device may be affected alongside it. Isolated backups and recovery testing are part of CISA’s ransomware guidance. CISA · StopRansomware Guide ↗

Start with one workflow and a map of its data. Drafting a public service description may be a suitable cloud use case. Searching contracts containing confidential pricing creates different requirements. Both decisions need to consider data restrictions, support and operating costs, alongside model output.

Local operation gives the company more control over storage and processing, while assigning it and its contractor more operational responsibility. Cloud services may offer convenient operations and powerful models, but require supplier assessment and clear transfer rules. A hybrid approach is useful when the boundary between these scenarios is defined and enforced.

Do not select a local AI server based on memory capacity alone. Test answer quality on real documents, response times, concurrent users and integrations. A formally local system that pushes employees to copy documents into personal cloud accounts has not achieved its data protection objective.

A useful pilot produces observable answers. Start with a small, approved set of documents and test the system’s restrictions as well as its successful path.

• Disconnect the internet and run the agreed local workflows. Establish which functions stop and why.
• Inspect outbound connections during upload, indexing and answering. Test diagnostics and error handling separately: one successful request does not prove the absence of external communication in every mode.
• Sign in as two employees with different permissions. Check that retrieval, source links and history do not expose the other department’s documents.
• Ask the agent to prepare a critical action. Confirm it is not executed before approval and the reviewer can see the recipient, content and consequences.
• Revoke access to a test document and an integration key. Check that the restriction also applies to the index, cache and subsequent requests.
• Restore from a separate backup in a test environment. Record what was recovered, how long it took and who could access the keys.

The result should be a concrete list of permitted workflows and remaining limitations. That is more useful than a general promise that “all data is secure”. Expand AI’s access after evaluating the next workflow, rather than because an earlier demonstration was impressive.

Answer quality remains important. It belongs alongside other questions: where does the model run, where is the data, who else can access it and what happens if an external supplier is compromised?

Local AI does not eliminate cyber risk. It lets a company control more of its own infrastructure and reduce the number of external systems through which critical data passes.

That requires managing dependencies, permissions, external connections and recovery alongside local execution. Together, these decisions turn model placement into a practical approach to corporate data security.

AI Office is being developed as a local AI platform for companies that want control over their data and intellectual infrastructure. Start with one process: identify the documents it needs, define the assistant’s permitted actions and verify the workflow within an agreed environment.