# The Relay Pattern: Encryption Says Who May Read, Signing Says Who Acted, And Ordering Comes From Data Dependency Rather Than From Either

**version** v0.33.59
**date** 16 August 2026
**from** Human (project lead)
**to** Engineering, Architecture, AppSec

**type** Architecture brief

*Fourth of 16 August. A design pattern for publication. Contains one precision that matters, because conflating three mechanisms would leave a hole in a design that appeared to be closed. Platform behaviour is grounded and cited.*

---

## What This Is

A deployment pattern for several agents collaborating through an encrypted vault, with per-agent keys, and one distinction that decides whether the security argument holds: **the pattern is a deployment shape for something the corpus specified in July, where a distributed vault architecture with authorisation by keys and sequencing enforced by keys was described before any of it was built, and the blackboard model of 2 August established the collaboration shape, so what is new here is the cluster topology and the per-agent key layer rather than the architecture; the memorable claim in the memo is that this achieves authorisation by being able to read the message, which is close and needs splitting into three mechanisms that do different jobs, because encrypting to a recipient controls who may read, signing controls who is accountable for a write, and neither of those controls ordering, since what actually prevents an agent acting early is that its input does not exist until the previous agent produces it, which is a data dependency rather than a cryptographic property; that distinction matters because a design believing encryption enforces sequence will not add the thing that does, and the corpus already has it, in the form of a transaction log where each message carries the hash of its predecessor, so the chain is verifiable rather than merely likely; the honest boundary should be published with the pattern, since it constrains which agent can act at which step and does not constrain what an authorised agent does within its own step, which is the confused deputy boundary the corpus keeps arriving at; the orchestrator is the substrate and not the architecture, because the described arrangement is one service and several clients that happens to run on a cluster, and saying so makes the pattern portable to plain machines and makes the demonstration reproducible by anybody; the practical gap is where agent private keys live, and the default answer is wrong, because platform secrets are base64-encoded rather than encrypted in the backing store unless encryption at rest is explicitly configured, which the platform's own documentation states plainly; and two things the memo offers as conveniences are security properties worth reframing, since a shallow clone limits what an agent holds locally and needing no version control client or shell access on each machine is a privileges argument rather than an installation one.** It is the fourth document of 16 August (cross-ref: the v0.33.49 distributed vault brief, the v0.33.55 vaults-as-substrate brief, the v0.33.56 kernel state machine brief, the v0.33.59 comparison pages brief, and the v0.33.56 plugins brief). New contributions: **the three mechanisms separated, ordering located in data dependency with the hash chain as the enforcement, the honest boundary stated, the orchestrator demoted to substrate, the key storage gap identified, and two conveniences reframed as security properties.**

## This Is A Deployment Shape For Something Already Specified

Worth establishing, because it means the pattern can be published with confidence rather than as a proposal.

The distributed vault architecture of 17 July described registers of registers, messages as transformations over a transaction log, and authorisation by keys with sequencing enforced by them. The substrate brief of 2 August established the collaboration model: agents with distinct responsibilities communicating asynchronously through encrypted folders, with none addressing another directly, and identified that the published literature leaves authorisation and audit of shared state as open questions which an encrypted versioned vault answers by construction.

**What this memo adds is the topology and the per-agent key layer**, which is exactly the part that was specified and not yet drawn. So this is ready to be a published pattern rather than an idea.

## The Setup

The memo's arrangement, stated plainly for the diagram.

```
   ONE NODE                          AGENT NODES
   the API in front of the vault     python + the client, nothing else
        |                                 |
        +---------------------------------+
                    HTTP

   IN THE VAULT
     agents/one/inbox/      each agent has an inbox
     agents/two/inbox/      by convention
     agents/three/inbox/
     agents/four/inbox/
```

Two access modes, both already present. A full clone, where commits show what each agent did. Or a shallow clone that fetches only what is wanted. The memo notes the second as a convenience and it is more than that; see below.

## Three Mechanisms, Not One

The memorable claim needs splitting, and this is the most important thing in this brief. The project lead: **"we're doing authorisation by being able to read the message."**

That is elegant and it bundles three separate mechanisms which do different jobs and have different failure modes.

| Mechanism | Question it answers | What it does not do |
|---|---|---|
| **Encrypt to the recipient** | Who may read this | Does not say who wrote it, or when it may be acted on |
| **Sign with the sender** | Who is accountable for this | Does not restrict who reads it |
| **Data dependency** | When may this be acted on | Nothing, unless the dependency is verifiable |

**Encryption is confidentiality and a form of access control.** A message sealed to agent three can be read by agent three and nobody else, which is a real and useful property: agent two may be unable to read the message that started the chain, and that is the supply-chain property the memo wants.

**Signing is attribution and integrity**, and it is what makes the memo's data integrity claim true. The project lead: **"you have data integrity now, because only the right agent can actually make the changes."** That holds because of the signature, not because of the encryption.

**And ordering is neither of them.**

## Ordering Comes From Data Dependency

The precision that matters, because a design that believes encryption enforces sequence will not add the thing that does.

The memo's claim. The project lead: **"we can then make sure that, for example, agents cannot read things out of order."**

**Encryption does not prevent an agent acting out of order.** A message sealed to agent three can be opened by agent three whenever it appears. What actually prevents agent three acting early is simpler: **its input does not exist until agent two produces it.**

That is a data dependency, and it is genuinely effective. It is also invisible in the design if the mechanism is described as encryption, which risks somebody later adding a convenience, such as pre-seeding all messages at the start, that silently removes the ordering while leaving the encryption intact.

**The corpus already has the reinforcement.** The July architecture described messages as transformations over a transaction log. Give each message the **hash of its predecessor**, and the chain becomes verifiable rather than merely likely: agent three can check that what it received actually followed what agent two received, and a gap or a reorder is detectable rather than assumed.

So the pattern has three layers, and the pattern page should show all three:

```
   confidentiality   sealed to the recipient's public key
   attribution       signed with the sender's private key
   sequence          input produced by the previous step,
                     with each message carrying the hash of the last
```

## The Honest Boundary

Worth publishing alongside the pattern, because a pattern page that states its limits is the one people trust, and because the corpus keeps arriving at this same edge.

**What the pattern gives.** Only the intended agent can read a step. Only the intended agent can produce a valid signed output for it. A third party cannot inject a step, reorder the chain undetected, or read a step not addressed to them. The vault holds a complete, attributable record.

**What it does not give.** It constrains **which agent may act at which step**. It does not constrain **what that agent does within its step**. A compromised agent three can read its input, do something wrong, sign it correctly and pass it on, and every cryptographic check will pass.

That is the confused deputy boundary named on 6 August, and it is not a flaw in this design; it is where this control ends and another begins. The corpus already has the adjacent piece: the kernel state machine of 6 August constrains which operations may occur in what order, and capability grants constrain what a component may touch at all. **The relay pattern is the third member of that set**, and the pattern page should say so rather than implying it is complete on its own.

One smaller boundary worth noting: an agent that keeps its plaintext can re-emit. Replay protection needs a nonce or a sequence number in the signed payload, which is cheap and should be in the pattern rather than discovered later.

## The Orchestrator Is The Substrate, Not The Architecture

Worth saying because it makes the pattern more useful, not less.

The described arrangement is **one service and several clients talking to it over HTTP**. That is not a cluster-specific pattern; it works on plain machines, on one machine with several processes, or on ephemeral compute. What the orchestrator adds is scheduling, network policy restricting which workloads may reach the service, and a place to put secrets, which is the subject of the next section.

So the pattern should be published as **agents, a vault, and per-agent keys**, with the cluster as one deployment option among several. Three benefits follow: a reader without a cluster can still use it, the demonstration is reproducible on a laptop, and the pattern does not date when orchestration fashions change.

The memo's own stated advantage supports this. The project lead: **"you don't have to install git and SSH into every single machine, you just need a bit of Python and sgit on each of the machines."**

## Two Conveniences That Are Security Properties

Both are presented in the memo as practical benefits and both are worth reframing, because they are the strongest parts of the pattern.

**Not needing a version control client and shell access on every machine is a privileges argument.** An SSH key to a repository server is typically a broad credential granting access to whole repositories, and shell access is broader still. What replaces it here is a read key or a write channel scoped to a vault. That is the privileges-granted dimension identified earlier today as the column that actually differentiates: same task, materially different access granted.

**A shallow clone is least authority, not just less bandwidth.** The memo offers it as a way to fetch only what you want. It is also the difference between an agent holding the entire collaboration history locally and holding only its own inbox. If that agent is compromised, the difference is what the attacker gets. **So the pattern should recommend shallow by default and full clone as the exception**, with the reasoning stated.

## Where Do The Private Keys Live?

The practical gap in the memo, and the default answer is wrong.

The whole security argument rests on each agent's private key staying private. The obvious place to put it in a cluster is the platform's secret object, and that is not what it appears to be.

**Platform secrets are base64-encoded, not encrypted, in the backing store unless encryption at rest is explicitly configured.** The platform's own documentation is direct: if the encryption provider configuration is not specified, encryption at rest is not enabled, and the default provider stores plain-text representations with no confidentiality protection. Practitioner guidance is blunter, noting that anyone with access to the backing store, a snapshot, or an unprotected backup can recover every secret in the cluster, and that base64 is an encoding for transport rather than a protection.

So the pattern must state the requirement rather than assume it. Three options, in increasing order of separation:

| Approach | Property |
|---|---|
| Platform secret, **with encryption at rest configured** | The minimum. Requires an explicit configuration and key rotation |
| An external key service | The key lives outside the cluster, which is the recommended production shape |
| **Derived at start from a passphrase, held in memory** | Nothing at rest to steal, at the cost of an unattended restart |

The third is the most consistent with the product's own posture and is the least operationally convenient, which is exactly the trade the pattern page should present rather than resolve.

Two further notes for the page. Access control on who may read the secret matters as much as encryption, since a workload identity able to read it gets the plaintext. And the public keys are publishable by definition, so only the private half needs any of this.

## Naming Clones After Agents

A small point in the memo with a consequence worth stating. The project lead: **"every clone has a public key, already by design, and if we name those clones with the name of the agent, we share that public key."**

That gives an identity layer for free: the clone name is the agent name, its public key is discoverable, and the private key never leaves. **Which means key distribution has no separate mechanism** and the vault is its own directory.

The caution is the corresponding one: names become identities, so who may create a clone with a given name is a privileged decision. If any party can register a clone called agent three and publish a public key for it, the chain can be redirected. The pattern needs a stated answer for who authorises a name, even if that answer is that it is done once by an operator at setup.

## Publishing It

The memo's ambition for the format is right and achievable. The project lead: **"we should kind of do this like the big providers do, where every major technology vendor has these sort of knowledge-base articles, and case study with architecture diagrams."**

Four things make one of these pages work, and the site already has the machinery for all of them: a **diagram** the reader can follow, the **sequence** stated as a numbered flow, a **worked instance** with real names and a running vault, and the **limits** stated plainly.

The last is what distinguishes it from vendor material, and it is the site's established strength. A pattern page that names what it does not protect against is more useful than one that does not, and it invites the peer review the comparison work is also aiming for.

One suggestion on scope: publish **the simple version first**, meaning agents with inboxes in a shared vault and no per-agent keys. It is the version most readers can use, it is already true, and the key layer is then a second page that builds on it rather than a barrier to understanding the first.

## What This Does Not Try To Be

- **Not one mechanism.** Confidentiality, attribution and sequence are three, with different failure modes.
- **Not ordering by encryption.** Ordering comes from data dependency, reinforced by a hash chain.
- **Not a complete control.** It constrains which agent acts when, not what an authorised agent does.
- **Not cluster-specific.** The orchestrator is a deployment option, and the pattern runs anywhere.
- **Not safe with default secret storage.** Encryption at rest must be configured explicitly, or keys held another way.

## Honest Tensions

| Tension | Note |
|---------|------|
| Encryption as access control | It genuinely limits reading and it is easy to describe in a way that implies more than it delivers |
| Data dependency as ordering | It works and it is invisible, so a later convenience could remove it without anybody noticing |
| Per-agent keys | Strong attribution and a key management burden that grows with every agent added |
| Shallow clone by default | Least authority and it means an agent cannot see the history it might need to debug |
| Names as identities | Free key distribution and a new privileged decision about who may claim a name |
| Publishing the pattern | Peer review is the goal and a pattern page is also a map of the attack surface |

## Open Questions

| Question | Notes |
|----------|-------|
| Does each message carry the previous hash? | It should, since that is what makes the sequence verifiable rather than assumed |
| How is replay prevented? | A nonce or sequence number in the signed payload, cheap and easily forgotten |
| Where do private keys live in the reference deployment? | The pattern page should show one and name the alternatives |
| Who may create a clone with a given name? | Names are identities, so this is a privileged decision needing a stated answer |
| Shallow or full clone by default? | Shallow, with the reasoning published, and an exception path for debugging |
| What happens when an agent is unreachable? | The chain stalls, and a stalled chain has no owner, which is the blackboard pattern's known failure |
| Simple version first? | Inboxes without per-agent keys is usable today and is the better first page |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 17 Jul | `v0.33.49__arch-brief__sg-send-fractal-distributed-vault-architecture-registers-of-registers-messages-as-graph-transformations-transaction-log-pki-authorization.md` | Messages over a transaction log with authorisation by keys, specified before this deployment shape existed |
| 2 Aug | `v0.33.55__arch-brief__sg-send-vaults-as-substrate-asynchronous-agent-collaboration-through-encrypted-folders.md` | The collaboration model this deploys, and the stalled-message failure mode |
| 6 Aug | `v0.33.56__arch-brief__sg-send-state-machine-in-the-vault-kernel-reference-monitor-write-is-the-attestation.md` | Sequence constrained at the kernel, which is the adjacent control this pattern does not replace |
| 6 Aug | `v0.33.56__arch-brief__sg-send-plugins-are-capability-grants-ambient-authority-is-the-injection-root-cause-instrument-before-enforcing.md` | The confused deputy boundary this pattern also reaches |
| 16 Aug | `v0.33.59__strategy-brief__sgit-comparison-pages-as-reproducible-tests-privileges-is-the-missing-column.md` | Privileges granted as the differentiating dimension, which the no-SSH point instantiates |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | This is a deployment shape for an architecture the corpus specified in July, so it is ready to publish |
| 2 | Authorisation by being able to read bundles three mechanisms that fail differently |
| 3 | Encryption controls who may read; signing controls who is accountable |
| 4 | Ordering comes from data dependency: agent three's input does not exist until agent two makes it |
| 5 | A later convenience could remove that dependency while leaving the encryption intact |
| 6 | Each message should carry the hash of its predecessor, making the sequence verifiable |
| 7 | The pattern constrains which agent acts when, and not what an authorised agent does within its step |
| 8 | Replay needs a nonce or sequence number in the signed payload |
| 9 | The orchestrator is a deployment option; the pattern runs on plain machines and is reproducible on a laptop |
| 10 | Needing no version control client or shell access is a privileges argument, not an installation one |
| 11 | A shallow clone is least authority, so it should be the default with the reasoning stated |
| 12 | Platform secrets are base64-encoded rather than encrypted unless encryption at rest is explicitly configured |

---

## Sources

- Platform documentation stating that if the encryption provider configuration is not specified then encryption at rest is not enabled, and that the default identity provider stores plain-text representations of resources with no confidentiality protection: https://kubernetes.io/docs/tasks/administer-cluster/decrypt-data
- Practitioner guidance that secrets are stored as base64-encoded text in the backing store rather than encrypted by default, that anyone with access to the store, a snapshot or an exposed backup can recover every secret, that base64 is an encoding for transport rather than a protection, and that encryption must be explicitly enabled through an encryption configuration and preferably backed by a key management service: https://www.cloudoptimo.com/blog/kubernetes-secrets-management-in-2026-best-practices/ and https://oneuptime.com/blog/post/2026-02-09-encrypt-kubernetes-secrets-rest-encryption-config/view
- The note that access control on reading the secret matters alongside encryption, since a workload identity able to read it obtains the plaintext, and the recommendation to prefer an external key service so the encryption key sits outside the cluster: https://dev.to/pjanderson/kubernetes-secrets-are-just-base64-not-encryption-heres-what-that-actually-means-35hi and https://www.plural.sh/blog/a-practical-guide-to-kubernetes-encryption-at-rest/

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).