Deployment models
CyberArmor runs two ways: hosted SaaS operated by CyberArmor, and self-hosted in your own environment. It is the same stack in both cases. The 15-minute local proof-of-concept is the self-hosted path running end to end on a single laptop — the self-hosted model is demonstrated, not promised.
- Hosted SaaS — CyberArmor operates the control plane; tenants are isolated by scope on every policy, evidence, and identity record.
- Self-hosted — the full stack deploys into your infrastructure from the same Docker Compose and Helm definitions the local PoC uses.
Encryption
TLS terminates every public domain. Service-to-service mTLS ships in the stack and activates with certificate provisioning at deployment. At rest, platform data lives in the deployment's PostgreSQL database and follows that deployment's database and disk encryption posture — hosted or yours. MFA secrets are encrypted at rest.
Authentication
The platform's own front door is enterprise-grade and runs in production today.
- Enterprise SSO (OIDC) — authorization-code + PKCE flow with just-in-time provisioning and ID-token claims enrichment on every login.
- Multi-factor authentication — RFC 6238 TOTP with backup codes, per-user enrollment, and a per-tenant requirement flag.
- Directory enrichment from Entra ID, Okta, Ping, and AWS IAM Identity Center resolves every audit event and incident to a named user, department, and group.
Secrets handling
Service credentials are managed through OpenBao, the open-source secrets manager, which ships as part of the deployment stack in both the Docker Compose and Helm definitions. Secrets are provisioned at deployment rather than baked into images, and the support runbooks include a dedicated secrets-path triage procedure.
Data handling
The platform processes prompts, URLs, file events, and endpoint telemetry — content that can contain credentials, PII, and non-public information. It is built to treat that content as sensitive: redaction policy outcomes run in production in the AI proxy and endpoint agent, and HMAC content-hash pseudonymization replaces redacted values with deterministic per-tenant tokens, so audit records correlate without exposing raw PII. Evidence is stored tenant-scoped, bound to the control decision that produced it. Data residency and retention specifics for your deployment are documented in the customer security package.
Engineering practice
The platform is founder-built — engineered end-to-end by its founding engineer, with a proof-obsessed culture: a capability is claimed only after it is verified by hand on real hardware. The Windows agent install was verified on a physical endpoint; robotic actuator clamping was verified on the wire on a physical Raspberry Pi 5. The public capability status page is our standing disclosure of exactly what is production, pilot-ready, configurable, and roadmap — updated as the codebase changes, not as marketing requires.
Vulnerability disclosure
Report security issues affecting our public site or product surfaces to security@cyberarmor.ai. Include the affected hostname, path, timestamp, and reproduction details. We acknowledge reports, investigate them, and credit reporters who want credit. Do not test against systems or data you are not authorized to access.
Compliance posture
The platform ships 17 compliance framework policy packs — SEC Cyber, FINRA Cyber, NYDFS 500, SOC 2, ISO 27001, ISO/IEC 42001, and NIST CSF among them — with persisted, tenant-scoped evidence bound to each control decision and per-framework assessment reports scored and stored. CyberArmor's own SOC 2 certification is a roadmap item: we state that plainly rather than implying otherwise, and the compliance engine exists precisely so that posture is a queryable fact, not a slide.
Running a vendor review?
The customer security package covers architecture, data flows, residency and retention, and deployment-specific controls in the depth a third-party-risk assessment needs.
Request the customer security package