Security & Privacy

Oblien is built for agents running untrusted code and storing user data. That means security is not a layer on top - it's the reason the architecture looks the way it does.

Two-layer security model

Every workspace is protected by two independent layers of security that work together to give you end-to-end control:

Both layers must be explicitly opened before anything can access a workspace. A workspace with no firewall rules and no tokens issued is completely unreachable - the network drops the packets before they ever hit the API.

This architecture makes workspaces ideal for autonomous agent control. An agent gets a fully isolated VM with a programmable runtime, and you control exactly what can reach it (firewall) and what can operate inside it (token). No ambient access, no shared attack surface, no accidental exposure.

• Firewall layer: Managed via public_access for gateway routing and private links for workspace-to-workspace calls. See Workspace Networking for detailed patterns.
• Token layer: Gateway JWTs for external access, raw connection tokens for direct access. See Internal API auth for setup.

---

We don't access what's inside your workspace

To be direct: Oblien operates the host infrastructure, so a sufficiently determined operator with physical access and root on the host could theoretically attempt to inspect a running VM. We won't pretend that's impossible. What the architecture does is make it practically very hard, immediately visible in audit logs, and against a strict internal policy with no legitimate operational reason to ever do it.

Each workspace is a Firecracker microVM with its own kernel and its own encrypted storage. When a workspace is stopped, the disk is encrypted at rest with a unique key per workspace - a host-level operator cannot access it without that key. When a workspace is running, the guest kernel owns the address space - the hypervisor interface is intentionally minimal and does not expose a memory inspection or filesystem read API. Getting to workspace data from the host requires active, logged, multi-step action. It doesn't happen by accident, and it doesn't happen.

What we access vs. what we don't:

---

Per-workspace encrypted disks

Every workspace gets a dedicated encrypted block device - a private virtual disk allocated at creation time. Nothing is shared between workspaces at the storage layer.

• The block device is attached exclusively to the workspace VM - the only path in or out of the disk is through that VM's kernel
• No other VM, no Oblien service, and no other account has access to the same device
• When a workspace is deleted, the block device is cryptographically erased - the encryption key is destroyed, making data unrecoverable regardless of what happens to the underlying hardware
• Disk I/O is rate-limited per workspace at the host level, preventing one workspace from affecting storage throughput of another

Persistent vs. temporary workspaces

Temporary workspaces leave nothing behind. Not on the host, not in backups - the key is gone.

---

Isolation is enforced by hardware, not software

Workspaces do not trust each other. This is enforced at multiple levels simultaneously:

Hardware-level (KVM)

Each workspace runs in a Firecracker microVM backed by KVM - the Linux kernel hypervisor. The guest address space is entirely separate from the host and from every other VM. A process inside workspace A has no address space that overlaps with workspace B under any circumstance.

Syscall filtering (seccomp)

The hypervisor process on the host is restricted to a minimal set of allowed syscalls. Every other syscall is blocked at the kernel level - not "returns an error", blocked before execution. This is the same mechanism AWS uses for Lambda.

Network isolation

Workspaces are network-dark by default. A newly created workspace has no connectivity to any other workspace - even within the same account. Network paths are explicitly opened when you add ingress rules. Everything else is dropped at the firewall level.

Process isolation

Each VM process runs in a dedicated, isolated sandbox with its own credentials and no access to the host filesystem or process tree. Oblien's own internal services run in a separate network and are not reachable from workspace VMs.

---

Host hardening and operational security

Runtime isolation only matters if the hosts running it are themselves hardened. The host is the last line of defence.

Host OS

• Hosts run a minimal, locked-down Linux distribution with no GUI, no unnecessary services, and no package manager in production
• The host filesystem is read-only at runtime - state lives only in VM storage and explicitly writable mount points
• Kernel is pinned to a validated version and updated on a defined patch cadence; security patches are applied within 24 hours of a critical CVE being published for the kernel or Firecracker
• Kernel security parameters are hardened beyond defaults at boot

Operator access controls

Patch cadence

---

Incident detection and response

Continuous monitoring

Hosts and the control plane are monitored continuously:

• System integrity - Critical file paths and binary execution on hosts are monitored; changes to critical binaries generate immediate alerts
• Network anomalies - Traffic patterns are baselined; deviations trigger automated investigation
• Control-plane - All API calls are logged with latency, error rate, and caller identity; anomaly detection fires on unusual access patterns
• KMS access - Every key request is logged; requests outside the expected flow are flagged

Log retention

Logs are written to an isolated, append-only store that production systems can write to but not read from or modify. Retrieval requires a separate access path.

Breach notification

In the event of a confirmed security incident that affects customer data:

• Affected accounts are notified within 72 hours of confirmation - consistent with GDPR Article 33 timelines
• Notification includes: what happened, what data was involved, what we are doing, and what you should do
• A public post-mortem is published after the incident is resolved, unless disclosure would materially aid an ongoing attack

---

Data processing - what actually happens

Your code and files never leave the workspace VM. Oblien does not receive, process, or transmit your application data. The only data that flows through Oblien infrastructure is:

How TLS termination actually works

TLS terminates at Oblien's edge nodes. This is unavoidable for HTTPS - the edge must decrypt to forward. What happens after termination:

• Request bodies are never written to disk on edge nodes - traffic is streamed to the upstream connection and released
• No request or response logging beyond the connection metadata (timestamp, source IP, status code, bytes transferred) required for abuse detection
• No caching - edge nodes are pure proxies, not CDN nodes; nothing is stored between requests
• No packet capture - edge nodes do not run tcpdump, eBPF capture, or any traffic recording tooling in production
• The internal channel from edge to workspace is encrypted end-to-end

Traffic is encrypted end-to-end. There is no plaintext segment at any point between the client and the workspace.

AI features

If you use Oblien's AI features (code generation, agent orchestration), prompts and context are sent to the configured model provider. Oblien does not retain these payloads after the response is returned. You control which model provider is used and can run fully on-premise models - in which case nothing leaves your account boundary.

---

Encryption and key management

How workspace keys work

Each workspace disk is encrypted with a unique key generated at creation time. That key is never stored in plaintext - it is managed through Oblien's internal KMS and protected with additional layers of encryption.

Key lifecycle:

• Generation - A unique key is generated per workspace at creation time
• Protection - Keys are managed through Oblien's KMS with strict access controls
• Rotation - Keys are rotated on a regular schedule
• Deletion - On workspace delete, the encryption key is destroyed, making data cryptographically unrecoverable
• Operator access - No Oblien engineer has standing permission to retrieve a workspace key. Access requires a break-glass procedure with a mandatory audit trail.

---

Compliance and data governance

Oblien is not yet certified under any compliance framework. That's an honest statement - certifications take time and we'd rather tell you where we are than claim something we haven't finished.

GDPR position

Oblien acts as a data processor when running your workspaces. You are the data controller - you decide what data enters the workspace and what it is used for. Oblien processes that data only to operate the infrastructure as instructed.

• Workspace data does not leave the region you deploy into
• We do not use customer workspace data for training, analytics, or any purpose other than running your workspace
• Data subject requests (deletion, export) for workspace content are your responsibility as controller; deleting a workspace triggers cryptographic erasure of all associated data on our side
• A Data Processing Agreement (DPA) is available on request for accounts that require it

---

What this means in practice

• You can run code that processes sensitive user data - it stays inside the VM
• You can store credentials, tokens, and secrets in the workspace filesystem - we cannot read them without a logged, audited, break-glass procedure
• You can run multi-tenant workloads where each user gets their own workspace - users are isolated from each other at the hardware level
• A compromised Oblien service cannot read your workspace data - the architecture ensures no service has standing access to workspace encryption keys
• If something goes wrong, you will hear about it within 72 hours, not after it makes the news

The threat model Oblien is designed for: a hostile tenant, a compromised host service, or a curious operator should not be able to access workspace data without it being logged, detected, and a deliberate violation of a process that requires a second human to approve. Encryption, isolation, and operational controls are all load-bearing - none of them alone is sufficient. All three together are what makes this production-ready.