Execution is local
Every command, cluster call, git operation, and database query runs in an engine on your own machine, or, for a cloud connection, in a connector you deploy in your own cloud. Nothing executes on OpenEng’s servers.
Security & trust · Privacy by architectureThe work runs on your machine.
The work runs on your machine.
Private by construction.
OpenEng is local-first by design, not by policy. Both halves of the platform do their work on your own machine. Each of the five engineering apps drives a small engine that listens only on loopback (the Git and Chat engines are coming soon), so your code is never sent to OpenEng. The OpenEng AI engine runs your open-weight models locally and reads your files there. Between the browser and the engine travels what you exchange in the Web Console — your requests, its replies, and the engine data the console shows you — and it passes, encrypted, through the OpenEng Broker, which opens the requests and that engine data and keeps them for 7 days by default. The engine also registers its key and fetches configs from our API, and, if you use them, Cloud Planner requests and approval requests go to our API; a hosted model you choose receives what you send it. The browser is a thin client: it renders the work your engine does.
Loopback-only app engines Sealed per frame No engine telemetry Streamed AI replies sealed end-to-end
Engineering apps
Browsersealed ⇄Engine · 127.0.0.1
After the key-exchange handshake, the web app's session is sealed in both directions, frame by frame. Loopback only: it never leaves your machine.
OpenEng AI
BrowserBrokerYour engine
- Requests: encrypted in transit and at rest; the broker opens them to route them and keeps them 7 days by default.
- Streamed replies: sealed end-to-end; the broker cannot read them.
- Thread history, memory, and config the console loads: sealed to the broker, which opens them to deliver them and keeps them 7 days by default.
- The engine dials out and opens no network port.
No engine telemetry Secrets by reference
At a glance
Two engines, one rule: the work runs on your machine.
The five engineering apps and OpenEng AI both execute locally. What differs is how the browser reaches the engine, and so what can cross the wire.
| Property | Engineering apps | OpenEng AI |
|---|---|---|
| Where the work runs | An engine per app, on your machine | The openeng engine, on your machine; its built-in models run in its enclosed model daemon, catalog models in a local Ollama daemon |
| How the browser reaches it | Directly, over loopback (127.0.0.1) | Through the OpenEng Broker; the engine dials out |
| Listening ports | One loopback-only port per app engine, not reachable from your network | No network port: the engine binds no network socket (its model daemon uses a local Unix socket) |
| Sealed end-to-end | Every frame of the web app’s session, after the handshake (the engine doesn’t yet reject unsealed frames) | The engine’s streamed replies. Requests and the engine data the Web Console loads are encrypted in transit and at rest, and the broker opens them to route them |
| What OpenEng’s servers handle | Your sign-in, the one-time pairing key, and update checks | Your sign-in, the engine’s key registration (a Pro check) and its update checks, config fetches, approval requests, the configs, attachments, and vault values you save, Cloud Planner calls paid from planning credit, your requests, and the engine data the Web Console loads (thread history, memory, config), which the broker opens to deliver and keeps for 7 days by default — see the Privacy Policy |
| How you authenticate | Google sign-in in the app, then a one-time start command | An OpenEng key (a Console API key) passed to the engine; Pro required |
Engineering apps · the model
Four design principles, with their limits.
Terminal, Kubernetes, Data, Git, and Chat run in your browser, and each one works through a small engine you run yourself: the Terminal, Kubernetes, and Data engines today, and the Git and Chat engines when they ship.
Sealed per frame by the web app
The web app and the engine exchange session keys when they connect. After that handshake, the web app’s session is sealed in both directions, every frame with a fresh one-time key, even on your own machine. The engine doesn’t yet reject a frame that arrives unsealed or fails to open, so the seal protects the web app’s own traffic; it doesn’t keep other local programs out.
Loopback only
Each app engine listens only on 127.0.0.1, so nothing is exposed to your network. A machine-local handshake token gates every call from the page, but any process on this machine, including one under another user account on a shared host, can obtain it. The engines can’t defend against other local processes.
Your credentials stay yours
Git uses your credential helper, Kubernetes your kubeconfig. Secrets and tokens are resolved locally by the engine and are never sent to OpenEng. The one exception is the Git app’s CI/CD view: the forge API token you enter stays in that browser, which calls your forge with it directly — it never reaches OpenEng either.
What we never see
If it’s sensitive, it stays on your hardware.
Nothing about your work is sent as telemetry, and there is no server-side copy. An app engine talks to OpenEng’s cloud for only two things: exchanging the one-time key that pairs it with your account (and keeping that sign-in fresh), and checking the release feed for updates. Your own clusters, databases, and git remotes are reached directly from the engine. (The Terminal engine also downloads a small embedding model from Hugging Face once, for command suggestions.)
Never sent to OpenEng
- Your source code or repositories
- Your terminal commands or output
- Your kubeconfig, cluster data, or logs
- Your databases and connection strings
- API keys, passwords, or private keys
Under the hood
How the channel is sealed.
1
Handshake
On connect, the app and the engine exchange session public keys. It is the only unsealed call.
2
Key derivation
For every frame, the sender mints a fresh ephemeral key and derives a one-time symmetric key from it and the recipient’s session key.
3
Per-frame seal
Every request and response frame of the web app’s session is sealed with authenticated encryption, with a fresh, unique key and nonce per frame. The engine doesn’t yet reject a frame that arrives unsealed or fails to authenticate: it passes the bytes on as they arrived. Sealing is how the web app talks to the engine, not a gate the engine enforces.
4
Auth floor
A machine-local handshake token gates every call, and the default is deny. The engine hands that token to any local program that asks, including one under another user account on a shared host, so it keeps out nothing that already runs on this machine. The schema carries no field for an OpenEng secret. The only credentials that cross it are your own, such as a database connection string, sent over the sealed loopback channel and stored on your machine.
Pairing uses one-time keys
Signing in to an app with Google mints a single-use start key that expires within minutes, and the OpenEng API mints at most five unused keys an hour per account. The start command hands the key to your engine, which exchanges it once with the OpenEng API for its own session, so a copied command can’t be replayed. The browser can’t launch a program, so this step is copy and paste, never auto-run.
The same model is built into all 5 app engines: Terminal, Kubernetes, Data, Git, and Chat. Read the architecture docs.
OpenEng AI · what crosses the wire
What crosses the wire, and what never does.
The channel between the browser and your AI engine carries what you exchange in the Web Console, encrypted on every hop. Model weights, embeddings, the engine’s stored provider keys, and your OpenEng key never cross it.
Status: OpenEng AI isn’t live yet. The Console and Web Console interfaces load, but the OpenEng AI API routes and the Broker aren’t deployed. Nothing can be saved or published, and no AI engine can register or connect. Pro, Enterprise, and pay-as-you-go launch in Q4 2026 and can’t be purchased yet. Everything in the OpenEng AI half of this page is how it is built to work.
Most vendors ask you to trust a privacy policy. OpenEng executes the work on your machine: your open-weight models run there, the engine reads your files there, and your provider keys stay there. A hosted model you choose for a role receives what you send it. What crosses the wire is what you exchange in the Web Console: your requests, the engine’s streamed replies, and the engine data the console displays — your thread history, learned memory, the running config, and placeholder names. Requests and that engine data pass through our broker, encrypted in transit and at rest, and the broker can open them. The engine’s streamed replies are sealed end-to-end, so the broker cannot read them.
What never crosses
Model weights, embeddings, the engine’s stored provider keys, and your OpenEng key never cross the channel. A secret value you type into the Web Console goes one way, write-only, to the vault, and is never read back by a browser.
The models stay on your machine
Your open-weight models run locally, so local inference never leaves the box. The engine’s built-in models run on llama.cpp only inside its enclosed model daemon, never directly in the engine process: resource-capped with a systemd scope where a user systemd session works, and given a read-only root where bubblewrap works. Release builds refuse local inference on a host with neither. Catalog models run in a local Ollama daemon that you install and run. The browser is a thin client that holds no model, and it never reads a vault value back.
A router that keeps a short log
Local models run on your machine and never leave it; a hosted model you choose (the included Cloud Planner among them) processes what you send it, reached through one gateway. The broker opens requests, and the engine data it delivers, to route them, and it keeps every envelope it carries for a retention window (7 days by default), then deletes it by age. Requests and that engine data are encrypted at rest; streamed replies are stored in their end-to-end sealed form. Nothing is used for training, and nothing is mined.
- Crosses the wire, encrypted: requests, replies, and the data you view
- Weights, embeddings, stored provider keys, and your OpenEng key stay on-device
OpenEng AI · encryption
Sealed replies. Encryption on every hop.
The engine’s streamed replies are sealed end-to-end to your browser, and the broker relays that stream without being able to read it — provided it relays the engine and browser public keys honestly, because the broker is also what distributes them. Your prompts, and the engine data the Web Console loads, travel sealed to the broker, which opens and re-seals them to route them. On those legs the relay is a trusted component, not a blind one.
Authenticated encryption on every hop
Every hop is authenticated-encrypted, so tampering is detected rather than merely decoded, and eavesdroppers on the network see only ciphertext. The broker opens browser-to-engine requests, and the engine data it delivers to the Web Console, to route them. The engine’s streamed replies stay sealed end-to-end, which protects them from anyone who can read the broker’s store or traffic, as long as the broker hands out the engine’s and the browser’s public keys honestly — nothing verifies those keys out of band yet.
- Tampering is detected, not just decoded
- Streamed replies are sealed past the broker’s store and traffic
- Even loopback traffic is sealed, as if it crossed a network
One key agreement, every surface
The AI engine, the Broker, and the Web Console share one sealing construction — X25519, then HKDF-SHA256, then XChaCha20-Poly1305 — implemented identically in Rust, Go, and TypeScript. The five app engines and their browser apps use the same X25519 and HKDF key agreement, with ChaCha20-Poly1305 on every frame. One well-understood design protects every surface instead of several ad-hoc ones.
- One key-agreement design, every surface
- XChaCha20-Poly1305 for OpenEng AI · ChaCha20-Poly1305 for the apps
- Standard primitives, no bespoke crypto
OpenEng AI · the perimeter
No front door to pick.
The AI engine opens no network port. It dials out to reach your browser, so the classic browser-to-server attack surface simply isn’t there. What remains is authenticated and encrypted at every hop, in independent layers.
layer 1
No network port
The AI engine opens no network port: it dials out, so nothing on your network or on a web page can connect to it. Its model daemon uses a local Unix socket, and runtime servers and Ollama, if you use them, listen on 127.0.0.1.
layer 2
An explicit origin allow-list
The API and the Broker answer browser calls only for the origins on an explicit, exact-match allow-list, and the Broker ignores a
* wildcard in production. CORS governs browsers only; every call still has to authenticate.layer 3
Paired to your engine only
The broker only ever pairs your browser with your own engine, never anyone else’s. There is no way to be routed to a stranger’s machine, or for a stranger to reach yours. Besides your browsers, one other sender reaches your engine through the Broker: the OpenEng API, over the Broker’s authenticated ingress, which sends it control messages (for example, to forget a config you deleted). A few privileged control verbs, such as attaching a gateway guard, trust, and rewind, are accepted only from that API path, never from a browser.
layer 4
Checked continuously
Every browser write is authorized on its own. Engine links are re-validated on every heartbeat against the engine’s Broker session, which lasts up to 24 hours. Revoking the key or the plan stops the engine from registering again, so a running engine is cut off when that session ends. A browser’s subscription is authorized when it opens, with a grant that lasts about an hour.
OpenEng AI · egress & policy
One gateway for models. A floor no config can lower.
Every hosted or cloud model call leaves through one gateway, so model egress has a single place to be seen and governed. Every config runs above a security floor that no config can remove — and the defaults that operators can relax are named below.
One gateway for model calls
Every hosted or cloud model call, and every call to a local Ollama, goes through one model gateway — routed out through the sandbox wherever the host provides one (bubblewrap or a user systemd session) — so model egress has a single place to be seen and governed. The engine’s other traffic (the Broker link, key registration, config fetches, approval polling, model downloads, update checks, research fetches, cells, MCP servers, and connectors) uses its own connections.
The floor no config can remove
Envelope checks, authorization, and secret-egress blocking and redaction are compiled in beneath every config, and no config can remove them. By default, destructive actions and downloads need your approval (denied if nobody answers in time), and shell commands run in a kernel sandbox where the host supports one. Operators can relax those defaults with environment variables: OPENENG_FLOOR_MODE, OPENENG_SANDBOX, and OPENENG_MCP_AUTO_ALLOW.
Policy layers above it
Your gateway and guardrail policy, and a chain of gate / transform / observe / enrich plugins, compose on top of the floor. Each one can add a check; none can remove one. Policy publishes with the config, pinned to a version.
OpenEng AI · credentials & execution
Short-lived sessions. Approval on anything that bites.
The Web Console’s credentials are short-lived (about an hour), re-minted silently, and gone when you close the tab; the Console keeps you signed in until you sign out, and the engine’s OpenEng key is long-lived, so treat it like a password. Where bubblewrap works on the host, the shell commands the agent runs execute in a kernel sandbox, and destructive actions need your approval by default.
Short-lived sessions, a long-lived key
The Web Console’s credentials are short-lived (about an hour), re-minted silently while the tab is open, and gone when you close it; the Console keeps you signed in until you sign out. Signing in again on the same surface asks you to confirm a takeover, which cuts off the old session. A captured credential works until it expires and can open its own Broker session, so it could load your thread history and memory. It can’t decrypt what has already been sealed to your tab’s in-memory key. The engine’s OpenEng key is long-lived (one year by default): keep it in OPENENG_KEY rather than on the command line, issue one per machine, and revoke it in the Console if it leaks.
A kernel sandbox where the host has one
Where bubblewrap works on the host, the shell commands the agent runs execute inside it: a read-only root, writes only in the workspace, and the network off where the host can isolate it. On a host without it, they run unconfined — set OPENENG_SANDBOX=workspace-write to refuse them instead — and OPENENG_SANDBOX=off opts out. The model daemon runs in an enclosure: a systemd resource cap where a user systemd session works, and a read-only root where bubblewrap works. Extending hard OS-level isolation to every individual worker is the next hardening milestone.
- Read-only root where bubblewrap works
- Network off where the host can isolate it
Approval on destructive actions
By default, every tool call passes the compiled floor (authorization, secret-egress blocking and redaction), a heuristic injection screen flags what tools return, and destructive actions and downloads need an explicit human approval, surfaced right in the console, and are denied if nobody answers in time. A guardrail model stays loaded, and a config’s gateway policy can use it to screen model inputs for injection and outputs for groundedness. Operators can relax this: OPENENG_FLOOR_MODE=off or observe turns the approval floor off, and OPENENG_MCP_AUTO_ALLOW pre-approves the MCP tools it names.
Secrets & identity
Secrets stay by reference. Identity stays clean.
Configs hold references, not secret values, and the account system is built on boring, audited standards. There is no bespoke crypto. The engine’s OpenEng key is OpenEng AI’s long-lived API credential, which you can revoke in the Console. The Web Console’s sign-in ends when you close the tab, and the Console keeps you signed in until you sign out.
Secrets-by-reference control plane
You author config in the browser, but it stores only
${ENV} references. The values resolve at run time from the environment of the machine running the engine, and a breach of the configs yields names, not values. If you prefer, the Web Console can save a value to an optional per-config vault: it is encrypted at rest, can never be read back into a browser, and is released only to an engine that presents your API key. An environment variable on the engine machine always wins.- Configs hold references, never secret values
- Optional write-only vault · the environment wins
Identity hygiene
Sign-in uses standard Google browser authorization, and each surface allows one interactive session at a time. The AI engine itself authenticates only with an OpenEng key, an API key from the Console passed as --key=<K> or OPENENG_KEY, which is also how headless servers will run once the engine’s scheduler ships. API keys are shown once at creation, and only their hash is stored, so a dump leaks nothing usable.
- Standard browser sign-in
- One interactive session per surface
- API keys shown once · only a hash stored
What we never collect
No engine telemetry. No training on your data. No stored cards.
The simplest privacy guarantee is the one where the data never exists. None of the engines, neither the five app engines nor the AI engine, sends usage telemetry.
No engine telemetry
No engine carries an analytics SDK, a usage beacon, or a crash phone-home, and none sends usage data. They do contact OpenEng to do their job — for example, to sign in or register a key, fetch configs and approval requests, and check for updates — but none of that is usage telemetry. Your activity is yours.
No training on your data
Local models run on your machine, not in our cloud. App traffic never leaves it. For OpenEng AI, the broker keeps what it routes for its retention window (7 days by default), encrypted at rest: your requests and the engine data the Web Console loads, which it can open, and the engine’s streamed replies, which it cannot. Nothing is mined for training data.
Card data never stored
Card payments are processed by Razorpay, which holds your payment method. We keep only Razorpay’s subscription reference, never your card details.
The one thing we measure is this website: openeng.app uses Google Analytics for Firebase to count page visits. It runs only on this site: the apps, the Web Console, and the engines load no analytics. Read the Privacy Policy.
Our threat model, stated plainly
The one boundary we can't cross, and won't pretend we do.
The same-machine ceiling
Every OpenEng engine runs only on your own machine, and, where bubblewrap works on the host, the AI engine confines the shell commands its agent runs in a kernel sandbox. But the engines can't defend against other processes on the same machine. An app engine hands its handshake token to any local program that asks, including one running under another user account on a shared host, and that program can then drive the engine, which runs as you. The AI engine opens no port, but a process running as your OS user can read its key and its files. We'd rather state that plainly than imply a guarantee we can't make: run the engines only on a machine whose other users and programs you trust. For the Terminal, Kubernetes, and Data apps, everything above this line describes how they work today, and you can verify it; Git and Chat follow when their engines ship, and the OpenEng AI half describes how it is built to work until its API and Broker are deployed.
Questions
Security, answered.
The five engineering apps never send them to OpenEng: each app engine runs on your machine, binds only to loopback (127.0.0.1), and the web app reaches it over a session it seals per frame. What you point an app at yourself — your SSH hosts, clusters, forges, MCP servers, connectors, or an external model server for Chat — receives what you send it. For OpenEng AI, the models and the agent run on your machine, and the engine reads your files there; a hosted model you choose for a role receives what you send it. Your requests travel through the OpenEng Broker, encrypted in transit and at rest, and the broker opens them to route them to your engine. The engine’s streamed replies are sealed end-to-end, so the broker cannot read them. The engine data the Web Console loads — your thread list and history, learned memory, the running config, placeholder names, and loop, warm-up, and device status — is sealed to the broker, which opens it to deliver it. The broker keeps every envelope it routes for a retention window (7 days by default) and then deletes it by age.
Every leg is encrypted in transit. For OpenEng AI, the engine’s streamed replies are sealed end-to-end, so the broker cannot read them. The broker also distributes the engine’s and the browser’s public keys, so this protects replies from anyone who can read the broker’s store or traffic, provided the broker relays those keys honestly. The browser-to-engine requests, and the engine data the Web Console loads (such as thread history and memory), are opened by the broker so it can route and deliver them. The engineering apps do not use the broker at all — their channel runs from your browser to the engine on 127.0.0.1.
On your machine, unless you choose the optional vault. The app engines use your own credential helper and kubeconfig, and a credential you enter in an app, such as a database connection string, is stored locally by its engine; the one exception is the forge API token you give the Git app’s CI/CD view, which stays in that browser and goes only to your forge. For OpenEng AI, configs store ${ENV} references only, never secret values, and the values resolve from the environment of the machine running the engine. If you prefer, the Web Console can save a value to an optional per-config vault: it is encrypted at rest, never readable back into a browser, released only to an engine presenting your API key, and an environment variable on the engine machine always wins. Console API keys are shown once at creation; only a hash is stored, so a database dump reveals no usable key.
No. No OpenEng engine — the five app engines or the AI engine — contains an analytics SDK, a usage beacon, or a crash phone-home. The openeng.app website itself uses Google Analytics for Firebase to measure page visits (see the Privacy Policy). Card details for billing are never stored — payment is handled by Razorpay, and we keep only Razorpay’s subscription reference.
Other processes on the same machine. Every OpenEng engine runs only on your own machine, but the engines can’t defend against other local processes. An app engine hands its machine-local handshake token to any local program that asks, including one under another user account on a shared host, and that program can then drive the engine. The AI engine opens no port, but a process running as your OS user can read its key. Run the engines only on a machine whose other users and programs you trust; we state that boundary plainly.
You sign in to the app with Google, and it gives you a one-time start command. The key inside it is single-use and expires within minutes (the OpenEng API mints at most five unused keys an hour per account). Your engine exchanges that key once with the OpenEng API for its own session, then listens only on 127.0.0.1, where a machine-local handshake token gates every call from the page. Any process on this machine can obtain that token, including one under another user account on a shared host.
Trust you can read for yourself.
Run an app engine on your own machine, watch the wire, and verify the engineering apps’ claims on this page. Private by construction: no engine telemetry and no training on your data.
Install the Terminal engine · free