diff --git a/secretstores/toolshed-session-key.yaml b/secretstores/toolshed-session-key.yaml
new file mode 100644
index 0000000..ac9cb32
--- /dev/null
+++ b/secretstores/toolshed-session-key.yaml
@@ -0,0 +1,40 @@
+# The Ed25519 private key api signs session tokens with.
+#
+# Only api gets this. The gateway is given the PUBLIC half instead, in plain
+# Helm values, and that asymmetry is the point: the gateway terminates traffic
+# for every deployed app, so it is the most exposed service in the system, and
+# holding only a verification key means compromising it does not let anyone
+# forge a session for anyone.
+#
+# Generate the pair with `make keygen` in the toolshed repo. It prints both
+# halves. They must be installed together — a private key here that does not
+# match the public key in the gateway's values means every session api issues
+# is rejected by the gateway, and every app redirects to login forever:
+#
+#   kubectl -n vault exec -i vault-0 -- sh -lc '
+#     vault login <root-token> >/dev/null &&
+#     vault kv put secret/toolshed/session private_key=<SESSION_PRIVATE_KEY>'
+#
+# then put the matching SESSION_PUBLIC_KEY into
+# devops-helm-charts/values/toolshed/toolshed/values.yaml and sync toolshed.
+#
+# Rotating the key invalidates every live session at once, which is the
+# intended behaviour for a key compromise and a rude surprise otherwise.
+apiVersion: external-secrets.io/v1
+kind: ExternalSecret
+metadata:
+  name: toolshed-session-key
+  namespace: toolshed
+spec:
+  refreshInterval: 1h
+  secretStoreRef:
+    name: vault-backend
+    kind: ClusterSecretStore
+  target:
+    name: toolshed-session-key
+    creationPolicy: Owner
+  data:
+    - secretKey: private_key
+      remoteRef:
+        key: toolshed/session
+        property: private_key