One Cyborg, one machine, one customer — the security architecture.

When you give something access to your email, your GitHub, your Notion, and your Slack — you're making a significant trust decision. You should understand exactly what you're trusting it with, where that access is scoped, how it's revoked, and what happens if something goes wrong.

This post is the complete answer to those questions. We're not summarizing our security posture — we're publishing the actual architecture. If something here isn't clear, or if you want the full technical specification, reach out to security@anilcyborg.com.

Single-tenant by default

The most important architectural decision we made: every Cyborg runs on its own dedicated Windows virtual machine. One Cyborg, one machine, one customer. No exceptions.

This is not the economically efficient choice — shared multi-tenant infrastructure would be significantly cheaper to run. We made the single-tenant decision deliberately, because the alternative creates attack surfaces that are genuinely hard to close.

What single-tenancy means in practice:

• No shared kernel. A bug or exploit in one customer's Cyborg cannot touch another customer's VM at the kernel level. The hypervisor enforces this — it's not application-level sandboxing.
• No shared model context. When your Cyborg queries a language model, the conversation context is isolated to your request. There is no shared prompt cache that could theoretically leak context from another customer's session.
• No shared memory. Your Cyborg's memory — the accumulated context about your team, your projects, your preferences — lives on your VM's disk. It has no pathway to another customer's data.
• No shared disk. Your Cyborg's credential store, audit log, and memory snapshots are on your machine. Physically separate from every other customer.

Auth architecture

Every tool integration is authorized via scoped OAuth. The Cyborg does not use your personal login. It does not store your password. It holds a service account token with the minimum scopes required for its role.

How this works in detail:

Service accounts, not user accounts

During onboarding, we create dedicated service accounts for each tool (e.g., a GitHub bot account, a Gmail service account). These accounts are owned by the customer — they appear in your admin panel, you can see what they're doing, and you can revoke them at any time without affecting your personal account.

Minimum scopes

A Software Engineer Cyborg that needs to open PRs on GitHub doesn't get admin access to your org. It gets repo-scoped write access for the specific repositories you designate. A Marketing Cyborg that sends emails doesn't get access to your entire Gmail — it gets access to send from a specific alias. We define minimum-scope bundles for each role, and we don't request anything beyond that.

Token storage

OAuth tokens are stored in the Cyborg's credential store on its VM, encrypted with the customer's key. The token is never logged. It never appears in the audit log. It is never transmitted to our infrastructure except during the initial token exchange. If you export your audit log, you will not find tokens in it.

Revocation

You can revoke any individual tool's access from the customer admin panel. The revocation takes effect in under 30 seconds — the Cyborg's credential store is updated, the runtime detects the missing token at the next guardrail check, and the action requiring that token is blocked and logged. You can also revoke all tool access simultaneously via the kill switch (covered below).

Data isolation

Customer data never leaves your Cyborg's machine unless you explicitly export it. This is not a policy — it's architecture.

When your Cyborg reads a document from your Google Drive, that document is processed locally on your VM. The content is passed to a frontier model for analysis (via an API call to the model provider), but that call uses your Cyborg's session context — it is not shared with any other customer's requests, and the model provider's data handling is governed by our data processing agreement with them, which includes confidentiality obligations.

After processing, the extracted insight or the generated output lives in your Cyborg's memory on your VM. It does not travel back to our infrastructure. We have no copy.

Memory snapshots — point-in-time exports of the Cyborg's full memory state — are encrypted with your customer-scoped key before being written to disk. We cannot decrypt them. If we were served a legal order to produce your data, we could produce the encrypted snapshots — but decryption would require your key, which we don't hold.

Encryption

Two environments, two standards:

• At rest: AES-256. Applied to all data on the Cyborg's VM disk: memory files, the audit log, the credential store, working files. Keys are customer-scoped and stored in a hardware security module (HSM) that we don't hold. You rotate keys from your admin panel.
• In transit: TLS 1.3. All network traffic between the Cyborg and external services uses TLS 1.3 with certificate pinning for our core infrastructure endpoints. Older TLS versions are disabled at the VM firewall level.

No plaintext tokens are stored anywhere in our systems. The credential store on the VM holds tokens in encrypted form. Our infrastructure databases hold no customer credentials at all — the only copy is on the customer's VM.

The audit log

Every action a Cyborg takes is logged. This is not configurable — it cannot be disabled. Here's what a log entry contains:

• Unique action ID (UUID)
• Timestamp (UTC, millisecond precision)
• Action type (read / write / send / execute / escalate / skip)
• Target system and resource identifier (e.g., GitHub repo, Linear ticket ID)
• Decision rationale (the model's stated reason for the action, as a brief structured string)
• Guardrail check result (pass / block / escalate)
• Human approval record (if applicable: who approved, when)
• Outcome (success / failure / partial, with error code if applicable)

The log is append-only. Entries cannot be edited or deleted. It is stored on the Cyborg's VM in a structured format that can be exported to CSV, JSON, or a syslog-compatible stream for integration with your SIEM.

The log is replay-able. You can reconstruct exactly what the Cyborg did on any given day, in order, by reading the audit log. This is a deliberate design goal: if something goes wrong, you should be able to understand precisely what happened without relying on our support team to explain it to you.

The kill switch

One button, in your admin panel. It does four things simultaneously:

1. Sends a SIGSTOP to the Cyborg's workflow engine process. The current task pauses at the next state boundary.
2. Revokes all OAuth tokens from the credential store. Calls to all connected tools will fail immediately.
3. Freezes the VM at the hypervisor level. No new processes can start.
4. Creates a timestamped kill event in the audit log, which cannot be removed.

Mean time from kill-switch activation to full halt: under 30 seconds. We test this on every deployment cycle. The SLA commitment is documented in our SLA.

Resuming after a kill requires explicit action from a customer admin — the Cyborg does not restart automatically. When it resumes, it replays its state from the last completed audit log entry and continues from there. No work is lost. The task that was interrupted resumes from the point it stopped.

Compliance path

We're building toward the standards that enterprise customers require. Current status:

Our DPA is available at anilcyborg.com/dpa. It specifies sub-processors, data retention periods, breach notification timelines, and data subject request procedures. If you need a custom DPA for enterprise procurement, reach out to security@anilcyborg.com.

Security isn't a feature we added. It's the architecture we built everything on top of. If the isolation breaks, the product breaks. We built it this way because there's no other way to build something you can genuinely trust.

If you find a vulnerability, please disclose it responsibly at security@anilcyborg.com. We have a responsible disclosure policy and we will respond within 24 hours.