How we protect website submissions, planner intake, and internal workflows.
A practical view of the public website controls: validated intake, no uploads, rate limits, CRM boundaries, and human review for sensitive cases.
Last updated
July 2026
This policy covers the public website. Internal SOW, commercial, delivery, and support tools are governed separately.
Short version
The website is designed for public discovery and secure project intake. It blocks sensitive/internal routes, keeps the planner upload-free, rate-limits sensitive systems, and routes security or manual-review cases to staff.
Security posture
AorBorC treats the website as a public intake and planning system, not as a place to expose internal estimates, SOWs, commercials, credentials, or private delivery tools.
The public flow is intentionally limited to project intake and sales qualification. Internal SOW, commercial, delivery, and support tooling live outside this public website project.
Scheduled jobs require server-side secrets, production HMAC flows fail closed when secrets are missing, and admin APIs check the relevant admin module before sensitive operations.
Public pages are built to be crawlable by search engines and AI assistants, while admin, auth, API, lab, and token-gated generated-document routes are blocked or noindexed.
Identity and abuse controls
The Project Planner validates submitted email addresses and rejects obvious spam or malformed requests before saving them.
The planner uses rate limits and a honeypot field to reduce bot abuse.
Sensitive admin actions remain behind authenticated staff access and server-side secrets.
Reference URL handling
The public Project Planner does not accept file uploads.
If a user shares URLs through another channel, staff review them manually before using them for delivery decisions.
Unsafe references are excluded from project planning and handled through manual review.
AI safety and token efficiency
AorBorC may use AI internally to identify gaps, prepare UAT thinking, and support documentation. Humans remain accountable for delivery, security, and commercial decisions.
The public Project Planner does not generate a customer-facing BRD, SOW, commercial, or quote.
Customer-specific intake stays in internal systems and is reviewed before any commercial or delivery commitment.
Data storage and access
Project planner requests, rate-limit events, CRM push status, and manual-review status are stored in Supabase-managed Postgres.
Admin access is restricted to authenticated AorBorC staff and service-role operations. Public users cannot browse planner records.
Sanitized CMS HTML must not include inline styles. Visual treatment belongs in CSS classes and theme tokens.
Manual review and Zoho Desk
Security review, CRM push failures, unclear requirements, and follow-up cases are routed to manual review.
When Zoho Desk is connected with the required ticket scope, the website can create Desk tickets and store the ticket status on the planner request.
If Desk is unavailable, the request remains marked for manual review with an admin-visible error.
What we do not expose publicly
The public site does not generate customer-facing SOWs, commercials, estimates, proposal decks, payment schedules, or quote PDFs.
The public site does not publish admin routes, internal documentation, per-customer generated documents, or lab experiments through sitemap or AI discovery files.
We do not expose public email addresses on marketing pages. Security and privacy enquiries should use the contact form.
Report a vulnerability
Submit vulnerability reports through /contact and include "Security" in the subject or message.
Include the affected URL, a clear reproduction path, expected impact, and whether any data was accessed. Do not include customer PII or exploit beyond what is needed to demonstrate the issue.
We review genuine security reports promptly and may follow up through Zoho Desk or email if more detail is needed.
Related policies
Security controls work alongside the Privacy Policy and Terms of Service.