# Product Plan (PRD): Secure Variables (v1) **Status:** Draft **Mantra:** *Store it once. Secure it everywhere. Use it without seeing it.* or *Lock it up, no one gets a key.* ## 1. The Problem Users across our platform need to repeatedly use sensitive information (API keys, passwords, customer PII) to get their work done. Currently, they have two bad options: 1. **Re-type it:** They manually copy-paste secrets from a password manager or text file every time. This is inefficient and kills workflow. 2. **Store it insecurely:** They paste the secret directly into a "notes" field or a `Variable` (our _current_ un-protected feature). This is a massive compliance and security risk for them and for us. We are forcing our users to choose between being efficient and being secure. ## 2. Personas & Core Needs This feature serves three distinct personas with competing needs. - **Persona 1: The Non-Technical User (e.g., Marketer, Support Agent)** - **Need:** "I want to store my team's shared social media password in a central place so I can reference it, but I don't want an intern to be able to see it." - **Use Case:** UI-driven. - **Persona 2: The Technical User (e.g., Developer, Data Analyst)** - **Need:** "I need to store a production API key to use in a platform script. The system needs to _use_ the key, but _no human_—not even me—should ever be able to _read_ it from the UI again." - **Use Case:** API/Script-driven. - **Persona 3: The Admin / Security Officer (e.g., Team Lead, CISO)** - **Need:** "I need to know that our PII (like SSNs) and secrets (like database passwords) are compliant with HIPAA/SOC2. I need to control _who_ can use a secret, not just who can see it." - **Use Case:** Compliance/Access-driven. ## 3. The Solution (v1): A Two-Tier System The user's questions (masked? verifiable? limited scope?) can't be solved with one "type" of variable. A feature that is verifiable (un-maskable) is, by definition, not secure. Therefore, our solution is to bifurcate the existing "Variables" feature into two distinct classes. |Feature|**Type 1: `Variable` (Existing)**|**Type 2: `Secret` (New v1 Feature)**| |---|---|---| |**What it's for**|Non-sensitive, repeated data.|Sensitive, "write-only" data.| |**Examples**|`project-name`, `team-email`, `company-logo-url`|`api-key`, `db-password`, `customer-ssn`| |**Masked?**|No. Plaintext.|**Yes.** Always masked as `********` after saving.| |**Verifiable?**|Yes. You can read/edit the value.|**No.** Value is write-only. Cannot be revealed.| |**Scope?**|**Global.** Can be used anywhere (notes, text, etc.).|**Limited.** Can _only_ be used in secure system contexts.| ## 4. Key Product Decisions (Answering the Questions) This is the core of the spec. By creating a new `Secret` class, we can make the following firm decisions for v1. #### **Decision 1: Is the value masked everywhere?** - **Yes.** A `Secret`'s value is **write-only**. - The user enters the value once. After they hit "Save," the UI will _only_ display the variable's name (e.g., `prod-api-key`) and a masked value (e.g., `********`). - This protects against "shoulder surfing" and unauthorized UI reads. #### **Decision 2: Can the value be verified? (The "Write-Only" problem)** - **No.** A true secret _cannot_ be revealed or verified by the creator. - **Why?** If a "verify" button exists, any admin or user with access could click it, exposing the secret and breaking the chain of custody. This also makes us non-compliant, as we would be "storing" readable PII. - **The Workflow:** If a user loses a secret's value, the only path is to **delete** the `Secret` (e.g., `prod-api-key-v1`) and **create a new one** (e.g., `prod-api-key-v2`). This is the industry-standard security practice. #### **Decision 3: Do we limit its scope? (The "Usage" problem)** - **Absolutely. This is the most critical part.** - A `Variable` (un-protected) can be referenced in any text field. If you type `{{project-name}}` in a note, it renders "Vibe Reader." - A `Secret` (protected) _cannot_ be used this way. If a user types `{{prod-api-key}}` in a note, it will render as `[SECURE SECRET]` or `********`. - **So how is it used?** A `Secret` can _only_ be referenced in platform areas that are explicitly designed to handle them (e.g., an "API Key" field in an integration, or a "Secure Environment" tab in a script editor). The system uses the value on the backend but _never_ exposes it to the frontend UI. ## 5. Out of Scope (v2 / Future) - **Per-Secret Access Control:** For v1, a `Secret` is owned by its creator and is usable by the team. Granular, user-by-user RBAC is v2. - **Audit Logs:** A full log of "who used what secret and when" is a v2 compliance feature. - **Secret Rotation:** Automated reminders or API-driven rotation of keys is v2+. ## 6. Success Metrics (v1 KPIs) - **Adoption:** % of new variables created that are `Secret` (shows users understand and want the feature). - **Secure Usage:** # of `Secrets` successfully referenced in a secure context (e.g., API test run, integration). - **Risk Reduction:** (Lagging Indicator) Reduction in insecurely stored secrets (e.g., values that look like `sk_live_...`) found in our existing, unprotected `Variable` tables.