What leaves the building, and what does not.

1 Scope of this document

An Allod deployment is a single compute node in a locked rack, installed in the customer's own facility, running the Allod serving platform and one or more task-specific open-weight models. This document covers that node, the network boundary around it, the channel by which software reaches it, and the data Allod as a vendor receives. It does not cover the customer's own network, identity provider, or physical facility, which remain under the customer's control and in the customer's assessment scope.

Allod operates no multi-tenant inference service. There is no Allod cloud that customer data passes through, because there is no Allod cloud.

2 Deployment topology

The node sits on an isolated VLAN provisioned by the customer. It has two logical interfaces:

• Service interface. Reachable from the customer systems that call the workflow, over mTLS or an OIDC-protected HTTP API, whichever the customer's platform team prefers. Access control is the customer's — we authenticate against the customer's identity provider and do not maintain a user directory.
• Update interface. Egress-only, to a single fixed hostname over TLS on 443. See §4 and §5.

There is no management plane reachable from outside the customer's network. There is no remote shell, no reverse tunnel, no jump host on our side, and no VPN from our office into the node. Allod engineers who need to touch the node either sit at the customer's site or use the customer's own remote access, under the customer's controls and logging.

3 Data residency

Prompts, retrieved context, model outputs, human corrections, derived training datasets, adapter checkpoints, and evaluation results are written to encrypted local storage on the node. They are not replicated, backed up, or mirrored to any destination outside the customer's facility by the platform. If the customer wants backups, they are configured to a customer-controlled target inside the customer's environment.

Storage is encrypted at rest with keys held in the node's hardware security module. A drive removed from the rack is not readable.

Data residency is therefore not a contractual jurisdiction question. The data is in the room the customer specified, on hardware the customer can walk up to.

4 Egress model

The node initiates all connections. Nothing outside the customer's network can initiate a connection to it, because no inbound route or listener is exposed beyond the service interface described in §2, which is reachable only from inside the customer's network.

Two flows cross the boundary outward, and only two:

• Artifact pull. A scheduled outbound HTTPS GET to one fixed hostname, checking for and downloading signed software artifacts. Request bodies are empty; the request carries a deployment identifier and the current version set.
• Metrics push. A periodic outbound HTTPS POST of a fixed, published, numeric-only metrics schema. Enumerated in §9. Rejected by the platform if any field falls outside the schema.

Both are to the same hostname and can be constrained by the customer's egress proxy to that hostname, that port, and those two paths. Customers commonly do exactly that and we recommend it.

Air-gapped mode. Both flows can be disabled at install. In that configuration the node has no route off the VLAN at all. Artifacts arrive on write-once physical media and are verified as in §5; metrics are written to a local file the customer may retrieve or ignore. Everything else — including the full nightly training loop — works unchanged, because none of it ever depended on the network.

5 Update delivery and verification

Platform releases, base model updates, and security patches are distributed as signed artifacts. Each artifact is a content- addressed bundle with a detached signature over its digest.

1. The node downloads the artifact and its signature to a staging area that is not on the serving path.
2. It verifies the signature against an Allod public key pinned in the node's HSM at install time. The pinned key is fixed at install; rotating it requires a physical, on-site procedure with the customer present. A remote actor cannot introduce a new trusted key.
3. It verifies the digest, then verifies that the artifact's declared version is greater than the installed version. Rollback to an older signed version is possible but requires explicit local action; it cannot be triggered by the update channel.
4. A verified artifact is staged and reported as available. It is not applied automatically. Application is a local action, gated by the customer's change window and approval, with a documented rollback.
5. Verification failure discards the artifact, raises a fault code, and does not retry that artifact.

Software bills of materials are published for each release, and the artifact digests are available so a customer can verify that what their node received is what we published.

6 Key handling

• Artifact signing key. Held by Allod in an HSM. Offline root, short-lived signing intermediates. Only the public half exists on the node, and only pinned.
• Storage encryption keys. Generated on the node at install, sealed in the node's HSM, never exported and never transmitted. Allod does not hold a copy and cannot recover data from a node's drives.
• Service TLS. Certificates for the service interface are issued from the customer's own CA. We do not need to be in that trust chain.
• Weights. Not encrypted with any key we control. On export at end of term the customer receives plaintext safetensors. There is no wrapping key, no license server, and no entitlement check in the serving runtime.

7 Tenancy and isolation

Single tenant, physically. One customer per node; one customer per rack. No workload from another customer runs on the hardware, and there is no shared control plane through which one deployment could observe another. The failure modes that dominate multi-tenant risk assessments — noisy neighbours, side channels, cross-tenant IAM misconfiguration, a shared vector index — do not have an analogue here.

Within a node, each deployed workflow runs in its own container with its own storage namespace and its own adapter set. A workflow cannot read another workflow's captured data unless the customer explicitly configures it to.

8 Audit logging

The platform writes an append-only local audit log covering: inference requests (caller identity, timestamp, workflow, adapter version — not content, unless the customer turns content logging on); every capture event and its outcome label; every training run, its input dataset digest, and its result; every gate evaluation, its score, and its pass/fail; every adapter promotion or rollback and who authorized it; every artifact verification; and every administrative action on the node.

Logs are written in a documented JSON schema and shipped to the customer's SIEM by the customer's own collector. We do not receive them. Retention is the customer's policy, and the log is the customer's record: an examiner asking "which model version produced this memo, and what was it trained on" gets an answer from the customer's own systems without contacting us.

9 What Allod can and cannot see

This is the table most reviewers turn to first, so it is exhaustive rather than illustrative. The right-hand column is what leaves the customer's building over the metrics flow described in §4.

The enforcement is structural, not procedural. Content fields do not exist in the metrics schema, the metrics client rejects anything outside the schema before it is serialized, and the customer's egress proxy sees the whole payload if they want to inspect it. We encourage customers to log and read that traffic.

10 Physical security

The rack ships with locking front and rear doors and tamper-evident seals; key control is the customer's. The customer's own facility controls — badge access, camera coverage, visitor escort — are the controls that apply, which is generally the point. Allod personnel on site are escorted under the customer's normal vendor procedure.

At end of term we collect the hardware. Drives are cryptographically erased on site, in front of the customer, before the rack leaves, and the customer signs the certificate. Customers who prefer to retain and physically destroy the drives may do so; we price that in.

11 Vulnerability handling and incident response

We publish an SBOM per release and monitor the components in it. Security fixes are released as signed artifacts through the normal channel with a severity label, and we notify named contacts directly for anything we rate high or critical rather than relying on the customer noticing a staged artifact.

Because we hold no customer data, an incident on our side cannot be a breach of customer data. It can be a supply-chain incident, which is the risk that actually matters here, and it is why the signing key is offline and the trusted key on the node cannot be replaced remotely. If our signing infrastructure were compromised we would say so publicly and immediately, and the remediation would be an on-site key rotation at every deployment.

Report a vulnerability to security@allod.us. We acknowledge within one business day and we do not send legal threats to researchers.

12 Personnel and access

Every Allod employee with production responsibility is background checked to the standard the customer's vertical requires, and we will run the customer's own screening if they prefer. Access to signing infrastructure is limited to named individuals, requires hardware tokens, and is quorum-based: no single person can sign a release.

No Allod employee has standing access to a customer node. Access is per-visit, escorted, and logged by the customer.

13 What we do not have yet

Being straight about this saves everyone a round trip. As of the revision date above, Allod holds no completed SOC 2 Type II, ISO 27001, HITRUST, or FedRAMP authorization. We are an early company and those take time and revenue we have not spent yet.

What we would put to a reviewer is that the architecture is doing the work those certifications are usually proxies for. The questions a SOC 2 report answers about a vendor — how they segregate tenants, how they control access to your data, how they handle your data at rest, what their subprocessors do with it — do not have a risky answer here, because the vendor does not hold the data. What remains in scope is our software supply chain, and §5, §6 and §11 are the controls on that. Ask us hard questions about those specifically.

We will pursue SOC 2 Type II, and we will date it here when it exists rather than say "in progress" indefinitely.

14 Contact

Architecture and risk review: security@allod.us. A named engineer will answer, and will get on a call with your third-party risk team without a sales person on the line.

Book a deployment call