Orchra Security at Orchra
This page describes how Orchra protects revenue data and governs the AI agents that act on it. For responsible disclosure or a security questionnaire, contact security@orchra.io.
Application and data security
Orchra is designed as the system of action for an entire revenue motion, so it treats revenue data — pipeline, forecasts, communications and financial signals — as sensitive by default. Data is encrypted in transit, access is limited to authorized staff under least-privilege principles, and customer data is logically isolated.
Encryption
All traffic to the site and application is served over HTTPS with modern TLS, HTTP Strict Transport Security (HSTS), and automatic certificate renewal. Forms and early-access submissions are protected in transit.
Access control and least privilege
Access to systems and data is role-based and limited to staff who need it for their work. Administrative access is restricted, and sensitive actions are logged.
AI agent governance and permissions
Orchra can dispatch AI agents to execute routine revenue work. Each agent operates within explicitly scoped, role-based permissions; sensitive actions can require human approval; and every agent action is captured in a versioned, attributed audit trail so it can be reviewed and reversed. We do not use private customer revenue data to train shared or third-party foundation models.
Logging and audit trail
Sensitive operations — including AI agent activity, configuration changes and forecast overrides — are recorded with attribution. This is the same audit trail that makes the forecast defensible: every figure drills to its formula and the underlying signal.
Infrastructure and hosting
Early-access and application data are stored on our application backend located in the Kingdom of Saudi Arabia. The marketing site is delivered through Cloudflare's content delivery network with a web application firewall, bot controls and rate limiting available at the edge. See data residency for cross-border detail.
Secure development
Security is part of our development lifecycle: dependency and vulnerability management, code review, and change control with the ability to roll back. We tune security response headers — including Content-Security-Policy, X-Frame-Options/frame-ancestors, Referrer-Policy and Permissions-Policy — to reduce browser-side risk such as clickjacking and information leakage.
External attack surface management
Orchra maintains a controlled view of its public footprint to reduce exposure that could affect customer trust or procurement readiness:
- Subdomain inventory and lifecycle — known assets have an owner, purpose and review date; stale DNS records are removed to prevent subdomain takeover.
- DNS governance — changes follow approval, change-logging and periodic stale-record review; CAA records restrict certificate issuance.
- Email authentication — SPF, DKIM and DMARC protect the orchra.io domain against spoofing and phishing and support deliverability.
- Security headers and TLS — HSTS, CSP and related headers are deployed; HTTPS is enforced with valid, auto-renewing certificates.
- Certificate transparency monitoring — newly issued certificates for Orchra domains are monitored to detect unexpected subdomains or unauthorized issuance.
- Leakage monitoring — periodic review of public search results, repositories and storage for accidental exposure of credentials, internal URLs or documents.
Responsible disclosure
If you believe you have found a security issue, please email security@orchra.io with details and steps to reproduce. We ask that you give us a reasonable opportunity to remediate before any public disclosure, and that testing is limited to assets you are authorized to test.