Security and Privacy Standard¶
This standard states baseline security and privacy rules that apply company-wide, across every venture, regardless of the product's technology or format.
No secrets in documentation or code¶
Do not commit API keys, passwords, tokens, private keys, or other secrets into this repository, in any file, at any stage — including examples, drafts, and test fixtures. If a secret is needed for an example, use an obviously fake placeholder (e.g., sk-example-not-real) and say so explicitly.
Classify data before handling it¶
Any document, feature, or process that touches data about people or the business should classify that data per docs/governance/information-classification.md before deciding how it may be stored, shared, or referenced in documentation. Do not assume data is low-sensitivity by default.
Minimize personal data in examples¶
Documentation examples, sample data, and specifications should use fictional or clearly synthetic personal data (names, emails, addresses) rather than real customer or user data, even for illustrative purposes. Where real aggregate or anonymized data is genuinely useful for evidence (e.g., in a research citation), it should be handled per external-research-standard.md and the information classification policy.
Human review for privacy-sensitive features¶
Any product feature that collects, stores, or processes personal data (account creation, any user-entered data that could identify a person, any analytics or tracking) requires human review before release — this is not a decision an AI agent working in this repository can make or approve unilaterally. See docs/company/responsible-ai-principles.md.
Distinguish "protection" from real security controls¶
Be precise about what a given mechanism actually provides, and do not describe weak protections as if they were strong security controls:
- Digital Products example: Excel "sheet protection" or "workbook protection" (password-locking cells or structure) is a protection against accidental edits, not a security control — it is trivially bypassed by anyone with basic tooling and provides no confidentiality guarantee. Documentation and product claims must not describe it as securing data.
- Shelfery example: client-side input validation is a usability measure, not a security control — actual enforcement of rules (e.g., authorization checks on what data a user can access) must happen server-side or in an equivalently trustworthy location, and should be described as such.
Where a product claims to be "secure" or "private" in customer-facing material, that claim must be backed by an actual control appropriate to the claim, consistent with docs/standards/commercial-claims-standard.md.
Relationship to venture-specific security practices¶
A venture may define more specific security practices (e.g., a specific authentication approach, a specific data-retention period) under its own venture-level standards, provided they meet or exceed this baseline.