Security & Trust
Runtime governance for AI contractor access.
OpenSyber is built for the case traditional endpoint controls miss: an external developer using Claude, Cursor, shell, GitHub, cloud tools, and MCP servers against sensitive repos.
Browser-isolated workspaces
Contractors work inside a hardened browser session with approved AI tools and MCP servers. Customer code and secrets do not need to land on an unmanaged laptop.
MCP policy chokepoint
Every MCP tool call routes through the OpenSyber gateway, where policy can allow, deny, redact, or require step-up auth before the upstream tool runs.
Device-bound identity
TokenForge binds contractor sessions to non-extractable device keys. Stolen cookies alone are not enough to replay a workspace session.
Signed audit chain
Prompts, tool calls, shell commands, repo actions, policy decisions, and evidence exports are linked into one reviewer-readable chain.
Certification status
OpenSyber is not yet SOC 2 or ISO 27001 attested. We are building and documenting the controls buyers expect from a security vendor, and we describe those controls plainly here. We do not use this page as a certification claim.
- 01Current: SOC 2 and ISO 27001 aligned controls, documented security practices, and product audit evidence.
- 02Next: design-partner questionnaires, security-pack review, and readiness gap remediation.
- 03Later: formal SOC 2 Type I, then Type II evidence period when customer volume makes the audit useful.
- 04As needed: ISO 27001 ISMS, risk register, Statement of Applicability, and external audit for EMEA deals.
Security pack
For design partners and security reviews, prepare one packet instead of rewriting questionnaire answers every time.
- Architecture and data-flow overview
- Access-control, MFA, and least-privilege summary
- Audit logging and retention details for workspaces, MCP calls, shell, and git actions
- Secure SDLC, code review, dependency scanning, and CI security checks
- Incident response, vulnerability disclosure, backups, and disaster-recovery notes
Reusable prospect answer
We are not yet formally SOC 2 attested. OpenSyber is an early-stage company building toward SOC 2 and ISO 27001 aligned controls.
Today, we can share our security architecture, access-control model, encryption posture, audit logging, incident response process, and product evidence exports.
We plan to pursue formal audit once customer volume and procurement demand make the evidence period useful rather than performative.
Data flow
- 01Contractor authenticates and enrolls a device-bound session.
- 02Workspace launches with approved tools, repos, MCP servers, and policy templates.
- 03AI tool invokes an MCP server, shell command, GitHub action, or cloud operation.
- 04OpenSyber evaluates policy before execution and records the decision.
- 05Audit records stream to the console, SIEM/webhooks, and compliance exports.
Controls buyers ask for
- TLS 1.3 in transit and encrypted secrets at rest
- Raw API tokens hashed; secrets are not logged in plaintext
- Cloudflare edge protections, WAF, rate limits, D1/KV/R2 storage
- Runtime telemetry from MCP gateway, Falco, osquery, and workspace events
- Regional deployment and longer retention available on Enterprise
- SOC 2 / ISO 27001 evidence mapping; not a certification claim
Compliance posture
OpenSyber generates evidence mapped to SOC 2, ISO 27001, HIPAA, GDPR, and upcoming AI governance frameworks. This is evidence generation and control mapping, not a statement that OpenSyber is certified or that your environment is automatically compliant.
Responsible disclosure
Report vulnerabilities to security@opensyber.cloud with reproduction steps and impact. We acknowledge reports within 24 hours and prioritize critical issues immediately.