Why a dedicated tunnel?
The 9 technical and compliance reasons why Rela AI doesn't use our customers' corporate VPN — and what you gain from a dedicated WireGuard peer.
Why don't we use your corporate VPN?
When we negotiate access to a new customer, the most common proposal from the IT team is "we'll give you credentials to our corporate VPN". It makes sense from their perspective: it already exists, it's already configured, they know how to manage it. But if we accept, we'd be creating several serious technical and compliance problems. That's why we require a dedicated tunnel to the OT infrastructure. Here are the 9 reasons, ordered by severity.
What a dedicated tunnel is for
So Rela AI can reach the customer's PLC without traversing their corporate network (IT) or mixing with employee traffic. Traffic enters at one point, touches only the OT subnet, and leaves — with full traceability and instant revocability.
How it works
WireGuard establishes a point-to-point tunnel with Curve25519 encryption, asymmetric-key authentication, and routing controlled by allowed-ips. We restrict allowed-ips to the customer's OT subnet; everything else stays outside the tunnel's reach. The private key lives on the customer's router and never leaves.
The 9 reasons
1. Isolates IT from OT (IEC 62443 / Purdue Model)
The industrial cybersecurity standard IEC 62443 (and its ancestor ISA-99 / Purdue Model) requires that OT layer access doesn't share the path of IT layer access. Using the corporate VPN collapses that separation the moment a packet arrives: audit dead, findable for auditors.
2. Least privilege
A typical corporate VPN user reaches the entire network: SharePoint, Jira, mail, printers, ERP, and the OT network. We only need to read the PLC. Reducing privilege means a stolen credential affects one subnet, not the whole company.
3. Reduce blast radius on breach
If Rela AI is breached with corporate VPN credentials, the attacker reaches your entire corporation. With isolated WireGuard and allowed-ips=10.200.X.0/24, the same attacker only reaches the OT subnet you already exposed on purpose. The asymmetry of risk works in your favor.
4. CISA / NIST SP 800-82 compliance
The CISA and NIST Industrial Security guides (Special Publication 800-82) explicitly recommend:
"Remote vendor access to OT environments SHALL use dedicated, purpose-specific connections separated from general-purpose corporate remote access."
Translation: if they audit your plant, using the corporate VPN for an external vendor is a findable.
5. Machine-to-machine MFA is an antipattern
Your corporate VPN almost certainly requires MFA (Duo push, TOTP, SAML). It's designed for humans who approve. We're a machine polling every 5 seconds. The options are all bad:
- Store the TOTP secret → the MFA credential becomes static (defeats MFA's purpose).
- Use bypass flags in your IdP → audit gap for your SOC.
- Disable MFA for that user → your CISO says no.
WireGuard is rotatable asymmetric-key authentication, designed for machines from day 1.
6. Zero Trust alignment
The standard replacing "corporate VPN + trusted network" is Zero Trust (NIST SP 800-207). Philosophy: "never trust the network, always verify". WireGuard with explicit peer + limited allowed-ips is exactly microsegmentation. Corporate VPN is the antipattern Zero Trust is retiring.
7. Asymmetric key custody
| Your corporate VPN | Dedicated WireGuard | |
|---|---|---|
| Who holds your credential? | Us (user/pass in a secret) | Your router (local private key) |
| How do you revoke? | You call your IT team | You remove the peer on your router |
| Revocation time | Hours (if there's a ticket) | Seconds |
| Does it expire? | Yes, by password policy | Never (rotate when you want) |
| Can we access if you drop us? | Only if IT is notified in time | Impossible — the key lives in your hardware |
8. Traceability and compliance
When your SOC 2, ISO 27001 or IEC 62443 auditor asks "who can reach your PLCs?", with corporate VPN the answer is:
"Rela AI has a VPN user, but also 400 employees, 12 consultants, and here's a 6-month log all mixed together."
Impossible to demonstrate control.
With dedicated WireGuard:
"The
rela-aipeer with public keyabc…and allowed-ips10.200.7.0/24. Latest handshake 3 seconds ago. Here's the handshake log for the last 90 days."
Auditor signs off and leaves.
9. Data leakage via full-tunnel
If your corporate VPN forces full-tunnel (all traffic from the remote station flows through your network), our traffic to MongoDB Atlas, Gemini API, SendGrid, etc., would flow through your corporate firewall. That:
- Makes you responsible for data that isn't yours (privacy / GDPR).
- Exposes metadata from all our tenants to your SOC.
- Breaks contractual SLAs with our other customers.
With dedicated WireGuard + limited allowed-ips, only the traffic to the OT subnet crosses your network. The rest goes straight out from Cloud Run to the internet.
Benefits
- Compliance guaranteed: IEC 62443 § 6.4, SOC 2 CC6.6, ISO 27001 A.9.2.
- Zero Trust aligned: satisfies NIST SP 800-207.
- Zero licensing cost: WireGuard is open source.
- Revocation in seconds: no dependence on IT tickets.
- Per-peer traceability: the auditor sees exactly who can reach what.
What if my IT still wants to use their corporate VPN?
For the reasons above, we don't support it. If your IT insists on an "you connect as clients to my corporate VPN" model, that's outside self-service and falls under custom deployment with enterprise pricing — it requires a dedicated IPsec IKEv2 site-to-site tunnel (not corporate user/pass), and we still recommend the standard model.
The correct path is documented in Setup and Configuration.
How to test that the VPN works
Technical checklist to validate the WireGuard tunnel with Rela AI end-to-end: from the first handshake to reading the PLC, with copy-paste commands and category-based troubleshooting.
Collections — Data Templates
Define the structure of the data you store in Rela AI. Collections are the database that AI agents query in real time during conversations.