Default trust model, network controls, and simple protection patterns for Enrai.

Security

Enrai ships without built-in authentication by default.

That is intentional for the current product shape: Enrai is a coding workspace with real file access, shell execution, PTY sessions, and Codex-driven changes in a live workdir. The expected default is a trusted environment, not a public multi-tenant SaaS surface.

Default security posture

Treat Enrai as an internal tool.

Recommended default assumptions:

Run it on a trusted machine or private subnet.
Put it behind a firewall.
Do not expose it directly to the public internet without adding access controls.
Assume anyone who reaches the UI can read and modify real project files.

Browser hardening

The frontend now ships with browser-side anti-embed and basic hardening headers:

Content-Security-Policy
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy

Important note:

frame-ancestors 'none' and X-Frame-Options: DENY mean the Enrai UI is not meant to be embedded inside third-party iframes.
This is intentional to reduce clickjacking risk.
It does not prevent Enrai from using its own preview iframe to render external preview targets.

Good deployment patterns

Reverse proxy in front of Enrai

The safest default pattern is:

Internet or private network -> reverse proxy -> Enrai on localhost:3001

This gives you one clean place to add:

TLS termination
Basic HTTP authentication
IP allowlists
request logging
future SSO or access gateway policies

Jump server or bastion host

Another good model is to run Enrai on a private host and only reach it through:

a jump server
SSH port forwarding
a VPN

This works well if you want Enrai available to operators without making it broadly reachable.

Security groups or IP allowlists

If you deploy Enrai on a VM or cloud instance, restrict inbound traffic to known operator IPs.

Examples:

your office IP
your home IP
your VPN egress IP
your bastion host

If you already use a cloud firewall or security group, this is usually the first control to add.

Basic HTTP auth example

If you want a fast first layer of protection, put Enrai behind Basic Auth at the reverse proxy.

Nginx with Basic Auth and WebSockets

server {
  listen 443 ssl http2;
  server_name enrai.internal.example.com;

  ssl_certificate     /etc/ssl/certs/enrai.crt;
  ssl_certificate_key /etc/ssl/private/enrai.key;

  auth_basic "Restricted Enrai";
  auth_basic_user_file /etc/nginx/.htpasswd-enrai;

  location / {
    proxy_pass http://127.0.0.1:3001;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

Generate the password file with something like:

htpasswd -c /etc/nginx/.htpasswd-enrai admin

Apache httpd with Basic Auth and WebSockets

<VirtualHost *:443>
  ServerName enrai.internal.example.com

  SSLEngine on
  SSLCertificateFile /etc/ssl/certs/enrai.crt
  SSLCertificateKeyFile /etc/ssl/private/enrai.key

  <Location />
    AuthType Basic
    AuthName "Restricted Enrai"
    AuthUserFile /etc/apache2/.htpasswd-enrai
    Require valid-user
  </Location>

  ProxyPreserveHost On
  ProxyRequests Off

  RewriteEngine On
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule /(.*) ws://127.0.0.1:3001/$1 [P,L]
  RewriteCond %{HTTP:Upgrade} !=websocket [NC]
  RewriteRule /(.*) http://127.0.0.1:3001/$1 [P,L]
</VirtualHost>

Make sure these modules are enabled:

a2enmod proxy proxy_http proxy_wstunnel rewrite ssl auth_basic

Caddy with Basic Auth and WebSockets

enrai.internal.example.com {
  basicauth {
    admin $2a$14$ReplaceThisWithABcryptHash
  }

  reverse_proxy 127.0.0.1:3001
}

Caddy handles WebSocket upgrades automatically through reverse_proxy, so this is a very clean option if you want modern defaults and low config overhead.

This is not meant to be the final enterprise auth story. It is just a practical first guardrail that is easy to add today.

Layering controls

A reasonable staged hardening plan looks like this:

Keep Enrai on a private host or behind a firewall.
Put a reverse proxy in front of it.
Add Basic Auth or another auth layer at the proxy.
Restrict source IPs with a security group, allowlist, or VPN.
Use a jump server or bastion path for higher-trust environments.

What Enrai does not do for you yet

Out of the box, Enrai does not currently provide:

built-in user accounts
built-in RBAC
per-project authorization boundaries
hardened multi-tenant isolation

If you need those controls, add them at the network and proxy layer first, then evolve the application surface later.

Practical recommendation

If you want the simplest safe-ish setup today:

run Enrai on a private host
expose it only through Nginx or Caddy
enable Basic Auth
restrict traffic to trusted IPs or a VPN

That gets you a much better posture than exposing the raw app directly.

Security

On this page