Security and Access Controls

Public pages on this site are visible to all visitors without authentication. The HPOA Comparison Tool interface is visible, but the prompting bar is locked until a valid access credential is provided.

Password validation happens server-side using a timing-safe comparison. A successful unlock creates a server-side session record with a six-hour expiry. The session ID is an opaque UUID stored in the browser's session storage. The plaintext password is never stored in the browser and is not returned to the client.

All protected API routes validate the session against the server-side record before any processing occurs. The session must exist, must not have been revoked, and must not have expired.

Authentication attempts are rate limited by IP address. After a threshold of failed attempts within a short window, further attempts from that address are blocked temporarily.

Prompt submissions are rate limited per session. Once a session reaches its prompt limit within a given time window, further submissions are declined until the window resets. Excessive requests receive a plain error response without revealing internal thresholds.

These controls are intended to protect service reliability and prevent automated or abusive use of the underlying AI infrastructure.

Limited operational metadata is logged for security monitoring, debugging, and service integrity. Log records may include:

• Timestamp of the event
• Session identifier (an opaque token, not linked to your identity)
• IP address
• User agent (browser and operating system)
• Event type and success or failure status
• Prompt length in characters

Full prompt text is not retained in logs. Logging exists to support security, debugging, rate limiting, and service integrity. It is not used for advertising, profiling, or model training.

This platform is not designed for patient-specific or clinical use. Users are instructed not to enter personal health information. Questions should be general and legislative in nature.

Both the client interface and the server-side validation layer screen submissions for common personal health information patterns, including health card numbers, clinical note indicators, and date-of-birth formats.

PHI detection is a practical safeguard. It is not a substitute for user judgment. Responsibility for what is submitted rests with the user.

Protected routes run server-side. Access credentials and API keys are stored in environment variables and are not exposed to the client. System prompts are not accessible through public API responses.

Supabase Row Level Security is enforced on all relevant tables. The session store has no public access policies. The knowledge base is read-only for the application role and is not reachable through the public Supabase client.

Architecture documentation is maintained in version-controlled D2 source form. The system design is documented publicly on the System Design page.

All pages on this site are served with the following HTTP security headers:

• Content Security Policy: restricts which scripts, styles, and resources the browser may load
• X-Frame-Options: DENY: prevents this site from being embedded in a frame on another domain
• Referrer-Policy: limits referrer information sent with outbound requests
• Permissions-Policy: disables camera, microphone, and geolocation access
• X-Content-Type-Options: prevents MIME type sniffing

This is a demonstration platform. Security controls continue to evolve as the platform matures. No system should be treated as risk-free, and organizational deployments may require additional controls.

Organizations with specific privacy, data residency, logging, or access requirements can request a custom deployment. Custom implementations may include on-premise hosting, modified logging configurations, alternative authentication methods, and organizational-specific privacy controls.

For security questions, access concerns, or responsible disclosure, contact:

hello@sympathetictechnology.com