— TRUST CENTRE
One Cyborg, one machine, one customer.
Every Cyborg you hire runs on its own dedicated Windows VM, in our data-centre, with its own keys, its own audit log, and zero shared memory. No multi-tenant database. No cross-customer leakage by architecture. This is what your IT, security, and compliance reviewers will check — so we built it to pass before they ask.
A whole machine, just for your Cyborg.
No "shared inference cluster". No "we promise the prompts don't leak". A Cyborg is an OS process tree on a VM that exists only for you. Spin one up: a new VM is provisioned. Fire it: the VM is destroyed. Hire ten: ten machines, ten boundaries.
Each row is fully isolated. No shared kernel between customers. No shared memory across Cyborgs. No shared file-system. No shared identity.
-
01
Dedicated Windows VM
Each Cyborg = its own Windows machine. Its own user account. Its own profile, its own browser, its own apps, its own files.
-
02
Dedicated identity
Each Cyborg has a unique work email + Microsoft Entra (Azure AD) identity issued under your tenant. It signs into your tools as itself, never as you.
-
03
Dedicated network namespace
Egress is logged + scoped. No outbound calls to undeclared destinations. Allowlist controlled per role + per integration.
-
04
Disposable by design
Fire a Cyborg → its VM is wiped to factory + securely destroyed within 7 days. Re-hire later → a fresh VM is provisioned. No "ghost" data persists.
-
05
Region pinning available
EU residency, India residency, UAE residency on enterprise plans. Default region selected by your billing country, never changed silently.
-
06
Full activity log
Every action a Cyborg takes — file open, app launch, message sent, API call — is recorded in the customer-visible Activity Log.
Where your data lives. And where it doesn't.
A blunt walk-through of every place customer data could touch — and what stops it from crossing the line.
-
01
Inside your tools
Most of your data never leaves your tools. The Cyborg works inside Microsoft 365, GitHub, Slack, Notion, etc. — same as a human employee. We see the screen + actions, not your underlying database.
→ stays in your stack -
02
On the Cyborg's VM
Working files (drafts, screenshots, scratch notes) live on the Cyborg's dedicated VM disk, encrypted at rest. No other customer's Cyborg can read it. No engineer can read it without a break-glass review.
→ encrypted, isolated -
03
In the AI provider call
When the Cyborg reasons, it calls a foundation model. Calls go over TLS 1.3 with our enterprise contract: zero training on your prompts/outputs, zero retention beyond the request, no sub-processor sharing.
→ no training, no retention -
04
In the activity log
Every action is logged to a per-customer log store, retained 90 days standard / 12 months enterprise. Logs hold action metadata + redacted payloads — never raw secrets, tokens, or full PII bodies.
→ per-customer log -
05
On offboarding
Fire the Cyborg → VM wiped + destroyed in 7 days. Activity log retained per your retention setting, then permanently deleted. Customer-initiated full purge available within 24 hours on request.
→ purged on request
Encrypted everywhere. Keys you can rotate.
Industry-standard primitives, used the boring way. No custom crypto. No "trust me" key management.
At rest
AES-256 on every disk we own — VM disks, log stores, backup snapshots, audit archives.
- Full-disk encryption on every VM
- Encrypted DB volumes (provider-managed)
- Encrypted backups, encrypted snapshots
- No plaintext secrets on disk — vault-only
In transit
TLS 1.3 everywhere — Cyborg ↔ tools, Cyborg ↔ AI providers, dashboard ↔ API, internal services.
- HSTS + cert pinning on `*.anilcyborg.com`
- mTLS between internal services
- No mixed-content, no plaintext fallbacks
- Modern cipher suites only (no SSLv3 / TLS 1.0/1.1)
Key management
Keys live in a managed KMS / HSM. Per-customer keys for tier-2+ enterprise. Rotation built-in.
- Per-tenant DEKs wrapped with KMS-managed KEKs
- BYOK / CMEK on enterprise (AWS KMS, Azure Key Vault, GCP KMS)
- Auto-rotation every 90 days standard
- Cryptographic erasure on offboarding (key destroy)
Who can do what. All of it logged.
Identity, authorization, audit. Same playbook your IT team already trusts.
Identity & access
- SSO — SAML 2.0 + OIDC (Okta, Azure AD/Entra, Google Workspace, JumpCloud).
- SCIM — auto user provisioning + deprovisioning.
- MFA enforced — TOTP, WebAuthn / passkeys, security keys.
- RBAC — Owner / Admin / Manager / Viewer + per-Cyborg ACLs.
- Just-in-time access — no standing engineer access to customer VMs.
- IP allowlisting on the management dashboard (enterprise).
- Session timeout + device-binding for high-risk actions.
Audit & observability
- Activity Log — every Cyborg action, with who/what/when/where/result.
- Admin audit log — every dashboard action, every config change.
- Approval log — every human-in-the-loop decision recorded.
- Sign-in log — successful + failed auth attempts, IP + UA.
- Export — JSON / CSV / SIEM webhook (Splunk, Datadog, Elastic).
- Retention — 90 days standard, 12 months enterprise add-on.
- Tamper-evident — append-only, hash-chained.
Live now. Audited next.
We don't bluff certifications. Here's exactly what's compliant today, what we're auditing for, and when.
| Framework | Region | Status | Target / live | |
|---|---|---|---|---|
| GDPR | EU | ● Compliant | Live · launch | Get DPA → |
| UK GDPR | UK | ● Compliant | Live · launch | Get DPA → |
| DPDP Act | IN | ● Compliant | Live · launch | Get DPA → |
| CCPA / CPRA | US-CA | ● Compliant | Live · launch | Get DPA → |
| SOC 2 Type 1 | GLOBAL | ◐ In audit | Within 6 months | Track → |
| SOC 2 Type 2 | GLOBAL | ○ Planned | Within 18 months | Notify me → |
| ISO 27001 | GLOBAL | ○ Planned | Within 24 months | Notify me → |
| EU AI Act | EU | ◌ Monitoring | Will comply per timeline | Read pos. → |
| HIPAA · PCI · FedRAMP | SECTOR | ◌ On request | Case-by-case | Talk → |
* "Compliant" means we operate under the framework's controls + sign DPAs accordingly. SOC 2 / ISO 27001 = third-party-audited certifications. Status updated quarterly. Last review: 2026-Q2.
What our Cyborgs will and won't do.
Eight public commitments. Plus a hard list of things we refuse to deploy Cyborgs for — regardless of contract value.
- 01
Transparency
Customers know which AI provider powers each Cyborg. Every action is auditable in the Activity Log. Model + data choices are published, here.
- 02
Customer data ownership
You own all your data + Cyborg work output. We do not train any model on your data without explicit written opt-in.
- 03
Per-Cyborg isolation
Dedicated VM per Cyborg. No shared memory across customers. No cross-customer leakage by architecture, not just policy.
- 04
Human oversight by design
Every Cyborg has a human Manager on your side. Critical actions (financial, irreversible, external comms) require explicit human approval by default.
- 05
Honest capabilities
We don't claim Cyborgs are perfect. Each role page lists what it can and can't do. Realistic week-1 to week-12 ramp expectations published.
- 06
Bias & fairness
Annual external bias audit on hiring / performance / segmentation tasks. Customers can opt out of decisions in protected-class contexts.
- 07
Safety guardrails
Each Cyborg operates inside a defined scope. Cyborgs cannot self-escalate scope. Hard-coded refusals for prohibited content. Rate limits + anomaly detection on outbound.
- 08
Mistakes & accountability
If a Cyborg makes a mistake, you're informed within 24 hours of detection. RCA shared. Compensation per SLA. Repeated systemic issues → public post-mortem.
What Cyborgs will never be used for.
- Mass disinformation campaigns.
- CSAM or non-consensual sexual content.
- Targeted harassment of individuals.
- Unauthorized surveillance of customers' employees.
- Replacing humans where a licensed professional is required by law (legal practice, medical diagnosis, regulated financial advice).
- Use cases that violate our Acceptable Use Policy.
This list applies regardless of contract size or customer revenue.
When something goes wrong, here's the clock.
Pre-committed SLAs. Severity tiers borrowed from how SREs run real incidents. Public post-mortems on SEV-1.
| Severity | Definition | Customer notified | Resolution target | Post-mortem |
|---|---|---|---|---|
| SEV-1 | Customer financial harm or data leakage. | Within 4 hours | Within 24 hours | Public, within 14 days |
| SEV-2 | Customer operational disruption (Cyborg paused, output blocked). | Within 12 hours | Within 72 hours | Private RCA |
| SEV-3 | Minor mistake / off-quality output. | Next reporting cycle | Next cycle correction | In monthly report |
| SEV-4 | Customer-side feedback / preference issue. | As raised | Next training / SOP update | Documented internally |
* Aggregate incident statistics published in our annual Responsible AI report. SEV-1 post-mortems live at /blog/post-mortems. Email security@anilcyborg.com 24×7 for vulnerability disclosure.
Every question your CISO will ask.
11 questions security reviewers ask in the first call. Direct answers. No marketing fog.
Is the Cyborg multi-tenant?
No. Each Cyborg runs on its own dedicated Windows VM with its own user account, its own keys, and its own network namespace. There is no shared inference cluster. No shared database. No shared memory. Multi-tenancy exists only at the management plane (your dashboard), never at the Cyborg execution plane.
Will my data be used to train AI models?
No, never — without your explicit written opt-in. Our enterprise contracts with foundation-model providers (OpenAI, Anthropic, etc.) include zero-training, zero-retention clauses on your prompts and outputs. You own everything. We can't and won't train on your data.
Where is data stored? Can I pin a region?
Default region is selected by your billing country (EU customers → EU, India → India, UAE → UAE, US → US). Enterprise plans get explicit region pinning per Cyborg with contractual data-residency guarantees. We never silently migrate a customer's data across regions.
How is encryption handled? Can I bring my own keys?
AES-256 at rest, TLS 1.3 in transit. Per-tenant data encryption keys (DEKs) wrapped with KMS-managed key encryption keys (KEKs). Auto-rotation every 90 days. Enterprise customers can BYOK / CMEK via AWS KMS, Azure Key Vault, or Google Cloud KMS — including cryptographic erasure (key destroy → data unreadable) on offboarding.
Do you support SSO, SCIM, MFA?
Yes — SSO via SAML 2.0 + OIDC (Okta, Azure AD/Entra, Google Workspace, JumpCloud, custom). SCIM for auto-provisioning + deprovisioning. MFA enforced for all admin accounts (TOTP, WebAuthn / passkeys, security keys). RBAC with Owner / Admin / Manager / Viewer roles + per-Cyborg ACLs.
Can your engineers see my data?
Not by default. There is no standing engineer access to customer VMs. Break-glass access requires: (1) written customer authorization or a SEV-1 incident, (2) two-person approval, (3) full session recording, (4) audit log entry visible to you. We treat this as the exception, not the rule.
What audit logs do I get?
Three streams: Activity Log (every Cyborg action — file open, app launch, message sent, API call), Admin Audit Log (every dashboard change), Sign-in Log (auth attempts). All append-only, hash-chained, exportable to SIEM (Splunk, Datadog, Elastic) via webhook. 90 days standard / 12 months enterprise.
Are you SOC 2 / ISO 27001 certified?
SOC 2 Type 1 audit in progress (target: within 6 months). SOC 2 Type 2 follows (within 18 months). ISO 27001 within 24 months. We're already operating under their controls — the audits formalize what we already do. Track status above; subscribe via security@anilcyborg.com for milestone notifications.
What's your incident response SLA?
SEV-1 (financial harm / data leakage): customer notified within 4 hours, resolution within 24, public post-mortem within 14 days. SEV-2: notified within 12 hours, resolved within 72. SEV-3 / SEV-4: handled in regular reporting cycles. See the table above for the full matrix.
Do you have a vulnerability disclosure program?
Yes. Report vulnerabilities to security@anilcyborg.com (PGP key on the page). We acknowledge within 1 business day, triage within 5. Bounty program launches with SOC 2 Type 2.
What happens to my data if I cancel?
VM wiped to factory + securely destroyed within 7 days. Activity log retained per your retention setting (90 days standard), then permanently deleted. Customer-initiated full purge available within 24 hours on request — you get a signed deletion certificate.
Let your security team dig in.
Send our DPA. Run our questionnaire. Talk to our security lead. We'd rather you ask everything before you hire than after.
- 1:1VM per Cyborg
- 0Cross-tenant
- 4hSEV-1 SLA
- 24hPurge on request