In one paragraph
Each client has its own database, authentication and file storage in Sydney, Australia. Every request to the WorkArc API is tied to the client whose identity provider signed it, so a token from one client cannot read another client's data. Fergus and Harper credentials are issued by the client, held in an encrypted vault inside the client's own database, and never stored in the browser, in logs or in source control. All traffic is encrypted in transit and all data at rest. Every call WorkArc makes to Fergus is logged and reviewed by automated alerts. An internal security review was completed in October 2026; the fixes are deployed. This page is the public version of what we tell platform partners.
Where data lives
Database, sign-in and file storage: Supabase, region ap-southeast-2 (Sydney), with managed backups in the same region. Application servers: a virtual private server at Hostinger that processes requests and holds working state; its weekly image backups are stored by Hostinger. AI processing happens transiently at Anthropic (United States) for the features listed below. Messaging to a client's customers goes through HighLevel (United States), which the client contracts directly. The full list is at /subprocessors.
One database per client
Each client is a separate Supabase project: its own PostgreSQL database, its own user pool, its own private storage bucket. Row Level Security is enabled on every table. The API binds each request to the project that issued the caller's token and refuses any other. There is no shared table across clients.
Sign-in and access
Client staff sign in with email and password, checked against known-breached passwords, with multi-factor authentication required for owner and administrator roles. Sessions use short-lived signed tokens that the API verifies on every request (signature, issuer, audience, expiry). Roles (owner, operations, sales) are stored server-side and enforced in the API; users cannot change their own role. New users start with no company access until an administrator assigns them. Deactivated staff lose access within a minute.
Integrations and agents use OAuth 2.1 or personal access tokens that are stored as hashes, read-only, rate limited and audited per call.
Fergus and Harper credentials
The client issues WorkArc an API token from its own Fergus account and can revoke it there at any time. WorkArc stores the token in Supabase Vault inside that client's project (authenticated encryption, keys held by Supabase and not readable from SQL), reads it once when the API starts, and holds it only in server memory. It is never written to the browser, to logs, to analytics or to source control, and the repositories are scanned for secrets before each commit. A revoked token is detected by the alerting below within 15 minutes and WorkArc's copy is removed within 24 hours. Harper (HighLevel) keys are handled the same way.
Encryption
In transit: TLS only (TLS 1.2 and above, 1.3 in practice), certificates issued and renewed automatically, HTTP redirected to HTTPS, HSTS enabled. At rest: Supabase encrypts databases, storage and backups with AES-256 using provider-managed keys. Credentials in Vault carry a second layer of authenticated encryption.
AI processing
ArcOS uses the Anthropic API for the features below. Each runs only when a staff member triggers it, sends only the text that task needs over an encrypted connection, and receives a draft or an answer back. Anthropic does not train on API data and retains it only as its commercial terms require. The AI tools inside the assistant are read-only: nothing is sent, changed or created by a model; a person does that. Customer messages and records are treated as data, never as instructions. The client consents to this processing in the Standard Terms (clause 9.7) and may ask for any feature to be switched off for its account.
| Feature | Runs when | What is sent |
|---|---|---|
| Quote builder | Staff type a brief | The brief and the generated line items |
| Quote check | Staff audit a quote | The quote text and sections from Fergus |
| Follow-up drafting | Staff ask for a draft | Customer name, address, job number, total, scope summary, pipeline stage, and the message history with that customer |
| Job pack | Staff generate a crew brief | Proposal text, site and access notes, client commitments |
| Client update draft | Ops draft a portal update | Client first name, project manager name, phase names, progress notes |
| Job briefing and assistant | Staff ask a question | The question and the job, quote, time and note records the answer needs. Phone numbers, email addresses and street addresses are excluded from customer lookups |
Not sent to any model: Fergus or Harper credentials, passwords, invoice or bank details, and the phone numbers, email addresses and street addresses of a client's customers when looked up by the assistant.
Logging and alerting
Every call WorkArc makes to the Fergus API is recorded: time, client, method, path, response status, duration and the signed-in user or scheduled job that caused it. No request or response bodies and no tokens. Refused sign-ins, cross-client attempts and bad webhook signatures are recorded the same way. A check runs every 15 minutes and alerts WorkArc on a revoked Fergus token, an error spike, unusual volume or repeated refusals. Job activity and every AI tool call are also logged. Logs are kept for 12 months and can be produced for a client or a platform partner for any window on request.
Incidents
WorkArc keeps a written incident response plan. A confirmed incident affecting a client's data is notified to that client within 24 hours and to any affected platform partner within 72 hours, with the Office of the Privacy Commissioner notified where the Privacy Act 2020 requires. Credentials are rotated first, the cause is found second, and a short written post-incident note is shared with the client.
Retention and deletion
Fergus remains the system of record; ArcOS keeps the working copies of quotes, jobs and customers that follow-up and reporting need, refreshed from Fergus. Assistant logs are kept 180 days, usage analytics 90 days, audit logs 12 months. When a client leaves, WorkArc revokes every integration, disables sign-in, provides an export on request and deletes the client's project and server-side data within 30 days, confirmed in writing. Individuals exercise their rights under the Privacy Act with the client, and WorkArc acts on the client's instruction within 10 working days.
Who has access at WorkArc
Two people: the founder and the infrastructure lead. Each has an individual account with multi-factor authentication on every provider; servers accept SSH keys only. Raw credentials are readable only through the server, by those two roles, and any emergency access by one is logged and told to the other. Access is reviewed quarterly. No contractor or agent is given production access.
Reporting a vulnerability
If you find a security problem in ArcOS or workarc.io, email ops@workarc.io (or josh@workarc.io). We reply within two working days, fix confirmed issues as a priority, and will credit you if you wish. Please do not access data that is not yours while testing.