Where your data goes,
and where it doesn't.
Weev is a control plane. It decides whether a job runs and records that it ran. It does not execute your code and does not store what your code touches. This page is written to be read by a reviewer, out of context, without a call.
01 · The trust boundary
Two execution models, one control plane
The difference between them is who opens the connection. Read this part carefully — it is the only structural decision on this page.
The service-embedded model needs a route Weev can reach — the same shape as any webhook. The agent model needs none. It polls outbound over 443 and receives work in the response, so there is no listening surface to review, firewall or exempt.
02 · The push handshake
Six steps, each one authenticated
This is the path a single run takes today, end to end. Nothing here is a shared secret in a header and hoped for the best.
Endpoint registered
The configured URL is checked by the SSRF guard when it is written. A route that resolves to link-local, loopback or internal address space is rejected at configuration time, not at 2am.
Re-checked at dispatch
The guard runs again on every dispatch, so a hostname that changes where it points after registration does not become an egress path.
Offer sent
Weev authenticates the offer to your endpoint with an outbound key, prefixed wvout_. Redirects are never followed — a 302 ends the attempt rather than forwarding your credential somewhere new.
Attempt claimed
Your SDK validates the offer, then claims the attempt with a single-use execution token. That token authorizes exactly one attempt context and nothing else in your organization.
Fenced lease held
The claim takes a fenced lease. A second claimant, a retry that overlaps, or a callback that arrives late cannot execute or commit the same attempt twice. This is the guarantee that a held job stays held.
Completion reported
Your SDK reports the outcome back with an inbound key, prefixed wvin_, and the run record closes.
The agent model replaces steps 01 through 03 with an outbound poll and leaves 04 through 06 unchanged. The claim, the lease and the completion path are the same code.
03 · What crosses the boundary
The complete list, both models
Leaves your network
Job identity — name, batch, declared dependencies
Run lifecycle events — queued, held, started, succeeded, failed, with timestamps
Graph revision and deployment version
Exit codes and durations
Run results — whatever your handler returns, as JSON up to 256 KiB
Agent heartbeat — version, host label, last seen (agent model)
Never leaves your network
Your source code
Job arguments, payloads and their contents
Database rows, files and transferred bytes
The credentials your job uses — database passwords, connection strings, third-party API keys
Log output — your process writes it, your host keeps it
If a field is not in the left column, it is not sent. Job names, dependency names and run results are the fields you author, and that is where discipline matters: do not encode a customer identifier in a job name, and have handlers return references — counts, IDs, status — rather than the rows they processed.
Weev issues its own key pair for the channel in both directions; how that material is stored is in section 05.
04 · The agent connection
What a firewall review has to approve
inbound ports opened, on any host
outbound only, TLS, to a single Weev hostname
registration token, scoped to one project, revocable instantly
VPNs, tunnels or IP allowlists to maintain
Works behind NAT, behind an egress proxy, and in networks with no inbound path at all. The agent runs as an unprivileged process; it needs only the permissions the jobs it runs already need.
The rules it cannot break
- The agent never executes a command string received from the cloud. Only job identity and an attempt token cross the wire inbound; commands resolve from the agent's local, hash-pinned copy of the deployed manifest.
- Every observation is written to a hash-chained store on disk before transmission — tamper-evident from the point of capture, durable through cloud outages.
- Credentials never leave the box, and command text is redacted before egress.
- The console shows exactly which rights the agent holds on each host — nothing is granted invisibly, and nothing updates itself.
05 · Credentials, logs and updates
What Weev holds, and what it cannot
Two kinds of key
Weev stores the key material for its own channel and nothing else. Machine tokens and inbound keys are bcrypt-hashed and cannot be recovered by anyone, including us. Outbound keys are AES-encrypted rather than hashed, because the worker has to present them to your endpoint — that is a deliberate trade, not an oversight. Hashed credentials are shown once, at creation. Outbound keys can be re-revealed later, but only by an organization admin, and every reveal is logged.
Logs stay home
Weev receives the outcome of a run — status, timing, and the result your handler returns — never your log stream. Log lines are written by your process, on your host, and stay there.
Updates are yours to run
Weev cannot push a new agent version to your host. The agent announces its version on every poll and the console flags a stale one, but installing it is an operator action through your own package or image pipeline. Pin a version and it stays pinned.
Key material never reaches a log line. Machine tokens, execution tokens, encryption keys, API keys and the contents of .env and .weevrc are excluded from application logging by rule, on both sides of the boundary. Rotating the encryption key is a versioned re-encryption plan, not a config change.
06 · Auditability
Don't take the diagram's word for it
The agent is the component running on your infrastructure, so it is the component you should be able to read.
Built to be read
UpcomingThe agent is designed to ship as open source under Apache-2.0 — public repository, no telemetry, reproducible signed builds. The sync loop, the request signing and the payload construction all readable, and the protocol deliberately small enough to audit in an afternoon. Open source is how the rules above become verifiable rather than asserted.
What we don't claim yet
Weev is in private beta and has no third-party audit — no SOC 2 report, no ISO certification, no penetration test to hand you. We would rather you read that here than discover it in week three of a procurement cycle. If a certification is a hard gate for you, tell us which one and we will tell you honestly where it sits.
Send this page
to your reviewer.
If something here is a blocker, it is worth ten minutes with the engineers who built it rather than a questionnaire.