Security starts with restraint.

1. Product security doctrine

• Read-only by default. No production writes without explicit customer approval.
• Least privilege. Customer access should be scoped to the minimum needed for the agreed work.
• Source systems remain the truth. Graphs, rankings, and receipts are derived from source data.
• Every risk has an evidence path. A finding should be explainable from the identities, roles, policies, and trust relationships that created it.
• Every fix is simulated first. No blind remediation. No irreversible automation without approval.
• Customer control remains intact. The customer decides what to connect, what to share, what to remediate, and when access ends.

2. Public website controls

The public website is hosted through Cloudflare Pages and routed through the Pathros custom domain. Production traffic should terminate through Cloudflare edge controls, not an exposed default build URL.

• HTTPS enforced at the edge.
• HSTS, referrer policy, permissions policy, and content-type protections configured through response headers.
• Content Security Policy added or tightened after embedded services are verified.
• Default Cloudflare Pages subdomain redirected to pathros.cc.
• Staging and preview environments blocked from indexing and protected where possible.

3. Form and bot protection

Public forms should use Cloudflare Turnstile with server-side token validation. A client-side check alone is not enough. Expired, replayed, or invalid tokens must fail closed.

• Turnstile token required for public form submissions.
• Server-side validation required before routing lead, audit, or contact requests.
• Rate limiting and abuse monitoring applied to public endpoints.
• Forms should never ask visitors to submit secrets, API keys, private keys, passwords, or access tokens.

4. Customer access model

For a read-only audit or design-partner engagement, the customer should create scoped access that gives Pathros only the permissions needed to read the agreed identity and cloud metadata.

• Okta or Entra access should be limited to agreed identity metadata.
• AWS access should use scoped IAM roles with read-only permissions where possible.
• GitHub access should be limited to agreed organization, repository, workflow, and OIDC metadata.
• Snowflake or data-system access should be limited to metadata needed to model access paths, not raw customer records unless separately agreed.
• The customer may revoke access at any time according to the written agreement.

5. Data handling

Pathros classifies customer data by sensitivity and limits who can access it. Customer environment data is handled separately from public website analytics and contact-form data.

• Customer source data is used to produce access graphs, evidence paths, rankings, simulations, and provenance receipts.
• Derived artifacts are treated as customer-sensitive because they may reveal internal access structure.
• Secrets should not be collected through public forms or stored in source control.
• Production credentials belong in managed secret storage, not in code, tickets, chats, or documentation.
• Customer pilot data is retained, returned, or deleted according to the customer agreement.

6. Infrastructure and deployment controls

• Production builds run through a controlled Cloudflare Pages deployment pipeline.
• Staging and production branches are separated.
• Rollback paths are documented before launch.
• Security headers and route redirects are validated before release.
• Accessibility, reduced-motion, route, link, content, and claim checks run as release gates.
• Environment variables and secrets are separated. Secrets must not be committed.

7. Application controls

• Role-based access is used for internal administrative systems where available.
• Multi-factor authentication is required for critical administrative accounts.
• Audit logs are preserved for security-relevant administrative actions where available.
• Dependencies are reviewed before launch and monitored during development.
• Errors should be logged without exposing secrets or unnecessary personal information.

8. Analytics and privacy

Pathros uses privacy-first analytics for site performance and product learning. Analytics events should not contain names, emails, phone numbers, company-sensitive details, secrets, or form text.

• Allowed events: page view, CTA click, form start, form success, form error, evidence-page open.
• Disallowed event payloads: email address, name, company confidential data, phone number, access token, policy content, raw customer data.
• Analytics is used to improve the site, not to retarget visitors with ads.

9. Incident response

If Pathros identifies a security incident affecting customer information, we will investigate, contain, document, and notify affected customers as required by law and contract.

• Classify the incident.
• Contain the affected system or access path.
• Preserve relevant logs and evidence.
• Determine affected data, customers, and systems.
• Notify affected parties according to legal and contractual obligations.
• Complete a post-incident review and remediation plan.

10. Vulnerability disclosure

If you believe you found a vulnerability in Pathros, email security@pathros.cc.

Please include:

• The affected URL, endpoint, or system.
• Steps to reproduce.
• Potential impact.
• Any safe proof of concept.
• Your contact information if you want a response.

Do not access, modify, delete, copy, or exfiltrate data that is not yours. Do not perform denial-of-service testing, social engineering, physical attacks, spam, phishing, or destructive testing.

11. Customer responsibilities

A safe Pathros engagement depends on both sides doing the disciplined thing.

• Use a scoped read-only role for any audit unless a separate written agreement says otherwise.
• Do not send secrets through public forms, email, or chat.
• Review requested permissions before granting access.
• Revoke pilot access when the engagement ends.
• Confirm remediation plans in your own change-management process before production changes.