WireGuard for Business: How Remote Employees Access Secure Data Without Cloud APIs

A ban on external APIs is not a ban on remote work. These are different things, and confusing them costs businesses unnecessary restrictions where they shouldn't exist.

📚 Article Contents

• 📌 Why "No External API" Doesn't Mean "No Remote Access"
• 📌 What is a VPN and How Does a Corporate VPN Differ from the Usual "VPN for Netflix"?
• 📌 How Remote Access Fits into the Architecture of a Self-Hosted Solution
• 📌 Who is Responsible for Setup – You or Your IT Department?
• 📌 What Are the Additional Costs and What Influences the Price?
• ❓ Frequently Asked Questions (FAQ)
• ✅ Conclusions

Why "No External API" Doesn't Mean "No Remote Access"

Imagine this scenario: your company operates in critical infrastructure, the legal sector, or finance. The security policy is clear – no data leaves your network, no calls to external cloud AI services. This is a logical and justified decision, often enshrined not just by internal regulations but by requirements from regulators or contractual obligations to clients. However, you have employees who work remotely, travel on business trips, are home sick with a laptop at hand, or simply want to check a document in the evening instead of waiting until morning at the office. The question is: does a ban on external APIs mean they are permanently tied to their office chairs?

A Common Misconception

When a company formulates the requirement "no external APIs," a simplified picture often forms in their mind: "everything must stay within the four walls of the office, which means employees must too." This is a logical but flawed conclusion. It arises because both scenarios – "data goes out" and "a person connects from outside" – contain the word "external," and the brain automatically groups them into a single risk category.

In reality, we are talking about two entirely different concepts:

• Where Your Data Goes – Does it end up on a third-party vendor's servers (OpenAI, Google, any SaaS) where it's processed outside your control, stored according to their retention policies, and could theoretically be used to train their models?
• From Where the Employee Connects – From what physical location do they establish a connection to your system: from their office desk, from home, from a hotel room in another city?

These are independent parameters, and this is precisely where the confusion stems from. The employee's location during connection has no bearing on whether data leaves your infrastructure after connection. It's possible to have a system that never, under any circumstances, accesses any external API – and still grant access to employees from anywhere in the world, if the network perimeter around this system is properly constructed.

The difference is roughly the same as between "who enters the bank building" and "where the bank sends its clients' money." These are two separate security issues, resolved by different tools, and should not be merged into a single requirement.

Public API to a Cloud Service vs. Private Tunnel to Your Own Infrastructure

To definitively resolve the perceived contradiction, it's worth examining both scenarios in detail – what exactly happens to the data in each case.

Calling a Cloud AI API. When a system calls a third-party provider – for example, sending a request to OpenAI or any other cloud AI service – the following happens: a fragment of a document or a user query is packaged into an HTTP request and sent to servers physically owned and managed by that provider. There, the request is processed using their resources, their software, according to rules dictated by the provider, not your company. For a period, the data physically leaves your infrastructure and falls under the jurisdiction and policies of another organization. This scenario, and only this one, is prohibited by strict security policies like "no external APIs."

Employee VPN Tunnel to Your Server. This is fundamentally different. When an employee connects via VPN, there is no call to any third-party data processing service. Instead, an encrypted "corridor" is created between the employee's device and your own server – the very server where documents are stored and the local model runs. All traffic through this corridor goes directly to your infrastructure and back. No third party gains access to the content of this traffic, does not process it, and does not even see it in decrypted form – the VPN provider (unless it's the company's own server) sees at best the connection itself, but not its content.

Therefore, the ban on the first scenario logically does not extend to the second. These are two different directions of data movement:

• In the first case, data moves outward, to external infrastructure.
• In the second, a person moves (virtually) inward, to your own infrastructure.

They are often confused precisely because of the word "external," which intuitively seems the same in both formulations – although technically, they are processes moving in opposite directions. Understanding this difference is the foundation upon which the entire architecture of secure remote access, which we will discuss in the following sections, is built.

What is a VPN and How Does a Corporate VPN Differ from the Usual "VPN for Netflix"?

Most people have heard of VPNs in the context of "watching Netflix US" or "bypassing website geo-restrictions." This is true, but it's only one possible use case for VPNs – and not the one needed by businesses. Confusion between these two scenarios often prevents non-technical executives from understanding why VPNs are considered a solution for strict security requirements – after all, "VPN for Netflix" is associated more with bypassing restrictions than with data protection.

Consumer VPN: Changing Geolocation

When you are in Kyiv and turn on a "US" VPN, your traffic doesn't go directly to the site you're visiting. Instead, it first goes to an intermediate server of the VPN provider somewhere in New York, and only then proceeds to the internet. Any site you visit sees the IP address of this intermediate server – and thinks you are physically located there, not in Kyiv.

The purpose of such a VPN is to hide or replace your real location while browsing the regular public internet. The endpoint of the route is always a publicly accessible site or service that is generally available to anyone in the world. The VPN here acts as a "mask," not a "key to locked doors."

Corporate VPN: A Tunnel into a Closed Network

A Corporate VPN solves a completely different problem. Its purpose is not to hide where you are, but to give you access to places that a regular internet user cannot access at all: the company's internal, closed network, which is generally invisible from the public internet.

There is no "intermediate server in another country" that masks your location. Instead, there is a direct encrypted connection between your device and a specific company server. This server typically doesn't even have a public IP address – meaning it's physically impossible to reach it with a regular internet request, regardless of your browser or location. The only way to get there is to have the correct access key (a certificate or configuration) that the company has issued specifically to you.

Consumer VPN vs. Corporate VPN: A Comparison

This table shows the general picture, but within the Corporate VPN category, there is also a choice – particularly between different protocols. If you're interested in a detailed comparison of WireGuard and OpenVPN for business, we've covered it in a separate article.

Analogy: A "Virtual Cable to the Office"

The easiest way to imagine a Corporate VPN is this: you're at home, and you connect a virtual network cable directly into the office network. Your laptop is technically "teleported" inside the office – you see the same internal resources you would normally access sitting at your work desk: internal services, shared folders, and in our case, the AI assistant interface at the internal server address.

At the same time, all your other internet traffic (email, regular websites, social media) does not go through this "cable" – only the traffic destined for the company's internal server. This is called split-tunneling, and it's how Corporate VPNs are usually configured – to avoid overloading the company's internal channel with unnecessary traffic and to prevent slowing down the employee's regular internet browsing.

An important nuance: unlike Consumer VPNs, where the goal is to appear as if you're "somewhere else," with Corporate VPNs, the employee's geolocation is completely irrelevant. Whether from Kyiv or a hotel in another city, the result is the same: a direct, controlled connection to the company's internal server, without any intermediate party processing or viewing the data.

Why Not Just Open the Web Interface to the Internet?

A logical question: if AskYourDocs is a web application, why not simply open a port to the outside and access it through a regular browser? In practice, this creates several serious risks immediately.

• Scanners Find It Immediately. Any open port on the internet falls within the view of automatic scanners (Shodan, masscan, and similar) within hours of appearing – regardless of how "invisible" the address seems.
• Brute-Force Attacks Begin. A login form exposed externally will almost immediately receive a flood of automated password-guessing attempts – it's a matter of "when," not "if."
• WAF is Required. To filter malicious requests (SQLi, XSS, and other application-level attacks), you have to deploy and maintain a Web Application Firewall – an additional component with its own configuration and expenses.
• Bot Protection is Required. Without a separate anti-bot/rate-limiting layer, the server wastes resources processing malicious traffic instead of real users, and logs get filled with noise, making it hard to spot actual suspicious activity.

A VPN eliminates all these risks at once: the service is simply invisible from the outside. No open port means nothing to scan, brute-force, or attack. Instead of building a defense perimeter around a public application, we remove it from the public space entirely, leaving access only through an encrypted WireGuard tunnel.

Why We Specifically Use WireGuard

We chose WireGuard not out of trendiness, but due to specific technical advantages that directly impact the speed and reliability of accessing AskYourDocs.

• Modern Cryptography. WireGuard is built on a current set of cryptographic primitives (Noise Protocol Framework, Curve25519, ChaCha20Poly1305), without outdated algorithms or "extra options" that would require separate configuration and security checks.
• Higher Speeds Compared to OpenVPN. Less protocol overhead and kernel-level operation (for Linux) provide noticeably better throughput and lower latency – this is palpable even during routine document work via AskYourDocs.
• Simpler Configuration. One configuration file with a key pair – and the client is ready to connect. No complex certificate distribution like in a classic OpenVPN setup.
• Less Code – Smaller Attack Surface. The WireGuard core is around 4,000 lines of code, compared to hundreds of thousands in OpenVPN/OpenSSL. Less code is easier to audit, and fewer places for vulnerabilities to hide.
• Cross-Platform. Official clients are available for Linux, Windows, macOS, Android, and iOS/iPhone – employees can connect from any device with equal ease.

A detailed comparison with alternatives is in our separate article: WireGuard vs. OpenVPN: What to Choose for Business.

How Remote Access Fits into the Architecture of a Self-Hosted Solution

Now let's put it all together and see how it looks at the architecture level of a self-hosted AI assistant – not abstractly, but step-by-step, from the moment an employee opens their laptop at home to when they receive a response on their screen.

The Employee's Request Path

1. The employee enables the VPN client on their device (at home, on a business trip – anywhere, location doesn't matter).
2. An encrypted tunnel is established to the company's internal network – from this moment on, the employee's device is technically "located" inside the office network.
3. The employee opens their browser and accesses the internal server address (e.g., an internal DNS alias like askyourdocs.internal) – exactly as they would from their workplace in the office.
4. The request reaches the internal server where the entire system runs – the web interface, the local LLM, the document database. All these components are physically located on one server or within the company's internal network.
5. The local model processes the request and generates a response without any external calls – document search, vector search, text generation by the model happen locally, without any HTTP requests beyond the perimeter.
6. The response travels back to the employee through the same encrypted tunnel – the same "corridor" the request came through.

At no point do the data leave the company's perimeter. There is no moment when a fragment of a document or an employee's request ends up on a third-party provider's server – the entire route, from the first to the last step, remains within the network controlled by the company itself.

Why This is Critical for Clients with Strict Requirements

For ordinary businesses, the difference between a "cloud-based" and a "self-hosted" solution often boils down to convenience – slightly longer setup for slightly more control. But for certain industries, it's not a matter of convenience but of compliance with regulatory and internal security requirements, the violation of which has very specific consequences:

• Critical Infrastructure – Leakage of technical documentation, maintenance procedures, or system schematics can have consequences far beyond reputational damage. This sector often adheres to specific cybersecurity standards (e.g., IEC 62443 for industrial control systems) that directly regulate the isolation of networks containing critical data.
• Legal Sector – Confidentiality of client documents is often contractually stipulated (NDAs, representation agreements), not just a desired best practice. Transferring client document snippets to a third-party AI provider without explicit consent can constitute a breach of these contractual obligations.
• Finance – Regulatory requirements for processing client data (depending on jurisdiction, this could be GDPR in Europe or industry standards like PCI DSS for payment data) typically directly prohibit the transfer of personal or financial data to third parties without separate permission or a data processing agreement.

Please note: The examples of regulations provided illustrate the general industry context and are not legal advice regarding compliance with your specific situation – exact compliance should be verified with your compliance department or legal counsel.

For such companies, an architecture where "everything stays within the perimeter, access is only through a controlled tunnel" is not an optional extra but a fundamental condition for even considering a solution. This is why the self-hosted approach with VPN access exists not as a compromise between security and convenience, but as a way to achieve both simultaneously: full control over data and full remote access for the team.

Comparing Remote Access Approaches

The main trade-off companies face is choosing between the convenience of cloud AI services and data control. Here's how the primary options stack up:

ChatGPT and Claude are excellent tools but are inherently cloud-based: the query and the document pass through the provider's servers. For companies with a "no cloud APIs" policy, this is unacceptable, even if the provider's model itself is considered reliable. The self-hosted option with AskYourDocs and WireGuard provides the same remote access, but without any data leaving the company's premises.

Who is Responsible for Setup – You or Your IT Department

Deploying such a system is a collaboration between two parties, and a clear division of responsibility is important from the outset.

What the Client Needs

• VPN Port — typically, one open port on the firewall/router is needed (e.g., UDP 51820 for WireGuard) – the single "door" to the outside, accepting only encrypted packets with the correct key
• Static Public IP Address or DDNS — so that employee VPN clients know where to connect
• List of Employees with Access — who exactly receives the keys/configurations for connection
• Administration Solution — whether the access list is managed by the client's own IT department or handed over to a contractor for support

What AskYourDocs Handles

• Deployment of the server itself with a local LLM, vector database, and web interface
• Configuration of the VPN infrastructure (if the client doesn't have it yet) or integration with an existing one
• Routing configuration so that the internal service is accessible exclusively through the tunnel, not directly from the internet
• Documentation and training for the client's IT department for subsequent self-management of access

For companies with heightened security requirements, the initial deployment is often conducted as a joint session with the client's IT engineer: the contractor leads the process, and the client's own personnel perform the commands on the server – this way, there's no need to grant external contractors persistent access to the internal network.

What's the Additional Cost and What Influences the Price

It's important to clarify upfront: remote access via VPN is a separate cost item beyond the base cost of deploying the AI assistant, not a hidden part of the standard price. Transparency here is crucial: the client needs to understand exactly what they are paying for.

What Influences the Cost

• Number of Employees with Remote Access — more users mean more configurations/keys and, if necessary, a more powerful VPN gateway
• Presence of Existing VPN Infrastructure at the Client's Site — if a corporate VPN is already in place, the work involves adding one new internal resource to the existing system; if not, a VPN solution needs to be deployed from scratch
• Need for a Separate Gateway — whether it's sufficient to host the VPN service on the same server running the AI assistant, or if the load requires a separate machine

The exact amount is always calculated individually after a brief discussion about the client's current infrastructure — there is no universal fixed figure here, as too much depends on the starting point of a specific company.

Common Mistakes

Over the years working with clients to set up secure access to internal systems, I regularly see the same mistakes. Almost invariably, they stem not from a lack of knowledge, but from a desire to "do it quickly now and properly later."

• ❌ Opening port 8080 externally "temporarily." In my experience, these temporary solutions never last less than several months, while scanners find such ports much faster.
• ❌ Using a single VPN key for all employees. It's convenient to distribute one configuration to the entire team, but then it's impossible to tell who exactly connected and to revoke access for one person without reconfiguring everyone else.
• ❌ Not revoking access after an employee leaves. This is the most frequent error I see during audits of a client's existing infrastructure: keys of former employees that remain active for months after they've departed.
• ❌ Not maintaining connection logs. Without logs, it's impossible to answer the simple question "who accessed the system and when," which is the first thing asked during any incident or security audit.

From my own experience: give each employee a separate WireGuard key, and include revoking access in the standard onboarding checklist, right alongside returning the laptop and access pass. It takes five minutes but closes one of the most common security vulnerabilities.

❓ Frequently Asked Questions (FAQ)

Will the VPN affect the assistant's performance speed?

A VPN adds a small network latency due to traffic encryption, but in practice, it's usually unnoticeable for regular use. We're talking milliseconds, not seconds. The primary factor for the assistant's response speed is the server's performance where the local model runs (specifically, the presence of a GPU), not the mere fact of using a VPN.

Do I need a separate server for the VPN, or can it be on the same one?

For a small to medium number of employees, a VPN service can certainly be hosted on the same server where the AI assistant runs; the additional load from VPN encryption is minimal. A separate gateway only makes sense with a large number of simultaneous connections or if the company, for security reasons, wants to separate the roles of "data server" and "network entry point."

What happens if an employee leaves – how quickly can access be revoked?

Access via VPN is based on individual keys/configurations for each employee. Revoking access means deleting or deactivating a specific key, which takes literally a minute and does not affect other employees' access. This is one of the arguments in favor of the VPN approach compared to a "shared password" – the company always retains control over each individual access.

✅ Conclusions

• The ban on external APIs concerns where your data goes, not where the employee is connecting from.
• A Corporate VPN is not a geolocation-changing tool but a private tunnel into your own closed network.
• With the correct architecture, not a single byte of data leaves the company perimeter, even when an employee is working from home or on a business trip.
• Deployment is a collaborative effort: the contractor sets up part of the infrastructure, and the client's own IT department controls the rest.
• The cost of VPN integration is a separate, transparent expense item that depends on the number of employees and the existing infrastructure.

If your company operates with strict data security requirements and you need a self-hosted AI assistant with controlled remote access, write to Telegram. We'll discuss your specific situation and the architecture that meets your exact requirements. If you'd like to see how it works first, try the live demo on the homepage.

• How to Prepare Documents for an AI Assistant: Formats, OCR, Checklist 2026
• AI for Law Firms: Data Security and Confidentiality
• AI Security: A 20-Question Checklist Before Implementation
• OCR in Modern AI Systems: From Scans to RAG