Owner: the founder. Approved: 2026-10-08. Review: annually. Applies to: anyone with access to Ataski systems, customer data or the company's accounts — today, one person.
This is the internal policy. What customers may and may not do with the
product is in the Terms of Service (/legal/terms); what the AI workers may do
on their behalf is in the AI Disclosure Statement (/legal/ai-disclosure).
The laptop that holds the SSH key and .env.local is production infrastructure,
whatever it feels like.
.env.local points at the production Neon database. Treat every local
script as a production script, because it is. This is the reason the
test-tenant guard exists.Look at a customer's data only when there is a reason, and make the reason
visible. In the product that is a support session: a structured reason, a hard
time box, read-only by construction, recorded under the platform_support actor
type so it lands in the customer's own audit export, and the customer is
told. Outside the product — a direct database query, a log grep — the same
standard applies without the machinery, so it must be written into the work
record.
Never: use customer data to train anything, share it with a third party outside the disclosed sub-processors, or copy it into a personal tool, note-taking app or chat that is not part of the stack.
Secrets go in .env.local (development) or the server .env (production, mode
0600), and nowhere else. Never in a commit, a comment, an issue, a
screenshot, a chat message, or a prompt to a model. The gitleaks scans in the commit hook and the pre-push gate are the
safety net, not the plan — and they only run on a clone where
scripts/install_git_hooks.sh has been run. Never --no-verify past a secret
finding: a real hit means the credential is rotated, not the hook skipped.
If a credential is exposed even for a moment, rotate it and open an incident. Rotation is cheap; hoping is not.
Do not sign the company up for a new service that will touch customer data without an ADR and founder approval — that is the vendor-management policy, and it applies to a free tier as much as to a paid one. Convenience tools that never see customer data are unrestricted.
Coding assistants may read this repository. They must not be handed customer
data, production database rows, or the contents of any .env. When an assistant
needs a real-world artefact to reproduce a bug, use the customer's document with
the customer's knowledge and delete it afterwards, or synthesise one.
Never claim a certification, attestation or audit result the company does not
hold. The approved wording while preparation is under way is «SOC 2 Type 1 audit
in preparation» — never "SOC 2 compliant", never "certified", never a badge.
Describe methods, never credentials. Where a control is a roadmap item, the
public copy says so; the sentence "Ataski does not currently hold a SOC 2
attestation and claims none" already sits on /trust and stays there
until it stops being true.
Anything that smells like a security problem — a stray credential, an odd audit-log entry, a customer asking why they can see something — goes straight into the incident-response plan's triage step. Same day. There is nobody to escalate to, which makes not deferring it the whole control.