Security
Security enforced below the UI
SiteOps Command holds multiple tenants’ designs, revenue records, and portal data. Isolation is enforced in database security rules, evidence is append-only, and this page follows one rule: present tense means shipped, and roadmap means roadmap.
How to read this page
Three commitments before any feature list
A security page is a claims exercise. These are the rules ours follows.
Shipped is present tense
Every control described in present tense on this page is running in production today. Anything we have not shipped sits in the clearly labeled roadmap section — nowhere else.
No unearned badges
We hold no security certifications today and we display no compliance badges. When an auditor issues one, it will appear here — not before.
Isolation lives below the UI
Tenant boundaries are enforced in database security rules and server-issued claims — not in client-side filters an attacker could skip by calling the database directly.
Tenant isolation
Org-scoped at the rules layer, fail closed
Every tenant’s data carries its organization id, and every business read and write is checked against the caller’s server-issued org claim inside Firestore security rules — the layer beneath the application. Client code adds the same scoping, and refuses to query at all when no tenant id is present.
- Identity claims are written by one server-side function; no client path can mutate them
- Per-document visibility is enforced in the rules, not by client-side filters — a bypassed UI still hits a closed door
- A dedicated emulator test suite asserts cross-tenant denial against the real rules engine with real auth contexts
- The customer portal is a second, separate boundary: its users carry a portal tenant id only, checked by both the rules and an app-layer guard
The boundary
- Claim
- org id issued server-side only
- Rules
- every read and write predicates on it
- Queries
- fail closed without a tenant id
- Portal
- separate claim, two-layer check
Access control
Roles narrow; they never quietly widen
Access resolves through three layers that can only narrow: the organization’s package ceiling, then role defaults inside that ceiling, then per-user overrides that can remove but not add. Deactivating a user blocks their writes at the rules layer, not just in the interface.
- Role and tenant claims sync from a single server-side trigger — the only writer
- Tenant administrators cannot modify their own platform flags or package assignments; the rules reject it
- Author fields are pinned to the authenticated user on create — records cannot be written in someone else’s name
- Destructive deletes are blocked on core business records; deletion is a soft-delete with an audit trail
Resolution order
- Ceiling
- org packages set the outer bound
- Role
- defaults narrow within it
- User
- overrides remove, never add
- Inactive
- writes blocked at the rules layer
Auditability
Evidence that cannot be edited after the fact
The audit log is append-only by rule — update and delete are denied to every caller. Configuration changes record before-and-after diffs through a typed audit facade, and requests carry a correlation id from the browser to the server so an investigation can follow one action end to end.
- Audit records: create-only; the rules deny update and delete outright
- Sensitive movements are ledgers, not mutable state — portal device history is an append-only event stream, and corrections are new events
- Signature and agreement trails are preserved as immutable records with document hashes
The trail
- Audit log
- append-only, by rule
- Changes
- before / after diffs recorded
- Correlation
- request id, browser to server
- Ledgers
- events appended, never rewritten
Data protection
Encrypted in transit and at rest, classified on paper you can read
Traffic is TLS in transit. At rest, data is encrypted with AES-256 under Google-managed keys (FIPS 140-2 validated) on multi-region replicated infrastructure. Every persisted PII field is mapped to a documented retention tier, and data-subject endpoints — export, deletion, portability — are live today.
- A documented PII classification assigns every stored personal field a retention tier
- Export, deletion, and portability endpoints are shipped, plus field-level contact redaction with its own audit category
- Honest fine print: signed contracts and signature artifacts are preserved under legal-hold exemptions during erasure — and we tell the requester exactly that
The controls
- Transit
- TLS
- At rest
- AES-256, Google-managed keys
- Classification
- four documented retention tiers
- Erasure
- export / delete / portability live
The intelligence layer
What SOC sees, keeps, and is never allowed to do
SOC works from your own operational data under a documented retention policy. Standard usage logging is metadata-first — model, tokens, latency, cost, request id — with prompt and response bodies excluded from standard logs by policy. A redaction and prompt-injection screening pipeline sits in front of provider calls, and every tenant runs under its own rate and credit limits.
- Metadata-first logging with a documented four-tier retention policy
- PII redaction and injection screening before requests leave the platform
- Per-tenant rate limits and credit caps — one tenant cannot spend another’s budget
- The trust invariant: SOC never invents the numbers — the deterministic physics and cost engines own every figure
The posture
- Logging
- metadata-first: model, tokens, cost
- Bodies
- excluded from standard logs by policy
- Screening
- redaction + injection checks
- Limits
- per-tenant rate and credit caps
Direction
Roadmap, labeled as roadmap
The controls below are documented commitments we have not shipped. They appear in this section and nowhere else on this page.
Roadmap
SOC 2 certification
The platform is designed around SOC 2 CC controls — access, isolation, audit evidence, change management — and certification is on our roadmap. Until an auditor signs, we say “designed around,” not “certified.”
Roadmap
Per-org key encryption
A drafted upgrade (ADR-019b) adds per-tenant envelope encryption for sensitive PII under dedicated per-org keys, with cryptographic shred on org deletion. It is a documented commitment — proposed, not shipped — so it lives here, not above.
Roadmap
Automated retention sweeps
Retention tiers are documented and enforced today on specific collections; a fully automated sweep across every tier is roadmap work. We publish the schedule as it lands rather than claiming it early.
Responsible disclosure
Found something? Tell us first.
Our disclosure contact is published at the standard location. We respond to every credible report.
The posture, measured honestly
Structural facts about where the controls live — no invented certifications, no borrowed badges.
- Rules layer
- where tenant isolation is enforced
- server-issued org claims — not client-side filters
- Two-layer
- customer-portal isolation
- rules predicate plus app-layer guard, fail closed
- Append-only
- audit logs and device ledgers
- update and delete denied by rule
- No badges
- displayed before they are earned
- SOC 2-aligned controls; certification on the roadmap
Security questions
Are you SOC 2 certified?
No. The platform is designed around SOC 2 CC controls — server-issued access claims, rules-layer tenant isolation, append-only audit evidence, documented retention — and certification is on our roadmap. We will not display a badge before an auditor issues it.
How is our data isolated from other tenants?
Every record carries an organization id, and Firestore security rules check it against the caller’s server-issued claim on every business read and write. Client queries fail closed without a tenant id, claims can only be written by one server-side function, and an emulator test suite asserts that a user from one org is denied another org’s documents. Portal users are a separate boundary with their own claim, checked by the rules and an app-layer guard.
What does the intelligence layer keep from our data?
Standard usage logs are metadata — model, token counts, latency, cost, request id — under a documented four-tier retention policy; prompt and response bodies are excluded from standard logs by policy. Redaction and prompt-injection screening run before provider calls, and every tenant has its own rate and credit limits.
Can we export or delete our data?
Yes — export, deletion, and portability endpoints are live, plus field-level contact redaction with its own audit category. One honest exception: signed contracts, signatures, and their certificates are preserved under legal-hold exemptions (such as GDPR Art. 17(3)(e)) — and an erasure request is told exactly what was preserved and why.
How do we report a security issue?
Through the contact published in our security.txt file at /.well-known/security.txt — the standard responsible-disclosure location. Tell us first; we take reports seriously and respond to every credible one.
Bring your security questionnaire
We will walk your team through isolation, access, audit evidence, and retention with real answers — including an honest “not yet” wherever that is the truth.