Where the data sits, and who can reach it.

Written for the person filling in a vendor-risk questionnaire. It describes the platform as it is built today — including a section listing what we do not have, because a security page that only lists strengths is not worth reading.

Last updated 2026-07-25

1. Two things, kept separate

There are two places your data can be, and the controls are different in each.

2. Where it runs

• Cloudflare Workers — the application. It runs at Cloudflare's edge; there is no origin server, no virtual machine and no container of ours to patch or leave exposed.
• Cloudflare D1 — the database. Created in the WNAM region: western North America, United States. This is where every durable record lives.
• Cloudflare DNS and TLS — the site answers at exactly one address; the *.workers.dev alias is disabled so there is no second, unbranded way in.
• Microsoft 365 — the info@vosky.ai mailbox that transactional email is sent from.

All traffic is served over HTTPS. Certificates and TLS termination are Cloudflare's.

3. What is stored

4. Authentication

Sign-in is passkey-first. Passkeys are WebAuthn credentials bound to the vosky.ai domain: there is no password to phish, reuse or leak, and a credential from a lookalike domain will not verify. We support ES256 and RS256, which between them covers every authenticator in circulation.

• Challenges are server-issued, single-use and short-lived — five minutes, and deleted the moment they are redeemed, so an assertion cannot be replayed.
• Several passkeys per person is the intent, not an edge case. Enrol a laptop and a phone and losing one costs nothing.
• We hold only public keys. Nothing in our database can sign on a user's behalf.
• Recovery codes are issued once, stored hashed, single-use, and a session opened with one lasts a single day — long enough to enrol a new passkey and no longer.
• Emailed sign-in links exist for corporate desktops that block WebAuthn. Fifteen minutes, single use, and redeemed by a POST from the page rather than by following the link — so a mail-security scanner that fetches every URL in a message cannot burn the link before the recipient clicks it.

The WebAuthn verification is implemented directly against the platform's Web Crypto API. The application has no runtime third-party dependencies — nothing from a package registry executes in the request path, which removes an entire class of supply-chain exposure.

5. Sessions and revocation

A session is a row in the database, not a self-contained token. The cookie carries only a session identifier and an HMAC signature; the row is what actually grants access. That design is the reason revoking one device is a single update that ends that device's access without touching anyone else.

• The cookie is HttpOnly, Secure and SameSite=Lax.
• Sessions expire after 30 days for staff and 14 for client accounts; a recovery-code session lasts one day.
• Every user can see every device signed in as them — with its browser, IP, sign-in method and last-seen time — and revoke any of them, or all of them, from their account page.
• Expired, revoked and disabled accounts all resolve the same way: no session. The check cannot be forgotten by a caller because it happens in one place.

6. Authorisation

• Three roles. Admin, staff, and client. Administrative screens and the people directory are admin-only; the audit workspace and deliverable tooling are staff and admin.
• Organisation scoping. A client account belongs to an organisation, and every query for audit data is filtered by that organisation in the database query itself — not by hiding rows in the interface. A client account with no organisation set sees nothing, which is the safe reading of a half-configured account.
• Out of scope reads as not found. Requesting a record belonging to another organisation returns 404, not 403, so the response cannot be used to enumerate which records exist.
• Clients read, they do not write. Writes and deletions on audit records are refused for client accounts at the API.

7. Access logging

Every read, write, deletion and failed lookup on a client-data path writes a row recording who, what action, which record, from which IP, and when. Consult-form submissions are logged too. The log exists so the scoping above can be demonstrated to behave rather than asserted — if you want to see the trail for your own organisation's records during an engagement, ask and we will produce it.

Log writes are deliberately fire-and-forget: the log is evidence, not a dependency, so a logging failure can never break the request that produced it.

8. AI handling

• The assistant on the home page sends your messages to Anthropic's API over TLS, and returns the reply.
• Audit drafting sends your audit intake to Anthropic's API. When one of our consultants asks the workspace to draft findings, the notes captured during your assessment — the institution profile, the discovery notes, the systems and compliance answers — are transmitted to Anthropic to produce a first draft. This is initiated by a person, never automatically, and is available only to Vosky staff. The draft is a proposal: it is reviewed, edited and approved by a human before it becomes part of any deliverable, and nothing is written to your record without that approval.
• Those two are the only paths out. No lead record, no account data, no credential and no access-log entry is transmitted to a model provider.
• Transcripts and drafts are not retained by us — only spend counters, which is how the cost caps work.
• The API key never reaches the browser. Both model calls are made server-side; the system prompts are server-side too.
• Input is bounded — capped conversation turns, capped message length, capped reply length, and a separate monthly ceiling on drafting.
• Anthropic's commercial terms state that API inputs and outputs are not used to train their models.

If audit content reaching a model provider is not acceptable under your vendor policy, say so at engagement and we will run the assessment without the drafting step. It is a convenience for our consultant, not a dependency of the product.

9. Abuse and cost controls

• A hidden honeypot field on the consult form; submissions that fill it are discarded and answered with a success so an automated client learns nothing.
• No more than five consult submissions from one IP address per day.
• Three independent spend caps on the public AI endpoint — per visitor per day, site-wide per day, site-wide per month — priced from the real token usage each reply reports, not an estimate.
• The budget check fails closed: if the ledger cannot be read, the endpoint declines rather than risk an uncapped bill.
• Upstream error bodies are never returned to the browser, so an API failure cannot echo request detail back to a caller.

Cloudflare's edge sits in front of everything, providing DDoS mitigation and bot protection at the network layer. Application-level limits are enforced in the code as well: the consult form is capped per IP per day, and the assistant is capped per visitor per day and site-wide per day and per month, in dollars.

10. Secrets and deployment

• Credentials — the model API key, the session signing key, the Microsoft Graph client secret — are stored as encrypted platform secrets, never in the repository and never sent to the browser.
• Outbound mail uses an application-only Microsoft Graph registration whose Mail.Send permission is narrowed by an Application Access Policy to the single info@vosky.ai mailbox — it cannot send as anyone else in the tenant.
• Deployment is from a version-controlled repository through Cloudflare's tooling. Changes are reviewed by the person deploying them.

11. Encryption, plainly

In transit: HTTPS/TLS everywhere, including the calls out to Anthropic and Microsoft Graph.

At rest: data in Cloudflare D1 is protected by the encryption Cloudflare provides for that platform. We do not add application-layer encryption on top of it, and we make no guarantee about encryption at rest beyond what Cloudflare provides. Recovery codes are the exception — those are hashed by us, so that table is worthless if it ever leaked.

12. Backups

The database can be exported in full on demand, and Cloudflare provides point-in-time recovery for D1.

13. What we do not have

We would rather you learn this here than three weeks into a review. As of the date at the top of this page, Vosky AI does not hold:

• A SOC 2 report. Type I or Type II. We have not been audited.
• ISO 27001 certification.
• A third-party penetration test of this platform.
• A formal bug bounty programme. Report anything you find to info@vosky.ai and we will act on it.
• PCI DSS scope. We do not take card payments through this platform and no cardholder data touches it.

What we do have is a small, deliberately simple system, a short list of subprocessors, no runtime dependencies, and a complete log of who read what. If your due-diligence process requires an attestation we do not hold, tell us early — that is a fair reason to say no, and we would rather hear it in week one than in week six.

14. Incident response

If we identify a security incident affecting your data, we will contain it, notify your named contact without undue delay, tell you what we know and what we do not yet know, and follow up with a root-cause account and what changed as a result.

15. Subprocessors

The same list as the privacy notice, repeated here because this is the page a risk team will pull.

Per-engagement subprocessors differ and are documented for each client before work starts.

16. Export and deletion

Email info@vosky.ai to request an export or deletion of your data. We respond within 30 days. Details, including the two honest limits on deletion, are in the privacy notice.

17. Questionnaires

We complete vendor due-diligence questionnaires in full, at no extra cost, and we take part in your third-party risk-management process. Send the form to info@vosky.ai or call (214) 702-9523.