Request Myrstack

Boundary is control

Your work is protected behind a series of layers governing access and approved changes.

01Security layers

Seven stacked security layers, top to bottom: Logical air gap, Verified boot, Split custody, Disk at rest, Memory in use, Least privilege, Signed updates. The selected layer, Logical air gap, is pulled forward and drawn in a deeper sage. Conceptual layers only, not a hardware specification.

01 /Logical air gap

Protects
Core server has no internet connection or outbound access. Inbound traffic is default-deny, with mutual authentication between components.
Note
Stateless frontend stores no data. If frontend is compromised, no information is taken from users.
Stops
  • Network attacks

02 /Verified boot

Protects
Firmware verified by a measured boot chain. Root filesystem is immutable during operation, backed by file-integrity monitoring.
Note
Rootkits and backdoors cannot persist across a boot that must verify before it runs. Any change must pass the same integrity checks.
Stops
  • Firmware tampering
  • Persistent rootkits

03 /Split custody

Protects
Disk-encryption passphrase is split between customer and Myrstack Labs, where it is sealed in a discrete TPM, released under secure-boot attestation only.
Note
Both shares needed for disk decryption. A subpoena to either party compels only that party's share, not the complete passphrase.
Stops
  • Legal compulsion

04 /Disk at rest

Protects
Full-disk decryption rely on two independent factors: a hardware attestation unique to each device, and a network-bound key available only to the authorised network. Both are required to unlock disks.
Note
If a Myrstack is stolen from the authorised network it will not boot, and its disks will remain encrypted.
Stops
  • Physical theft

05 /Memory in use

Protects
Processor-level encryption protects memory using ephemeral keys for each boot, never exposed to software. Physical memory extraction returns ciphertext, never readable data.
Note
Sensitive work runs in ephemeral confidential-mode sessions, adding a second layer of runtime protection on top of memory encryption.
Stops
  • Cold boot / DMA
  • Data persistence

06 /Least privilege

Protects
All work within permission and action scopes. Controls include role-based access and row-level database isolation. Administrative access requires two-person authorisation with split credentials.
Note
Behavioural anomaly detection look for slow-exfiltration attempts that threshold-based alerts miss.
Stops
  • Insider access

07 /Signed updates

Protects
Updates are signed at origin and verified before installation, with signing keys kept separate from deployment credentials, using an auditable transfer.
Note
If verified updates misbehave, authenticity checks allow for rollbacks and a clear recovery path.
Stops
  • Update injection
  • Supply-chain risk
02Ownership boundary

Compare local ownership with cloud access

The same documents, memory and models create a different security posture depending on where they are put to work.

Documents, memory and models inside your environment. Laminated document plates, a layered institutional memory sculpture and a finned model module stand together on one milled plinth. A continuous inlaid channel runs around all three, marking your environment.
  1. Myrstack

    Knowledge stays with you.

    Documents, conversations and decisions turn into your institutional memory.

  2. Myrstack

    Models run on your grounds.

    Local requests are processed inside your environment, without external cloud exposures.

  3. Myrstack

    Your capability grows.

    You keep building, Myrstack keeps updating and upgrading the tech.

03Agentic threat surface

Defending against inside and outside threats

Myrstack’s security model accounts for both the physical boundary and the additional threat surface introduced by AI systems.

Threat class / public design response AI layer
01

Prompt injection and intent manipulation

Response

Constrained roles, validated inputs and least-privileged access to tools.

02

Memory poisoning

Response

Validated writes, session isolation and authenticated access to persistent memory.

03

Privilege misuse

Response

Granular permissions, bounded delegation and checks at execution.

04

Unsafe output or code execution

Response

Controlled output handling, sandboxed execution and restricted access to critical resources.

05

Rogue or compromised agents

Response

Narrow roles, enforced execution boundaries, traceability and per-agent testing.

06

Runaway loops and resource exhaustion

Response

Limits, monitoring, containment and recovery paths.

04Compliance posture

Compliance by elimination, not by mitigation

Vendors try to manage user risk and obligations. That is mitigation. When data physically cannot leave your building, it removes risk to begin with.

Mitigation

Manage risk
  • Data-processing agreements.
  • Audit the subprocessor chain.
  • Justify cross-border transfers under shifting adequacy rules.
  • Insure against a provider compromise you cannot rule out.

Workarounds for containing risk to manage obligations.

Elimination

Remove risk
  • No data transfer to assess.
  • No subprocessor chain to audit.
  • Technology supplier, not data processor.
  • No adequacy rules, no standard clauses.

Remove conditions that create risk and obligation.

Confidential