Security
This page describes how the platform is built, because the architecture is the part of a security posture we can state as fact rather than as an intention. The website you are reading is a set of static files with no accounts and no login; what it collects while you read it is set out on the privacy page instead.
Everything below is a property of the design. Where a property has not been checked by anyone outside this project, the last section says so in as many words.
Credentials stay on the host
Everything outside calls a named Endpoint. Behind that Endpoint the platform holds the connections: the vault, the OAuth dance and its refreshes, and per-tenant credentials. A caller reaches the Endpoint and gets an answer; the caller never holds the vendor credential behind it, never rotates it, and never sees it.
There is a second shape for the case where you would rather we stored nothing at all. In it, the caller’s own token is forwarded for that one request and never kept.
App code runs in a sandbox
Every hook runs in a Deno worker with deny-by-default permissions and no ambient network. Outbound traffic is not something app code arranges for itself: it is proxied by the host against a per-app allowlist, per invocation. So action code has no network of its own, and the fetch it thinks it is making is proxied through that allowlist, which the host enforces rather than the app.
An app is ordinary code, and it is treated as though it might be hostile: the permissions it is granted are the ones it was given explicitly, and the hosts it can reach are the ones its allowlist names for that invocation.
The credential and the network never meet
The one hook that is handed a credential runs in its own worker, and that worker also has no network. That is the entire property, and it is worth spelling out in both directions: the code holding the token cannot speak, and the code that can speak has no token.
Two things follow, and both are deliberate rather than incidental. There is no flag that turns this off, for anyone, in any deployment. And no endpoint hands the token back to a tenant: the API you call returns a connection as a summary — which app it is for, who owns it, whether it last tested clean — with the credential left out of the response.
There is one exception, and we would rather name it here than leave you to find it. A host operator — somebody holding operator rights on the deployment itself, which is neither a tenant nor an app — can read a stored credential back through an administrative route that exists for exactly that purpose. That is a deliberate capability for running the service, not an oversight, and it is why the boundary above is drawn between the credential and the code that can reach the network rather than as an absolute. If you run the platform in your own infrastructure, its operators are your own people.
What is recorded
Every outbound request and response is captured host-side, and credential-bearing fields are redacted before the record is stored. That is what turns an integration’s behaviour into a record rather than a promise: you can see what a given call actually sent and what came back.
The redaction recognises known credential names — an authorization header, an api-key parameter, a password field in a request body. A response body is truncated at a size cap, but never redacted. So a credential a vendor echoes back to you, or one carried under an unrecognised name, can still land in the record.
What we do not claim
The isolation property itself has not yet been through an independent audit. We would rather you heard that from us than found it.
To be exact about the rest: we publish no third-party security attestation, and this page is not one. We do not operate a paid vulnerability-reward programme. What is written above describes design properties that are implemented and can be exercised; it is not an assurance opinion about them, and it should be read as engineering documentation rather than as a guarantee.
Reporting a problem
If you believe you have found a security problem — in the platform, in one of the published apps, or in this website — please write to the contact address at the foot of this page rather than opening a public issue. A useful report says what you did, what you expected to happen, what happened instead, and how somebody else can see the same thing.
Please do not run destructive checks against anything of ours, do not access data that is not yours, and give us a reasonable chance to fix the problem before you describe it publicly. We would far rather hear about something early and awkwardly than late and elegantly.
The scope of this page
This page is about the platform’s architecture. It is not a description of any one deployment: if you run the platform inside your own infrastructure, then the network around it, the storage under it and the operational controls beside it are yours, and nothing here speaks for them.
It will be reviewed, corrected wherever it turns out to be wrong, and replaced; the note directly below says on what footing it stands until then.
- Published by
- w6w, Inc, a Delaware corporation
- Contact
- legal@w6w.io
- Last updated
This page is a baseline pending counsel review. It describes how things actually work today and is written to be reviewed and replaced; it is not legal advice, and it is not a substitute for advice about your own situation.