Security

Current status (subject to change as audits land):

In transit. All connections to the Service use TLS 1.3 with modern cipher suites (AEAD-only; no SHA-1, no RC4, no static RSA). HSTS is enabled site-wide with a one-year max-age and the preload list. Internal service-to-service traffic is required to use mutual TLS; that rollout is still being completed across every service path.

At rest. The production design requires AES-256-GCM for Customer Content with keys managed by Amazon Web Services KMS. Workspace-scoped keys are part of the Enterprise launch plan.

Key management. Provider API keys you store with Osyra are sealed with envelope encryption. Plaintext keys exist only momentarily in service memory during a request and are zeroed on completion. Root keys are rotated annually; data-encryption keys follow the configured Amazon Web Services KMS rotation policy.

End-user authentication. The Osyra dashboard supports username/password with mandatory TOTP MFA (RFC 6238), SAML 2.0 SSO (Enterprise), and SCIM 2.0 user provisioning (Enterprise). Passwords are hashed with Argon2id using OWASP-recommended parameters.

Session and tokens.Access tokens are short-lived ES256-signed JWTs (15-minute TTL by default). Refresh tokens are bound to a token-family and are revoked on detection of replay. Single-sign-on sessions inherit the IdP's session lifetime (configurable, default 12 hours).

API authentication. Programmatic access uses OAuth 2.0 (authorization-code-with-PKCE for user contexts, client-credentials for machine-to-machine) or Personal Access Tokens. PATs are scoped to a workspace and a permission set.

Internal access. The production access policy requires SSO, hardware-bound MFA, short-lived session credentials, and audited break-glass elevation. These controls must pass the launch readiness gate before production access is enabled.

The AWS-only launch plan places the Service on Amazon Web Services in us-east-1, with eu-west-1 planned as the Enterprise EEA option. The architecture uses separate VPCs, private data-plane subnets, and controlled ingress through the edge gateway.

The launch design runs compute on managed Kubernetes (EKS) with restricted pod security standards, non-root containers, and read-only root filesystems. Stronger sandbox isolation (gVisor / Firecracker) for any untrusted third-party-code execution is on the roadmap.

The planned data layer uses PostgreSQL (RDS Multi-AZ), Redis (ElastiCache), and S3 object storage with policies requiring encryption in transit and at rest. Sensitive blobs also require application-layer encryption before launch.

Provider activation. Osyra has not launched a production service or placed production Customer Content with these providers. This register documents the engineering launch data-flow plan; every provider remains subject to security, privacy, and contract review before activation.

The production design routes structured audit logs to a separate Amazon Web Services security account with access controls independent from workload accounts. Retention is applied by workspace policy and applicable contract.

The launch monitoring plan routes real-time alerts through the documented incident runbook. On-call coverage and customer response targets are confirmed in the applicable service agreement before production activation.

Customer-facing audit logs are surfaced in the dashboard and via the GraphQL API for the events wired to the audit pipeline today. SIEM export for Enterprise customers — webhook or streaming delivery to Splunk, Datadog, or Sumo Logic under a signed delivery contract — is planned and not yet generally available.

Code review. All production changes are peer-reviewed by at least one engineer who is not the author. Sensitive areas (auth, billing, key management) require a security reviewer.

Static and dependency analysis. Every pull request runs SAST, secret-scanning, dependency vulnerability scanning, and license-compliance checks. Findings above the agreed threshold block merge.

Container scanning. Images are scanned at build time and weekly in registry. Critical and high vulnerabilities are remediated within the timelines in our internal vulnerability-management policy.

Branch protections. The default branch requires signed commits, successful CI, and review. Production deploys are GitOps-driven (ArgoCD) with canary rollouts (5% → 25% → 50% → 100%) and automatic rollback on health-check regression.

Training. All engineers complete annual secure-coding training; incident-response drills run quarterly.

We are establishing an independent third-party penetration-testing programme on a planned quarterly cadence and after material changes to the Service. As the programme matures, a summary letter will be available on request under NDA and the full report shared with Enterprise customers under their MSA.

The launch plan combines Amazon Web Services Inspector for cloud workloads, Trivy for containers, and repository dependency scanning. Findings are tracked through the engineering security workflow; published remediation commitments are set in the applicable customer agreement.

Backups. The launch configuration targets point-in-time database recovery, encrypted snapshots, and routine restore tests. Final retention and replication settings follow the workspace policy and applicable service agreement.

Recovery objectives. Our design targets are a 5-minute RPO and a 4-hour RTO for full-region failover. These are engineering targets and have not yet been independently validated by a full-scale DR exercise. Smaller-scope failures (single AZ, single service) are mitigated by Multi-AZ deployment with auto-failover.

DR exercises. A full disaster-recovery exercise on an annual cadence, with smaller quarterly tabletop exercises, is being established; outcomes will be documented and fed back into the runbook.

We follow a documented incident-response process with severity tiers, on-call escalation, communication templates, and a post-incident review for every SEV-1 / SEV-2. For incidents affecting Customer Content or personal data, we will notify the Customer without undue delay and in accordance with applicable law (GDPR Article 33: 72-hour controller notification; we provide enough information to meet your downstream obligations as soon as we have it).

All personnel are subject to background checks (where lawful), confidentiality agreements at hire, mandatory security awareness training at hire and annually, role-based access provisioning with least-privilege defaults, and prompt offboarding within one business day of termination. Contractors are held to the same standard by contract.

The Service records an audit log of authenticated actions — each record includes the actor, target, action, request identifier, source IP, and outcome. Today this covers the events wired to the audit pipeline. A tamper-evident, WORM-retained ledger over every tenant action is on the V1 roadmap and not yet live for all events. As it lands, Enterprise customers will be able to receive ES256-signed receipts (COSE_Sign1 envelope) suitable for downstream regulatory evidence (e.g. EU AI Act Annex IV).

Report vulnerabilities to security@osyra.ai. PGP key and machine-readable contact details are at /.well-known/security.txt (RFC 9116).

Safe harbour. We will not pursue legal action against, or report to law enforcement, researchers who (a) report in good faith, (b) avoid privacy violations, data destruction, or service degradation, (c) limit testing to in-scope assets, and (d) give us a reasonable opportunity to remediate before public disclosure (typically 90 days).

We respond to reports within one business day, triage within five, and remediate per severity. We publish a public acknowledgement after coordinated disclosure (with researcher consent).

Security inquiries: security@osyra.ai

Enterprise security questionnaires (SIG-Lite, CAIQ): same address, allow up to five business days for the first response.