What protects your data, and what doesn't yet.

Open-weight models run through Ollama, which listens on the machine itself only (127.0.0.1), not the network.

The agent has no cloud provider configured. If the local model fails, the task fails; it does not quietly go to the cloud.

macOS firewall blocks inbound connections; the unit does not answer pings.

Password login is off. macOS records every SSH login in its system log. Sessions are agreed with your IT contact in advance.

The installer stops if FileVault is off; our demo unit runs with the demo override (DEMO_UNIT=1), so its disk is not encrypted. On a customer unit it is checked with fdesetup status and written in the install record.

Our aim is draft-only: sending and deleting turned off in the agent. Whether the mail platform can also block them at the permission level depends on the platform. Before install we tell your IT provider in writing which limits the platform enforces and which only the agent does.

What it can read is agreed in writing before install. In a quote pilot: forwarded quote requests and one price-list file.

Who applies macOS, Ollama, agent and model updates is agreed in writing at install. We re-run the test set before model updates. Your IT provider does not need to wait for us to apply a security patch.

On staffbox.ai, this Trust Center, the status page and the pilot room, plain HTTP is redirected to HTTPS at the CDN (Amazon CloudFront, policy TLSv1.2_2021). The lead-form endpoint is an AWS API Gateway default address, whose minimum TLS version we have not tested.

All public access is blocked on the S3 buckets; the CDN reaches them through origin access control.

Website files, lead-form records, pilot-room records and CDN visit logs are encrypted at rest (AES-256, S3 server-side). The Gmail copy of each lead is held by Google under its own terms.

CDN logs for staffbox.ai (IP address, page, referrer) expire automatically. Logs kept by the lead-form and pilot-room functions have no expiry set yet. Website analytics is separate: see Website analytics.

GitHub Actions deploys through a short-lived AWS role (OIDC) that only the main branch can use. No AWS keys sit in the repository.

HSTS (one year), no MIME sniffing, same-origin framing only and a strict referrer policy on staffbox.ai, trust., status. and the pilot room. Not yet on the lead-form endpoint; no Content-Security-Policy yet.

About every 5 minutes we check that the website, Trust Center, status page, lead-form gateway, pilot-room gate and email (MX) records respond. It does not test a form submission or mail delivery. Results: status.staffbox.ai.

DNS records limit which certificate authorities may issue certificates for staffbox.ai.

Each form entry is stored in our AWS account and a copy is emailed to the founder's inbox (Amazon SES to Gmail). Today both are deleted by hand; automatic expiry is planned.

Comments and e-signatures in the private pilot room are kept in a private, encrypted, versioned bucket in our AWS account.

As of 2 Oct 2026 the founder is the only person working on Staffbox. Automated credentials also exist: the deploy role, the status monitor, the lead-form and pilot-room functions, and the demo worker (which reads lead-form entries). People invited to a pilot room can see only that room.

Staffbox shares an AWS account with the founder's other projects, and that account has other administrator users who could technically read Staffbox data. Moving Staffbox to its own account is planned.

Some changes go through pull requests, but nothing yet enforces review or checks on the main branch. There is one developer, so no second reviewer.

Not enforced at the organization level yet. The website repository sits on the founder's personal GitHub account, outside the organization.

Published in testing mode: sending servers are asked to report TLS failures to us, but delivery is not blocked yet.

Signing keys are published; our mail is not yet sent through them.

SPF and DMARC records are published; DMARC is in monitoring mode, not yet set to reject. Enforcement follows outbound signing.

Access, incident response and vendor policies are not written yet.

Whether our SSH session reaches the unit directly on your network, through a VPN, or through a tunnel, and which ports the unit listens on.

Where agent updates come from, whether they are pulled or pushed, and how they are pinned or verified.

The mail platform supported and exactly what the worker may do: read, move, label, create drafts. Sending and deleting stay off.

The legal name and jurisdiction of the party you sign with.

Every host and port a default unit connects to, so your firewall can deny everything else.

How fast we tell your named contact about an incident touching a unit, our key, our update path or your data, and what we send.

Where our SSH key is held, how often it rotates, and what happens to access if Staffbox stops operating.

Who patches macOS, Ollama, the agent and models, and how fast for critical fixes.

Which logs the unit keeps (remote logins, agent actions, mailbox access), for how long, and how to send them to your log system.

What is backed up, to a target you own, and how fast a failed unit is replaced.

Inbound email is treated as untrusted. We will publish the test set and results for injection attempts against a default install.

Models, memory and working copies of the files and mail the worker reads are stored on the unit in your building. Our practice is to see them only if you send them to us during setup, or in a support session you have agreed.

Staffbox will not train or fine-tune a model on your data and will not give your data to anyone for model training. The providers listed under Subprocessors hold some data under their own terms. If you choose a cloud model, that provider's terms apply.

If you want a cloud model, you ask in writing and supply your own key. Then that provider is yours, under your contract with them.

The worker's notes and memory are plain Markdown files you can open, edit or delete. The agent also keeps working files (logs, skills, caches) on the unit; the install record lists where.

The unit is returned or wiped in front of you. Within 14 days of exit we delete what we hold from your pilot and confirm in writing what was deleted and what remains (for example older versions or logs that expire on their own schedule).