I do not place a workload by asking which server has room. I start with the data: how sensitive it is, whether the service must be public, and what an attacker could reach if that one workload were compromised.

That produces three roles. The diagram on the Lab page is deliberately abstract. The rules are more useful than a public inventory of machines and addresses.

Tier 1: sensitive processing stays on-premises

The first tier accepts no inbound connection from the public internet. Personal data and sensitive client processing stay there. A public service cannot simply reach back into it.

Isolation becomes physical when the data calls for it: separate system containers, filesystems, processes, and no shared client runtime. An outbound encrypted tunnel can retrieve narrowly scoped inputs or deliver a result, but it does not turn the private tier into a public server.

The constraint is intentional. If exposing a feature requires opening the private network, the feature belongs somewhere else.

Tier 2: public services live on the dedicated tier

The second tier carries public HTTP traffic, OAuth callbacks, and lower-sensitivity services that need predictable resources. These workloads can be multi-tenant when their data and threat model allow logical separation.

They still do not get a path into the private tier. Public applications expose only what the edge needs and keep secrets scoped to the service that uses them. The tier is allowed to be reachable. It is not allowed to become a bridge back home.

Tier 3: the edge holds keys, not data

Some external systems accept connections only from a fixed, allowlisted address. A small edge role provides that stable egress point.

Its job is narrow: hold revocable, low-privilege, preferably read-only keys and pull a defined result. It does not store client datasets or become a second application platform. If it is compromised, rotating a key should close the path.

This tier exists because a network requirement should not force sensitive data onto a public box.

Physical and logical isolation solve different problems

One container per sensitive client costs more maintenance but provides a clear process, filesystem, and network boundary. A multi-tenant service is more efficient for many lower-sensitivity workloads, provided every record and secret is scoped by client and the application enforces that boundary.

Profiles inside an agent are useful for separating contexts. They are not a security boundary between clients when they share the same user and runtime. I do not use a convenient application-level profile where the data requires a separate system.

The LLM never gets the keys

The same doctrine applies inside AI-assisted services. The model produces text: a draft, classification, or extraction. Deterministic code owns credentials, validates the requested operation, and performs it after the required approval.

Prompt injection can then produce a bad draft, but it cannot directly use a token, open a shell, or call a privileged endpoint. An allowlist defines the few things the service can do. I do not rely on a list of forbidden actions that will always be incomplete.

Denied paths define the architecture

  • A public compromise cannot open an inbound route to the private network.
  • The edge cannot leak a dataset it never held.
  • One sensitive client does not share a runtime with another.
  • An LLM cannot exercise a permission it never receives.

The setup will change. Hardware, providers, and applications always do. These constraints can stay stable while the systems underneath them are replaced.