Blast radius
One machine, nothing beyond
A command that wipes a filesystem wipes that machine. Other machines, other tenants, and the control plane are untouched, because nothing is shared for the damage to travel through.
MANSSINO / Security
Built to run code nobody reviewed.
A model will eventually produce a command you would never type yourself. Our answer is not a longer deny list, because a deny list assumes you can predict what the code will try. The boundary around a MANSSINO machine is enforced by the processor, which does not need to understand the code to contain it.
Position
- Hardware virtualisation, not container namespaces
- A dedicated kernel per machine, never shared
- Encrypted persistent disks and snapshots
- Root inside the walls, nothing outside them
01 Isolation model
A wall, not a policy.
Container isolation works by convincing a shared kernel to show each tenant a different view of the same system. It is fast and it is useful, but the kernel is still one piece of software, and a flaw in it is a flaw in the boundary. MANSSINO places a hardware boundary between tenants and gives each machine a kernel of its own, so a compromise inside a machine has nothing shared to reach through.
- Separate memory. Guest memory is mapped for that machine alone and is not addressable from any other guest.
- Separate filesystem. Each machine owns its block device. There is no shared layer, no shared cache, and no copy-on-write ancestry between tenants.
- Separate kernel. A kernel bug inside a guest is contained by the guest, because no other tenant is running on it.
- Narrow device surface. The virtual device model is deliberately small, which keeps the code a guest can talk to small as well.
Boundary map
Enforced by
The processor, through hardware virtualisation extensions.
Per machine
Kernel, memory, block device, and virtual network interface.
Shared
Host hardware only, scheduled by the hypervisor.
Inside the walls
Full root, loadable modules, raw devices, and Docker.
Control plane
Runs outside the guest and never executes code inside it.
02 Comparison
Three boundaries, three very different promises.
Each of these is the right answer to some problem. The question is which one you want standing between a model-written command and the rest of your infrastructure.
| Property | Language isolate | Container | MANSSINO machine |
|---|---|---|---|
| Boundary enforced by | The runtime | The shared kernel | The processor |
| Kernel | Shared with everyone | Shared with everyone | Dedicated per machine |
| Root inside | No | Restricted and risky | Yes, by design |
| Arbitrary binaries | No | Yes | Yes, including kernel modules |
| Persistent state | None | Volumes, bolted on | Native, snapshot and restore |
| Start cost | Milliseconds | Seconds with an image pull | Under 250ms from snapshot |
| Suitable for untrusted code | Only within the runtime's rules | Conditionally, with hardening | Yes, that is the design point |
03 Running untrusted code
Assume the worst command, then make it boring.
Teams running agent-written code should design for the day the agent does something destructive, not hope it never happens. The machine model makes that day uneventful.
Recovery
Replace instead of repair
A wrecked machine is one delete and one create away from a clean one. Keep a known good machine asleep and resuming it is faster than debugging the broken one.
Credentials
Scope what you hand over
Treat a machine as a place that holds whatever you put in it. Give agents short-lived, narrowly scoped credentials rather than keys that reach your production estate.
Practices we recommend
None of this is exotic. It is the same hygiene you would apply to a build server, which is exactly the point: a machine is a familiar object with familiar controls.
- One machine per untrusted session, deleted when the session ends.
- Narrow egress rules for fleets that run third-party or model-written code.
- Secrets injected per command through
envrather than written to the disk. - Results copied out to storage you control, so no machine is a system of record.
04 Data protection
Your disk, encrypted, and gone when you say so.
Persistence is a feature, which means deletion has to be a feature too. Both are explicit operations with predictable outcomes.
At rest
Encrypted storage and snapshots
Machine disks and the memory snapshots taken on sleep are encrypted at rest with keys managed by the platform and scoped per machine. A snapshot is never readable by another tenant and is never mounted outside its own machine.
In transit
Encrypted control and access paths
API traffic runs over TLS, SSH sessions use your own key pair, and the CLI speaks to the same authenticated endpoints. There is no unencrypted path to a machine.
Deletion
Delete means destroyed
Deleting a machine destroys its disk and every snapshot attached to it. There is no recovery window and no archive copy, which is deliberate: a persistent machine that cannot actually be erased is a liability.
Residency
Pinned to a region
A machine stays in the region it was created in, and its snapshots stay with it. Teams with residency requirements should tell us the region they need before they start building.
05 Access control
Keys that are easy to scope and easy to revoke.
Most incidents start with a credential that was broader than it needed to be or lived longer than anyone remembered. Access on MANSSINO is designed to make the narrow option the convenient one.
- Scoped API keys. Issue a key per environment or per service, limited to the operations it needs, and revoke it without touching the others.
- SSH by key pair. Shell access uses keys you hold. Passwords are not an option, so there is nothing to guess.
- Separate profiles. The CLI keeps credentials per profile so a workstation, a CI runner, and a production service never share one.
- Audit trail. Lifecycle operations are recorded with the key that performed them, which is what makes an investigation short.
06 Network controls
Open enough to work, closed enough to trust.
Inbound
Nothing published by default
A machine does not expose ports to the internet unless you ask for it. Reach services through SSH forwarding, which keeps access tied to a key you hold.
Outbound
Normal egress, narrowable
Machines reach the internet so that installs, crawls, and API calls behave normally. Fleets running untrusted code can have egress restricted to an allowed set of destinations.
Between machines
No implicit trust
Machines do not share a flat private network by default. Teams that need machines to talk to each other get an explicit private network rather than an accident of topology.
07 Operations
What we do on our side of the wall.
Isolation is an architecture, but it is also a set of habits. These are ours, stated plainly so you can hold us to them.
- Host and hypervisor patching. Hosts are updated on a regular cadence, and critical fixes are rolled out ahead of it. Machines are migrated or scheduled around maintenance rather than being terminated under you.
- Control plane separation. The control plane runs on its own infrastructure, holds no shell access into guests, and cannot read a machine disk.
- Least privilege internally. Access to production systems is scoped per role, time limited, and logged.
- Incident communication. If something affects your machines we will tell you what happened, what we changed, and when, without waiting for a quarterly report.
Certifications
We do not claim audits we have not completed. Formal programmes are under way and we will publish them when they are finished, not before.
Security questions
Send them with your access request and an engineer will answer them directly, including architecture detail under a mutual agreement where that is needed.
Vulnerability reports
If you find something, write to us through the request page and mark it as a security report. We will acknowledge it and keep you updated until it is closed.
08 Shared responsibility
Where our job ends and yours begins.
Root access is the whole point, and it comes with the obligations root has always carried. The line is simple enough to state in one table.
| Area | MANSSINO | You |
|---|---|---|
| Isolation between machines | Ours, enforced in hardware | Nothing to configure |
| Host and hypervisor patching | Ours | Nothing to configure |
| Guest operating system updates | We ship a current base image | Yours once the machine is running |
| Packages you install | Not inspected, by design | Yours |
| Secrets placed on a machine | Encrypted at rest with the disk | Yours to scope and rotate |
| Egress policy for a fleet | We implement what you ask for | Yours to decide |
| Deleting data you no longer need | Deletion is immediate and complete | Yours to trigger |
Waitlist open
Bring your hardest security question.
Tell us what you plan to run and what has to be true for you to run it here. We would rather answer the architecture questions now than have you discover the answer later.
- Hardware isolation with a dedicated kernel per machine.
- Encrypted disks and snapshots, destroyed on delete.
- Scoped keys, key-based SSH, and an audit trail.
- Egress controls for fleets running untrusted code.