One Front Door: Where Your Credentials Live

One Front Door: Where Your Credentials Live

Everything outside this platform calls one named Endpoint. Behind it, w6w holds the connection: the vault, the OAuth dance and its refreshes, per-tenant credentials, and — where a caller would rather not store anything at all — the caller’s own token, forwarded for one request and never kept. That is one front door in practice: one access point, one credential, no matter how many vendors sit behind it.

Where does the credential actually go?

The credential and the network never meet — that isolation boundary has not yet been through an independent audit, and we’d rather you heard it from us than found it the hard way. Action code runs in its own worker with no network of its own, and the one hook that holds a credential runs in a separate worker with no network either: the code holding the token can’t speak, and the code that can speak has no token. There is no flag to turn that off. No endpoint hands the credential back to a tenant, though a host operator can reveal a stored credential through an operator-only administrative route — a deliberate escape hatch, not a leak.

This is what makes multi-tenant end-user credentials safe to hold at all: the boundary is structural and per-tenant, built on sandboxed execution rather than a policy someone has to remember to turn on.

What happens when a hook actually needs to make a request?

Its fetch is proxied through a per-app allowlist the host enforces — a request to a host outside that allowlist is rejected before it ever leaves the sandbox, the same way the Health Check spec’s own hooks are scoped. An app declares the hosts it needs once, in its manifest:

{
  "w6w": {
    "network": { "allow": ["api.sendgrid.com"] }
  }
}

Every outbound request and response through a declared Connection is captured host-side, so what a Connection actually did is a record rather than a promise. Credential-bearing headers, parameters and request fields are redacted by name; response bodies are not, so a value a vendor echoes back can still land in the record. That is deliberately not “everything is safe by default” — it is one specific, checkable boundary, stated plainly rather than implied.

Has this actually been audited?

No. We haven’t had a third-party audit yet. Say so before a security reviewer finds it first — that admission belongs next to the claim above, not three screens later where a skim would miss it.

What a security reviewer actually gets to check

The claim above is deliberately narrow. The credential never reaches your network, and that isn’t a promise — it’s a boundary enforced by where the token lives. It is not a claim about every declared feature working perfectly, and it is not a substitute for an audit — it is the one property a reviewer can verify directly, today, by reading where the credential and the network are kept apart, rather than trusting a paragraph of marketing copy.