1. How work is isolated

Work is executed only inside a confinement, never as an unrestricted process on the host. There are two confinement backends and they are not equally strong, so the position is stated precisely rather than averaged:

• The container backend runs each job in a disposable container with the network disabled, dropped capabilities, a read-only root, no host mounts beyond the workspace, resource limits, and an unprivileged user (uid 65534).
• The fallback backend, used on hosts with no container runtime, runs a fixed, registered recipe under a Landlock and seccomp sandbox as the service's own user. It grants read and execute on the filesystem, write access only inside the per-job scratch directory, applies CPU, memory and file-size limits, and denies network syscalls. It is a weaker boundary than a container: it can run only the platform's own recipes, whose files and command are fixed in code, and it is not used for open-ended work.

The service reports the containment status of a run with its result, so a customer can see which confinement was applied rather than take it on trust.

2. Credentials and keys

• The service holds no key that can spend a customer's funds. The receiving address is receive-only: no private key is read, held, or logged, so the service cannot sign or spend.
• The operator's administration console is protected by a password stored only as a salted PBKDF2 hash, and sessions are signed.
• Secrets are supplied to the service through its environment, not committed to the repository.

3. Payment-to-job reconciliation

Every job is tied to its payment: the authorisation, the payer address, the amount, the nonce, and the settlement transaction are recorded against the job, so a payment can be traced to the work it paid for and the reverse.

4. Audit log and evidence

Consequential actions are written to an audit log: who acted, what they did, when, and the outcome. Verification output is retained with the deliverable so the acceptance decision can be re-checked.

5. What we do not claim

The service has not been certified to any security standard such as ISO 27001 or SOC 2, and it does not claim to be. It is not penetration-tested by a third party. The fallback confinement is a weaker boundary than a container and is not presented as equivalent. Claims on this site are limited to what the implementation does and what has actually been measured.

6. Incident response

If the operator becomes aware of a personal-data breach, it will assess it and, where it affects a customer's data, notify that customer without undue delay with the information needed to meet their own obligations. Where the operator is the controller, it will notify the ICO within 72 hours where the law requires it.

7. Human approval for irreversible actions

Payment settlement, changing a receiving address, and other actions that cannot be undone are not part of the automatic job path: they are operator actions that require the operator's explicit approval. The automatic path is kept to work that is reversible and independently verifiable.

8. Reporting a vulnerability

Report a suspected vulnerability to hello@swishrjobs.com. Please do not test against systems you do not own, and do not access other customers' data. The operator will acknowledge a report and say what it intends to do.