Crawft is high-detail monitoring software for organization-managed Macs. The privacy story should be direct: organizations use Crawft when they need a reviewable activity record, and the people being monitored deserve to understand what is collected, who can see it, how long it is kept, and what Crawft does not collect.
This Privacy Policy covers the Crawft marketing site and Crawft deployments for organizations. For deployed customers, the organization is the controller of the data and Crawft acts as the processor on that organization's instruction.
1. Who we are
Crawft is built and operated by Cruce Saunders, an individual. It is not a company. There is no incorporated entity behind Crawft — no “Crawft Inc.,” no LLC, no registered business — and nothing on this site should be read as implying one. Crawft is not being offered commercially today; it is pre-pilot, with no customer and no revenue. If that changes, this section will be updated before it does.
This matters for a privacy policy specifically. When you read “Crawft” below, it means one person and the systems he runs — not a staffed organization with a privacy department. Privacy questions go to cruce.saunders@alpha.school and are answered by him.
A Data Processing Addendum template exists and is offered to customers, but no customer agreement or DPA is currently in force with anyone. Crawft is pre-pilot. Any future deployment will be governed by a signed agreement, and this policy will say so once one exists rather than describing terms that do not yet bind anybody.
2. What we collect
The exact configuration is set by the customer before rollout, but Crawft can collect the following from an enrolled Mac:
- The focused app, active window, device state, timestamps, and health or offline signals.
- Typed text in many normal text fields, including drafts that may not be sent or saved, except protected fields such as passwords.
- Periodic screenshots during active use when screenshots are enabled. These are still images, not video, and may include connected external displays.
- Derived records such as segments, activity timelines, alerts, summaries, exports, operator notes, and audit logs.
- Enrollment and administration records, including device identifiers, per-device enrollment status, organization membership, administrator accounts, access logs, and support history.
On the marketing site, we collect information you intentionally submit through the request-access form: name, work email, organization, role, and optional notes about your use case.
3. How we collect it
Crawft starts with the organization, not with an individual installing monitoring on their own. A Crawft operator prepares enrollment, the organization's administrator distributes the Mac agent or enrollment instructions through an approved channel, and the enrolled device begins collecting the activity types enabled by the organization's policy.
The Mac agent captures activity on-device, temporarily stores pending data in a local cache until it is uploaded, and uploads the data over encrypted connections to Crawft infrastructure on AWS. That local cache is not encrypted. It is a plain SQLite database plus a folder of JPEG screenshots under /Library/Application Support/Vantage, protected by macOS file permissions rather than by cryptography; on-device encryption is designed and not built. The screenshot spool in particular is created group-readable, so a local account on that Mac can read pending screenshots before they upload, and so can anyone who can read the disk. An earlier version of this policy described that cache as encrypted, which was not true. Whole-disk encryption on the Mac — FileVault, which your MDM can enforce — is what actually protects this data at rest on the device, and it is worth confirming it is on before you deploy. Organizations can use manual installation or managed-device deployment. Some configurations require macOS permissions such as Screen Recording, Accessibility, Input Monitoring, or Full Disk Access. Crawft ships no network or system extension and does not inspect network traffic.
4. Who has access
Within a customer organization, access is limited to the administrators the customer designates for a need-to-know role. That might include an operations lead, technology director, compliance lead, HR lead, or another approved administrator. It does not automatically include every team member, IT staff person, or unrelated third party.
On the Crawft side there is no staff: one person, the operator named in section 1, is the only human with administrative reach. He may access customer content only for a support case, investigation, or operational need the customer has authorized in writing, and that access is logged. Crawft does not sell customer data, use it for advertising, or allow unrelated third parties to browse customer records.
5. Where data is stored
Crawft stores deployment data in AWS in the United States, in us-east-1. That is the only region Crawft runs in — there is no second region, on request or otherwise. Data is encrypted in transit between the Mac agent and Crawft services, and encrypted at rest in Crawft databases, object storage, queues, and backups. One qualifier, stated here as it is on the security page: the hop between our own application and its database is protected by network isolation rather than TLS. Operational logs are designed for system health and support; they should not contain captured content, user names, screenshots, or other sensitive data.
6. Who else processes it
Crawft turns raw capture into a readable day record using a large language model. That step sends captured on-screen text and typed text to Anthropic, through the Claude API. It is the one place captured content leaves Crawft-controlled infrastructure, and it belongs in a privacy policy rather than only in a contract.
| Sub-processor | What it handles | Location |
|---|---|---|
| Anthropic | Captured on-screen text and typed text, sent to the Claude API to produce the written day record | United States |
| Amazon Web Services | Hosting, database, object storage, queueing, backups | United States (us-east-1) |
| Vercel | Hosting this marketing site — no captured data | Provider-controlled |
| Resend | Sending the request-access form and service email — no captured data | Provider-controlled |
| Plausible | Anonymous marketing-site analytics — no captured data | Provider-controlled |
No sub-processor is authorized to use captured data for its own advertising, resale, or model training.
7. How long we keep it
Screenshots are kept for at least 90 days. Activity records are retained indefinitely. Neither is deleted because it got old. 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 the customer can set — that field is read-only and the API rejects a write to it. Keeping this data is a deliberate product decision.
Two areas of object storage are the exception, and this page states them rather than claiming a blanket “nothing is ever removed.” 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 removed 365 days later. Both are engineering byproducts — the replay log a window can be reprocessed from, and the export bundles an administrator generates — rather than the record you read in the console, which is unaffected. An earlier version of this page described the 365-day object-storage figure and a later one called that description wrong; the figure was correct, and this paragraph restores it with the scope it always needed.
After about 90 days a screenshot moves to cold archival storage; it is archived, not erased, and it remains retrievable until someone deletes it deliberately. If you are being monitored, the honest statement is that a screenshot taken today may still exist in a year, and so may every activity record from today. Deletion is available on request through the organization that controls the account, and is a real action someone takes — not something that happens on its own.
Customers may request export, preservation, or deletion under their agreement and applicable law. Deletion covers Crawft-held records and backups under Crawft control, subject to the backup lifecycle in the customer agreement. It does not automatically delete copies a customer exported and stored outside Crawft.
8. What we do not collect
Crawft has hard product boundaries. Crawft does not collect:
- Camera video or images.
- 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 day-metrics contract is a closed schema that rejects a score-shaped field outright, so a score cannot reach storage even if the model tried to emit one.
- Hidden content inside encrypted apps unless the content is visible on screen or the app exposes it as normal text.
One important limit: if sensitive content is visible on the monitored screen, a screenshot-based system may capture what is visible. That can include private messages, health information, family context, or other non-work content if it appears on an enrolled Mac. Crawft reduces that risk with customer-controlled exclusions, password-field handling, and access controls. It does not reduce it with short retention: no timer removes a screenshot or an activity record — see section 7.
9. Your rights and customer responsibilities
The customer organization remains responsible for lawful notice, consent where required, end-user disclosure, acceptable-use policy, access decisions, and how records are used. Crawft processes data only on the customer's instruction under the contract and DPA.
End users and other data subjects may request access, export, correction, or deletion through the customer organization that controls the account. Crawft supports those requests on the customer's instruction, including exporting records, deleting records, correcting or annotating misleading processed records, and preserving records when legally required.
10. Cookies and analytics on this site
The Crawft marketing site uses Plausible Analytics to understand basic page traffic. Plausible is privacy-focused and anonymous: no Google Analytics, no behavioral ad pixels, no session replay, no cross-site tracking, and no third-party advertising trackers.
11. Contact
For privacy questions, customer DPA requests, or data-rights routing, email cruce.saunders@alpha.school. We expect to move privacy requests to privacy@vantage-tracking.com later.
12. Changes to this policy
We will update this policy when our product, subprocessors, retention practices, or legal commitments materially change. For deployed customers, Crawft will provide notice at least 30 days before material changes take effect, unless a shorter timeline is required for security, legal, or operational reasons.