Access Control Policy

1. Principle

Every person and every system gets the least access needed to do its job, access is tied to an individual identity (never shared), and access that is no longer needed is removed. Where the service can enforce a rule in code, it does, rather than relying on habit.

2. Customer accounts

• Identity is provided by Google Firebase Authentication. Customers sign in with email and password or with a Google account. Firebase, not PsiGuard, stores and verifies passwords.
• Instant trial accounts are anonymous Firebase identities created for a no-signup trial. They are rate-limited per network address and hold the smallest usage allowance; claiming the account with an email upgrades it in place.
• Sessions are Firebase session cookies with a 14-day lifetime, marked HTTP-only and Secure. Every request to a signed-in page or endpoint re-verifies the cookie, including a check that the session has not been revoked. Signing out invalidates the session server-side.
• Each account sees only its own data. Activity, keys, configuration and history are always looked up by the signed-in account's identity on the server; there is no way to request another account's records.

3. API keys

• A key is shown once, at creation. PsiGuard stores only a one-way SHA-256 fingerprint and a short display prefix. The key itself is never written anywhere.
• Keys belong to the account that created them and can be revoked instantly by that account. A revoked key is rejected on its next request.
• Each key records when it was last used, so unused keys can be identified and retired.
• Keys are sent in the request header over HTTPS only. Documentation never shows a real key.

4. Customer-supplied provider keys

When a customer connects their own AI-provider key, it is encrypted at rest (Fernet symmetric encryption) with a key that exists only in the production server's environment, never in the code repository. It is decrypted in memory solely to make model requests on that customer's behalf and is never returned to the browser, logged, or shown in any interface.

5. Administrative access

• Admin capability inside the product is granted by an explicit allow-list of account identifiers held in the server environment. There is no "admin" role a user can request or set on themselves.
• Admin-only pages and endpoints answer 404 Not Found to everyone else, including signed-in customers, so their existence is not discoverable. Conventional administrative paths (such as /admin) are deliberately unrouted.
• Admin views are designed as counts and status only. They do not expose other accounts' prompts, answers or keys.
• Today the allow-list contains the Founder's accounts only.

6. Infrastructure and provider accounts

Production depends on accounts at Render, GitHub, Google (Firebase / Cloud), Stripe, Cloudflare, Resend, and the AI model providers. For each of these:

• Exactly two people hold sign-in access: the Founder, who operates them, and the co-founder, who holds access as a partner in the company and does not use it day to day. Each has their own credentials; no shared logins.
• Multi-factor authentication is required on every one of these logins, for both partners, wherever the provider offers it.
• Access for any additional person is granted as a separate, named identity with the minimum role, and is removed the day it is no longer needed.
• The set of people with access, and whether each login still needs the role it has, is reviewed at each policy review.

7. Secrets

• Secrets (API credentials, the encryption key, Firebase service credentials, Stripe keys) live in the hosting provider's environment variables and secret files. They are never in the code repository. Local secret files are excluded from version control.
• A secret that is suspected to have been exposed is rotated immediately and the exposure is handled under SEC-04.

8. Network controls

All traffic is HTTPS with HSTS. Every response carries a Content-Security-Policy, clickjacking protection, and related browser hardening headers. All dynamic routes are rate-limited, with tighter limits on the API, generation and contact endpoints; sign-in attempts are throttled by Firebase Authentication. Cloudflare sits in front of the application for DNS, TLS and network-level protection.