Data ownership and processing
Your organization is the data controller under the Data Processing Addendum that governs every deployment. Crawft is the processor.
Being precise about who that is, because it is the first thing your counsel will ask: Crawft is not a company. It is built and operated by Cruce Saunders as an individual. There is no incorporated entity behind it — no “Crawft Inc.,” no LLC, no registered business — so the processor obligations in the DPA are his, personally. No customer agreement or DPA is in force with anyone today; Crawft is pre-pilot. See the privacy policy for the full statement.
We act only on documented instructions from your organization. We do not sell, rent, lease, or share customer data with any third party for advertising, analytics, or model training.
Where data lives
Production data lives in AWS us-east-1. That is the only region Crawft runs in — there is no second region available, on request or otherwise. If a data-residency requirement rules out US hosting, say so early and we will tell you honestly that we cannot meet it today.
Application data is isolated per tenant two ways: every read query carries an org_id predicate scoped to the caller's organization, and every captured object is written under an org-prefixed storage key. To name the mechanism precisely, because a reviewer will check it: this is application-level scoping, not Postgres row-level security. No RLS policy exists on any table.
Device authentication
Each enrolled Mac authenticates with a per-device bearer token issued at enrollment and sent over TLS. The token is scoped to that one device, is stored server-side only as a hash, expires after 90 days, and is renewed on the device. The agent never holds long-lived cloud credentials. Revocation is immediate from the operator console.
Crawft does not use mutual TLS. The load balancer does not request a client certificate, and no per-device certificate is issued. If your review requires mTLS, treat it as a gap rather than a feature.
Retention
Screenshots are kept for at least 90 days. Activity records are retained indefinitely. After about 90 days a screenshot moves to cold archival storage — archived, not erased — and it stays retrievable.
No timer removes a screenshot or an activity record. The screenshot store carries no expiry rule at all, no age-based purge runs against any record table, no per-data-class retention tier governs the records you read, and there is no retention window for your organization to set. That is a deliberate product decision, not an unfinished feature, and this page used to describe a tiered schedule that was never built.
Two object stores are the exception — the two this deployment writes to — and we would rather name them than let “nothing is ever removed” stand as a blanket claim your counsel could later disprove. The raw upload replay log and the processed-and-export object area each carry a live 365-day expiry rule in AWS, so an object written into either one is gone a year later. The replay log is an internal artifact — a processing window we can re-run. The processed area is not purely internal: it is where an export bundle you ask for is written, so an export is removed a year after it is generated. Neither is the record you read in the console, which is unaffected by both.
Deletion is real, but it is an action a person takes rather than a schedule that runs, and it is narrower than a full erasure. On your written instruction we run org-wide deletion of captured data from the operator console: it removes your devices and the data captured through them — observations, events, screenshots, sessions and rollups. Per-device wipe works the same way. Both are audit-logged.
What that wipe does not remove, stated plainly because a buyer's counsel will ask: your organisation record and the directory attached to it (people, groups, locations, console logins), the interpreted day narratives — which carry snapshotted excerpts of what was on screen — export jobs, and the audit trail. Removing those is a manual step we perform, not a button, and we will tell you in writing what was and was not removed. If a contractual erasure guarantee matters to you, raise it before you sign: it is a real product gap, not a configuration flag.
Access logging
Every read of a monitored person's record is logged before it is served — by whoever performed it, from which IP, against which device, and for what span. The write is fail-closed: if the audit row cannot be written, the read returns an error instead of data.
The tamper-evidence is narrower than the logging, and the difference matters to your reviewer. There are two audit tables. Crawft-side access — ours, the vendor's — is hash-chained: each entry commits the hash of the one before it, database triggers reject any UPDATE or DELETE, and a verifier walks the chain and reports the first break. Actions taken by your own administrators in the customer console — including viewing an employee's screenshots — are logged to a separate table that is not hash-chained and carries no immutability trigger. Those entries are complete and fail-closed, but they are not tamper-evident in the cryptographic sense. Read “hash-chained” as covering vendor access only until this page says otherwise.
What Crawft does not capture
Enforced in code, not only in policy:
- No camera or webcam feeds
- No password-field typing
- No productivity score, rating, grade, tier, or percentage. Crawft describes what happened. It does not score, rank, or grade a person's work. The model that writes the day record is instructed never to emit one, and — because an instruction is not enforcement — the interpreted day-metrics contract is a closed schema that rejects a score-shaped field outright, so a score cannot reach storage even if a model tried to emit it.
- No data leaves your tenant uninstructed
- No model training on your data
One honest footnote to that list, because the heading above claims code enforcement and only claims it where it exists: “no model training on your data” rests on Anthropic's commercial API terms, not on a switch inside Crawft. There is no zero-retention flag set in our code, and an earlier version of this page implied there was. Treat it as a vendor commitment your counsel should read at the source, in the same way you would read any sub-processor term.
Sub-processors
The nightly interpretation step sends captured on-screen text and typed text to Anthropic's Claude API, which is what turns raw capture into the written day record. That is the one place captured content leaves Crawft-controlled infrastructure, and it is named here rather than left to be discovered inside a contract.
| Sub-processor | Service | What it handles | Location |
|---|---|---|---|
| Anthropic | Claude API (LLM) | Captured on-screen text and typed text, turned into the written day record | United States |
| Amazon Web Services | RDS, S3, SQS, EC2 | Hosting, database, object storage, queueing, backups | United States (us-east-1) |
| Vercel | Web hosting | This marketing site only — no captured data | Provider-controlled |
| Resend | Transactional email | Request-access form and service email — no captured data | Provider-controlled |
| Plausible | Analytics | Anonymous marketing-site analytics — no captured data | Provider-controlled |
The same list appears in the DPA and is updated with 30 days' notice for material changes.
Compliance posture
Crawft holds no SOC 2 report, and no SOC 2 audit or readiness engagement is under way. No auditor is engaged, no compliance-automation platform is in use, and there is no incorporated entity for a report to be issued to. Until August 2026 this page said the opposite — it described Type I control design as active and gave a readiness date. Nothing behind either statement had begun. The correction is stated here rather than made silently, because a certification timeline is the one claim on this page a security reviewer will actually go and check.
There has also been no third-party penetration test, and Crawft holds no other certification or attestation — no ISO 27001, no HIPAA BAA, no FedRAMP, no sector-specific certificate of any kind. If your policy requires one before a vendor can touch employee data, we do not meet it today, and you should know that now rather than in week three of an evaluation.
What we offer in place of an audit report: a written security questionnaire answered control-by-control against the source code, the sub-processor list published above, the DPA, and a live screen share in which any control described on this page can be demonstrated rather than asserted.
Disclosure and acceptable use
Crawft is deployed openly. The agent has no menu-bar UI by default — not to hide, but to avoid interrupting work. Disclosure to end-users is the organization's responsibility, executed through your acceptable-use policy or workplace handbook.
We do not supply a template acceptable-use policy or handbook clause. This page and the privacy policy describe precisely what is captured, which is the input your counsel needs to write one — but the drafting is yours. This page and the FAQ both used to offer such a template. None was ever written, and you would have found that out at rollout.
Vulnerability reporting
Security researchers can report vulnerabilities to cruce.saunders@alpha.school with subject line beginning with [SEC]. We acknowledge within two business days.
DPA & sub-processor list
The Crawft Data Processing Addendum template is available for review by your counsel during pilot evaluation. It carries the same sub-processor list published above.