Security, privacy, and tenant isolation
A public, product-level view of the controls that protect account and portfolio boundaries, together with the release evidence used to keep those controls from silently regressing.
Current control state
The public summaries below intentionally omit sensitive policy text, identifiers, internal topology, and privileged implementation details. CI retains the detailed hashed evidence separately for diligence and authorized enterprise review.
Portfolio-scoped data access is enforced through tenant-aware database authorization and row-level policy boundaries.
Evidence: Release validation exercises canonical tenant helpers, scoped resource families, row-level policies, and cross-account denial behavior.
Server and agent-facing access paths preserve the authenticated user's account and portfolio authorization context.
Evidence: Release validation checks scoped server surfaces, hardened mutation paths, and tenant-boundary behavior for machine-facing access.
Property documents and storage references remain attached to authorized portfolio context rather than a global browser-visible namespace.
Evidence: Release validation covers portfolio document boundaries, storage policy contracts, and least-privilege access expectations.
Derived and generated tenant state is qualified against the same portfolio isolation model as primary records.
Evidence: Deterministic multi-tenant qualification probes derived-state resource families across representative portfolio scales.
Reporting and generated-file surfaces are expected to preserve account and portfolio scope through read and export workflows.
Evidence: Release qualification includes generated-file and reporting-adjacent tenant families together with the complete regression suite.
Platform, account, and support administration use explicit authority boundaries; account roles do not imply fleet-wide access.
Evidence: Administration regression coverage checks canonical account authorization, same-account role management, diagnostic-only support access, and audited privileged actions.
Encryption, secrets, and privileged access
Hosting-provider controls, Property Pulse application controls, and customer responsibilities are labeled separately so provider assurances are not presented as Property Pulse certifications.
Production public URLs are canonicalized to HTTPS. TLS termination and certificate lifecycle are managed by the hosting and network provider boundary rather than application code.
Evidence boundary: Release configuration verifies an HTTPS-only canonical production origin; provider TLS evidence remains provider-scoped diligence material.
Database and managed storage encryption at rest are hosting-provider controls. Property Pulse does not present provider-managed encryption as a Property Pulse certification.
Evidence boundary: The diligence boundary requires current provider evidence for at-rest encryption; the application release gate verifies that no custom browser-side encryption key or privileged database credential is introduced.
Browser and SSR application clients are configured with the Supabase publishable-key boundary and must not ship service-role or privileged database credentials in public source or assets.
Evidence boundary: Automated release configuration scans client/public source for privileged environment-variable patterns and verifies the generated Supabase client consumes the publishable key only.
Privileged database and service access is explicit, server-side, least-privilege, and separated from ordinary account or portfolio membership.
Evidence boundary: Release evidence checks explicit function grants/revocations, the platform-admin allowlist, least-privilege service-identity profiles, and audited privileged operations.
Account owners and administrators remain responsible for member access, role assignments, MFA/SSO policy choices, and promptly disabling access that is no longer required.
Evidence boundary: Property Pulse provides account-scoped role, member, security-policy, service-identity, and audit controls; customer administrators choose and review their configured posture.
Secure development and vulnerability management
Production changes are delivered through pull requests and blocked on consolidated CI. Security-sensitive paths are explicitly identified in the review checklist; current owner-operated repository governance does not claim independent reviewer separation unless a distinct reviewer is recorded.
Dependency updates are monitored with automated update proposals and release CI performs a high/critical dependency vulnerability audit before merge.
Release CI scans tracked browser/public source and environment configuration for privileged credential patterns. The dedicated server-only service-role boundary is validated separately rather than treated as client exposure.
Property Pulse does not currently publish a completed independent penetration-test claim. The readiness target is before enterprise assurance claims and on a recurring cadence after material authentication or tenancy changes.
Not yet independently verified| Severity | Triage target | Remediation target |
|---|---|---|
| critical | within 24 hours | mitigate within 72 hours when technically feasible |
| high | within 2 business days | remediate within 14 calendar days |
| medium | within 5 business days | remediate within 30 calendar days |
| low | within 10 business days | remediate within 90 calendar days or an approved release window |
These are internal response targets, not an external service-level guarantee.
Data lifecycle and resilience
Recovery evidence requires an isolated restore or equivalent provider-supported recovery rehearsal, deterministic tenant-isolation qualification and recorded cutover/rollback results. A documentation-only review is not treated as a successful restore exercise.
Customer application data is retained while the account is active unless a documented lifecycle process applies. Security events currently have no automated purge. Property Pulse does not claim a shorter automated deletion window that is not implemented.
Exports are tenant/property scoped and must preserve existing authorization boundaries. Platform account export is an audited request workflow rather than an unrestricted browser-side bulk dump.
Account deletion is an audited reviewed request workflow. This release does not claim immediate one-click destructive deletion or silently erase customer evidence.
Database/storage backup capability is provider-managed and depends on the current backend plan/configuration. Property Pulse must verify current provider backup coverage before publishing a numeric backup guarantee.
No external numeric RTO/RPO SLA is claimed in this release. The recovery objective is a safe isolated restore, tenant-isolation requalification, and controlled cutover with rollback evidence before speed is represented as guaranteed.
Providers and shared responsibility
Current technical providers are shown below. Region and formal subprocessor claims remain subject to current provider and contractual evidence rather than being inferred from source code.
Managed PostgreSQL, authentication and storage backend
The application does not independently assert a hosting region; verify the current project/provider record before external diligence.
Current project build, publish and managed backend integration tooling
No application-level regional claim is made here; verify current provider documentation and contract for diligence.
Source control and release CI/evidence artifacts
No application-level regional claim is made here; provider terms govern source-control/CI processing.
Responsible disclosure
Report suspected vulnerabilities through the security-report instructions in the Trust Center. Do not include credentials, production customer data, or exploit payloads beyond what is necessary to reproduce the issue safely.
Good-faith research should minimize access, avoid privacy impact or service disruption, stop after proving the issue, and allow reasonable time for remediation before disclosure.
The canonical machine-readable disclosure record is /.well-known/security.txt. Researchers with an existing Property Pulse relationship should use their secure support channel for the initial report. Researchers without an account can use the AreaAlpha corporate contact surface to request the security team; do not send sensitive customer data in the initial contact.
Release evidence
Every proposed release runs the complete regression suite plus deterministic multi-tenant qualification before merge.
CI generates timestamped SHA-256 release evidence and a customer security posture package on every release-candidate run. The public-safe package is published at /security-posture.json; detailed evidence remains gated for authorized diligence.
A failed tenant-isolation/security validation or an expired customer-evidence review window blocks the release. Stale evidence must be reviewed and regenerated before it can be represented as current.
A public-safe machine-readable summary is published at /security-evidence.json.
These are Property Pulse product-control statements and release evidence, not a claim of third-party certification or independent audit.