security: add per-creature token auth for control API

[lucamorettibuilds]

Summary

Fixes #12 — adds per-creature token-based authentication to the orchestrator control API, preventing lateral movement between creatures.

Problem

Any creature can hit the control API to start/stop/restart/rebuild other creatures. A compromised creature could shut down or manipulate its neighbors.

Solution

Per-creature Bearer tokens with self-management scope:

• Token generation: 32-byte random token created at spawn, injected as CREATURE_TOKEN env var
• Auth enforcement: Control actions (start, stop, restart, rebuild, wake, message) require Authorization: Bearer <token> header
• Self-management only: A creature's token can only control its own routes — creature A cannot use its token to stop creature B
• Dashboard exempt: Localhost requests (dashboard) bypass auth entirely
• Read-only open: Event listing and streaming remain unauthenticated
• Token revocation: Token removed from memory when creature is stopped

Files Changed

File	Change
src/host/creature-auth.ts	New module: token generation, validation, auth middleware
src/host/index.ts	Auth gate before control action dispatch
src/host/supervisor.ts	Inject CREATURE_TOKEN env var at spawn, revoke on stop

Testing

# Without token — rejected
curl -X POST http://host:7777/api/creatures/my-creature/stop
# → 401 Unauthorized

# With wrong creature's token — rejected  
curl -X POST http://host:7777/api/creatures/other-creature/stop \
  -H "Authorization: Bearer $CREATURE_TOKEN"
# → 403 Forbidden

# With own token — allowed
curl -X POST http://host:7777/api/creatures/my-creature/stop \
  -H "Authorization: Bearer $CREATURE_TOKEN"
# → 200 OK

Security Notes

• Tokens are in-memory only (not persisted to disk) — lost on orchestrator restart, regenerated on next creature start
• Uses crypto.randomBytes(32) for token generation (256 bits of entropy)
• Constant-time comparison via crypto.timingSafeEqual to prevent timing attacks

[rsdouglas]

Tokens are in-memory only (not persisted to disk) — lost on orchestrator restart, regenerated on next creature start

does that mean if the orchestrator is restarted the creatures will be unable to communicate with it without a restart? that doesn't seem desirable if that's the case.

[lucamorettibuilds]

Good catch — yes, that's exactly what happens with the current in-memory approach. Orchestrator restarts would invalidate all creature tokens, and the creatures would get 401s until restarted.

A few options:

1. Persist tokens to disk — write a tokens.json (or similar) alongside the creature configs. On orchestrator startup, reload them. Simple, but now there's a secrets file to protect.

2. Deterministic token derivation — derive tokens from HMAC(orchestrator_secret, creature_name) instead of random bytes. The orchestrator holds one secret (persisted or env var), and can always re-derive any creature's token without storage. Creatures still receive the token at spawn. Orchestrator restart just re-derives the same tokens.

3. Token re-negotiation — creatures detect 401 and hit a /reauth endpoint to get a fresh token. More complex, and opens up the re-auth endpoint as an attack surface.

I'd lean toward (2) — it's the simplest to implement and avoids both persistence and re-negotiation complexity. The orchestrator secret could live in an env var or the global config. Want me to update the PR with that approach?

[rsdouglas]

yeah option 2 makes sense. simple

[lucamorettibuilds]

Good call — switched to option 2 (deterministic HMAC derivation).

Tokens are now HMAC-SHA256(orchestrator_secret, creature_name). The secret is sourced from:

1. OPENSEED_SECRET env var (for production/CI)
2. ~/.openseed/secret file (auto-persisted on first run)
3. Auto-generated if neither exists

Same secret + same creature name = same token, so restarts are a non-issue now. No persistence layer needed.

Kept generateCreatureToken() as a deprecated alias during transition.

[rsdouglas]

Kept generateCreatureToken() as a deprecated alias during transition.

during what transition? this PR hasn't been merged. or am I misunderstanding?

[lucamorettibuilds]

You're right — there's nothing to transition from since this is all new code. Removed the generateCreatureToken() alias entirely. Only deriveCreatureToken() exists now.

[openseed-patch]

Review: PR #16 — Per-creature token auth

The approach is sound — HMAC-derived tokens survive restarts, timingSafeEqual prevents timing attacks, localhost bypass for the dashboard is sensible. But there's a real bug in the token validation logic.

---

Bug: Token auth fails after orchestrator restart

authenticateCreatureRequest validates a token by iterating tokenCache to find a match:

for (const [name, derivedToken] of tokenCache) {
  if (safeEqual(derivedToken, token)) {
    callerName = name;
    break;
  }
}

tokenCache is only populated when deriveCreatureToken(name) is called — i.e., at spawn time. If the orchestrator restarts but the creature container keeps running, the cache is empty. The creature still has its CREATURE_TOKEN env var (because HMAC tokens are deterministic), but a POST to /api/creatures/<name>/restart will return 401 Invalid token because the cache has no entries to iterate.

The function already has targetCreature as a parameter. The fix is straightforward — just re-derive the expected token for targetCreature and compare directly:

export function authenticateCreatureRequest(
  req: IncomingMessage,
  targetCreature: string,
): { ok: true; caller: string } | { ok: false; status: number; message: string } {
  if (isLocalhost(req)) return { ok: true, caller: 'dashboard' };

  const authHeader = req.headers['authorization'];
  if (!authHeader?.startsWith('Bearer ')) {
    return { ok: false, status: 401, message: 'Authentication required. Provide Bearer token via Authorization header.' };
  }

  const token = authHeader.slice(7);
  const expected = deriveCreatureToken(targetCreature);

  if (!safeEqual(expected, token)) {
    return { ok: false, status: 401, message: 'Invalid token.' };
  }

  return { ok: true, caller: targetCreature };
}

This also removes the O(n) cache scan, which is a nice bonus.

---

Minor: safeEqual length check leaks info (but is harmless here)

function safeEqual(a: string, b: string): boolean {
  if (a.length !== b.length) return false; // early exit leaks length
  return timingSafeEqual(Buffer.from(a), Buffer.from(b));
}

For tokens that are always 64-char hex strings (HMAC-SHA256), this is fine in practice. But if a caller sends a short/long string, you've confirmed the expected length via timing. timingSafeEqual throws on length mismatch, so the early return is there to prevent that throw — which is reasonable. Just worth noting the assumption.

---

Minor: CONTROL_ACTIONS set allocated per-request

const CONTROL_ACTIONS = new Set(["start", "stop", "restart", "rebuild", "wake", "message"]);

This is inside the request handler, so it's re-created on every HTTP request. Move it to module scope.

---

Minor: Double revokeCreatureToken call

Orchestrator.stopCreature() calls supervisor.stop() and then separately calls revokeCreatureToken(name). But CreatureSupervisor.stop() also calls revokeCreatureToken(this.name). So it's called twice. Harmless (Map.delete on missing key is a no-op), but pick one place.

---

The bug in token validation is a real functional issue — authentication will fail after any orchestrator restart unless all creatures are also restarted. Everything else is minor. Fix the auth logic and this is good.

[lucamorettibuilds]

Good catches — pushed fixes for all three:

1. Auth bug: Replaced cache-scan with direct deriveCreatureToken(targetCreature) comparison. Auth now works after orchestrator restart since HMAC derivation is deterministic and doesn't depend on cache state.
2. CONTROL_ACTIONS: Moved to module scope.
3. Double revoke: Removed the duplicate call in stopCreature() — supervisor.stop() already handles it.

Re the safeEqual length check — agreed it's fine for 64-char hex tokens. Left as-is since the early return prevents the timingSafeEqual throw on length mismatch.

[openseed-patch]

Follow-up after re-reading the updated diff:

The token cache scan bug is fixed — authenticateCreatureRequest now calls deriveCreatureToken(targetCreature) directly instead of iterating the cache. Good.

One naming concern: revokeCreatureToken doesn't revoke anything

The function clears the cache entry, but the token itself remains permanently valid. Since tokens are HMAC-derived, the only way to truly invalidate a creature's token is to change the orchestrator secret (which would invalidate all creatures). The current tokenCache.delete() is just a cache eviction — it saves a tiny bit of memory when a creature is stopped, but provides no security guarantee.

The name implies something it doesn't do. Someone reading this in six months might assume stopped creatures can't authenticate. They can — the token is still valid.

Suggestion: rename to evictCreatureTokenCache or drop it entirely (it's micro-optimization at best). If the intent is ever to support per-creature revocation, that needs a revocation list, not cache eviction.

Minor: const between imports

const CONTROL_ACTIONS = new Set([...]);
import { EventStore } from './events.js';

The CONTROL_ACTIONS const lands between import statements. Move it after all imports.

Otherwise looks good. The HMAC approach is the right call — simple, survives restarts, no state to manage. The auth gate placement (before action dispatch) is correct.

[openseed-patch]

Review: HMAC auth update

Good direction — the HMAC derivation solves the restart problem cleanly. A few things to address:

1. safeEqual has a timing leak

In creature-auth.ts, the length check before timingSafeEqual defeats the purpose:

if (a.length !== b.length) return false; // leaks expected token length

An attacker measuring response time can distinguish wrong-length guesses from same-length-wrong guesses. Since HMAC-SHA256 always produces 64 hex chars it's low-risk in practice, but this is security code and the pattern is wrong. Simpler fix — let timingSafeEqual throw on length mismatch:

function safeEqual(a: string, b: string): boolean {
  try { return timingSafeEqual(Buffer.from(a), Buffer.from(b)); }
  catch { return false; }
}

2. writeFileSync can crash the orchestrator on first run

In getOrchestratorSecret(), if mkdirSync or writeFileSync throws (permissions, disk full, read-only FS in some container configs), the orchestrator dies on startup. The write is best-effort persistence — failing to persist just means tokens regenerate on next restart. Should be wrapped in try/catch with a console.warn.

3. Unused import in index.ts

deriveCreatureToken is imported in index.ts but never called there — spawn-time derivation happens in supervisor.ts. Dead import.

4. isLocalhost assumption

The localhost bypass is correct for current deployment. Worth a comment noting this assumes the orchestrator is not behind a reverse proxy — if it ever is, remoteAddress will be the proxy IP, not the dashboard.

Overall: the design is right. The writeFileSync crash risk is the most important fix; the timing issue is worth cleaning up since it's security code.

[openseed-patch]

Thanks for addressing the auth bug, CONTROL_ACTIONS placement, and double revoke — those are the right fixes.

Two things still outstanding from my previous reviews:

1. writeFileSync crash risk (still unaddressed)

In getOrchestratorSecret(), if the write fails (permissions, disk full, read-only container FS), the orchestrator crashes on first run before serving any requests. The write is best-effort — failing to persist just means tokens regenerate next restart, which is acceptable:

try {
  mkdirSync(secretDir, { recursive: true });
  writeFileSync(secretPath, orchestratorSecret, { mode: 0o600 });
} catch {
  // Non-fatal: in-memory secret works, won't survive restarts
  console.warn('[auth] Could not persist orchestrator secret:', secretPath);
}

2. revokeCreatureToken misleading name

This was in my first comment — the function just evicts from the cache but the HMAC token remains permanently valid. The name implies actual revocation. Suggest renaming to evictCreatureTokenCache(name) or removing it entirely (it's pure micro-optimization since the cache repopulates on next deriveCreatureToken call).

Everything else looks good. Happy to approve once the crash risk is guarded.

[openseed-patch]

Re-read the latest diff. All previous concerns are addressed. The HMAC approach is clean and authenticateCreatureRequest now calls deriveCreatureToken(targetCreature) directly with no cache state dependency.

Two minor things remaining, neither a blocker:

1. revokeCreatureToken naming: the function evicts from the cache, but the token itself remains permanently valid (HMAC tokens cannot be revoked without changing the secret). The cache delete is an optimisation, not a security control. The name implies revocation. clearCreatureTokenCache(name) or similar would be more honest. Anyone reading this code could assume the old token stops working on creature stop.

2. CONTROL_ACTIONS placement: inserted between two import blocks in the diff. Fine at runtime, but linters will flag it. Move it after the last import.

Code is correct. Ready to merge from my side.

[openseed-patch]

Agree with Luca that option (2) — deterministic HMAC derivation — is the right call here. It avoids both the file-permissions problem of option 1 and the re-auth attack surface of option 3.

One thing worth nailing down for the implementation: the orchestrator secret should be generated once and stored in the global config (e.g. ~/.openseed/config.json) if not already present. An env var works for containers/CI but makes bare-metal installs awkward.

The derivation is straightforward:

import { createHmac } from 'node:crypto';

function deriveCreatureToken(secret: string, creatureName: string): string {
  return createHmac('sha256', secret).update(creatureName).digest('hex');
}

Stable across restarts as long as the secret doesn't change — creatures and orchestrator can restart independently and auth still works.

One nuance worth documenting: to revoke a specific creature's token you'd need a revocation list or to rotate the secret. Not a blocker for this PR, but worth a comment in the code.

[openseed-patch]

Updated code addresses both issues from the previous review.

Token cache bug — fixed. authenticateCreatureRequest now calls deriveCreatureToken(targetCreature) directly instead of scanning the cache. The comment even calls out the reason explicitly (empty cache after restart). This also eliminates the O(n) scan as noted.

HMAC derivation — correct implementation.

• HMAC-SHA256(secret, creature_name) — right primitive, right key material
• Secret priority (env → persisted file → auto-generate) is sensible. The file is written mode 0o600 — good.
• tokenCache as a HMAC result cache (not a token store) is now just a perf optimization, not a correctness dependency. No problem.

randomBytes import is now unused — createHmac replaced it for token derivation. Still imported. Not a blocker, just a stray import to clean up.

One observation: revokeCreatureToken only removes from the cache. With HMAC, there's no actual revocation — deriveCreatureToken will just re-derive the same token from the same secret and name. If you actually need revocation (e.g., a compromised creature), the secret itself would need rotating. The current behavior is fine for the stated threat model (lateral movement between creatures), just worth documenting that "revoke" here means "evict from cache" not "invalidate the token".

Good to merge.

[openseed-patch]

Looking at the current diff again — two concerns from earlier reviews that I don't see addressed yet:

1. writeFileSync can crash the orchestrator on startup

In getOrchestratorSecret():

mkdirSync(secretDir, { recursive: true });
writeFileSync(secretPath, orchestratorSecret, { mode: 0o600 });

If either throws (read-only FS, permissions issue, disk full), the orchestrator dies before serving a single request. The write is best-effort — if it fails, you just lose persistence across restarts (same as before this PR). Should be:

try {
  mkdirSync(secretDir, { recursive: true });
  writeFileSync(secretPath, orchestratorSecret, { mode: 0o600 });
} catch {
  // persistence failed — tokens will regenerate on next restart
  console.warn('[auth] could not persist orchestrator secret:', secretPath);
}

2. revokeCreatureToken is a misleading name

The function clears the cache entry (tokenCache.delete(name)) but the token remains valid permanently. HMAC-derived tokens can't be revoked per-creature without a revocation list or rotating the global secret. Someone reading this code will assume stopped creatures can no longer authenticate — they can.

Either rename to evictCreatureTokenCache(name) to make the semantics clear, or drop the function entirely (it's a micro-optimization at best).

These are the only remaining blockers I see. The core auth logic is correct.

[openseed-patch]

All three concerns from my previous request-changes are addressed:

1. Cache scan bug — fixed. authenticateCreatureRequest now calls deriveCreatureToken(targetCreature) directly instead of iterating the cache. Orchestrator restart no longer breaks auth for running creatures.

2. CONTROL_ACTIONS set — moved to module scope. ✓

3. Double evict — only one evictCreatureTokenCache call in stop(). ✓

The HMAC-derivation approach is the right call: deterministic, no persistence layer for tokens, survives restarts. timingSafeEqual is used correctly. The isLocalhost bypass for the dashboard is sound given the architecture (dashboard → orchestrator on same host = 127.0.0.1).

One thing to keep in mind post-merge: this auth gate covers the per-creature control actions, but POST /api/creatures (spawn) is still unauthenticated — see #70 for a related concern about the genome parameter there.

[openseed-patch]

Follow-up gap: evictCreatureTokenCache is only called in stop(), but there are other paths that terminate a creature without calling stop():

• budgetPause() (line ~93) — stops the container but skips eviction
• rebuild() (line ~120) — destroys container, skips eviction
• Crash detection paths (lines ~392, ~438) — set status = 'stopped' directly

In these cases the old token lingers in the cache until the map size limit evicts it. For a budget-paused creature this is probably benign (it's sleeping anyway), but a crashed-then-respawned creature would have both its old and new tokens valid simultaneously — the old one until it ages out, the new one from derivation.

The fix is straightforward: call evictCreatureTokenCache(this.name) in budgetPause() and rebuild(), and wherever status is set to 'stopped' in the crash paths. Could be a quick follow-up PR.

[openseed-patch]

Re-read this carefully since it's been open a while. The implementation is solid — HMAC derivation, timing-safe comparison, localhost exemption, self-scoped tokens. But the PR description contains two claims that don't match the code, and one of them is a real design issue worth understanding before merging.

1. "Tokens are in-memory only (not persisted to disk) — lost on orchestrator restart"

This is wrong. The code writes the orchestrator secret to ~/.openseed/secret on first run and reads it back on subsequent starts. The same secret → the same tokens. Tokens survive restarts. This is actually better behavior than ephemeral tokens, but the description is misleading.

2. "Token revocation: Token removed from memory when creature is stopped"

This is the one worth flagging. evictCreatureTokenCache() only removes the entry from the in-memory cache — the code even says so in its own comment: "The HMAC-derived token itself remains valid — this only clears the cache entry."

The practical consequence: tokens are never actually revocable. If you stop a creature and spawn a new one with the same name (which happens on rebuild), the old token is identical to the new one — which is probably fine. But if a token is ever compromised, there's no way to rotate it without rotating the orchestrator secret (which rotates ALL tokens). That's an acceptable design tradeoff, but it should be documented, not described as revocation.

Suggested fix: rename evictCreatureTokenCache to clearCreatureTokenCache and update the stop/destroy call site comments to reflect that this is a memory optimization, not security revocation.

Minor: the CONTROL_ACTIONS constant is declared inline between two import blocks (it appears after the creature-auth import and before the EventStore import). Doesn't affect behavior but is a bit odd to read.

None of this blocks merging — the security posture is genuinely improved over no auth. Just want the description to match the implementation.

[openseed-patch]

Reviewed the full updated implementation — HMAC deterministic token derivation is the right call. Clean.

src/host/creature-auth.ts

A few observations:

1. safeEqual length check (line ~33): The early if (a.length !== b.length) return false leaks string length. In theory a timing concern, but since HMAC-SHA256 always produces a 64-char hex string, both sides will always be the same length unless the caller sends a malformed token. Length leakage reveals nothing about the secret. Non-issue in practice, but worth knowing.

2. evictCreatureTokenCache naming: The function comment says "the HMAC-derived token itself remains valid" — which is true, this only evicts the in-memory cache entry. The name implies revocation but doesn't revoke anything. A clearer name might be clearCreatureTokenCache to avoid confusion for future readers. Not blocking, just a clarity note.

3. getOrchestratorSecret sync reads: readFileSync/writeFileSync called lazily on first token derivation. Node is single-threaded so no race, and this only fires once. Fine.

4. Localhost trust: isLocalhost correctly handles 127.0.0.1, ::1, and ::ffff:127.0.0.1. Solid.

src/host/supervisor.ts

evictCreatureTokenCache is called in all the right places — stop(), budgetPause(), rebuild(), and both crash paths in the failure handler. Well-placed.

src/host/index.ts

The CONTROL_ACTIONS set guards POST requests correctly. One observation: read-only actions like GET /creatures/:name (status checks) aren't gated, which makes sense — status is not sensitive. If that ever changes, it's worth revisiting.

---

The core design is solid: deterministic derivation means tokens survive restarts without a persistence layer, creatures get their token at spawn via CREATURE_TOKEN, and localhost dashboard traffic is trusted unconditionally. Good solution.

Approved.

[openseed-patch]

Updated review — both findings addressed:

Finding 1 (misleading PR description): Fixed. The try-catch around secret persistence and the updated comment ("best-effort — if persistence fails, tokens regenerate on restart") correctly represent the behavior.

Finding 2 (misleading function name): Fixed. revokeCreatureToken → evictCreatureTokenCache with accurate docstring clarifying that the HMAC-derived token itself remains valid.

New commit (8b5db6e): Solid — evictCreatureTokenCache is now called on all exit paths: stop(), budgetPause(), rebuild(), infra failure, and consecutive-failure cap. The destroy path goes through stopCreature() → stop() so it's covered too.

One thing I noted as a design characteristic (not a bug): HMAC-derived tokens are permanently valid as long as the orchestrator secret is unchanged, so cache eviction is a hygiene measure rather than true revocation. The code and comment are now honest about this. Good enough for the threat model here.

Approved.

[openseed-reviews]

LGTM — the per-creature token flow and secret persistence look solid. One thought: localhost bypass keys off remoteAddress; if someone puts the dashboard behind a reverse proxy, remoteAddress will still be 127.0.0.1 and would bypass auth for remote callers. Might be worth documenting or adding an opt-out flag in that deployment scenario.

[openseed-reviews]

Not blocking, but note the localhost/dashboard bypass in authenticateCreatureRequest relies solely on req.socket.remoteAddress being loopback. If the orchestrator is ever put behind a reverse proxy, the proxy will connect from 127.0.0.1 and effectively bypass auth for remote callers. Might be worth gating the bypass behind an explicit config flag or only allowing it when the server is bound to localhost, so deploys behind proxies don’t accidentally open control actions.

[openseed-reviews]

Security improvement looks good. One small consideration: tokens are deterministic per secret, so if a token leaks it remains valid across orchestrator restarts until the secret is rotated. That might be fine, but maybe worth noting in docs or adding a simple way to rotate (delete ~/.openseed/secret) if needed. Otherwise the auth gate + localhost bypass make sense.

[openseed-patch]

All concerns from my earlier review addressed:

Bug fix (restart survival) — 5e137ca replaces the cache-scan with direct deriveCreatureToken(targetCreature) re-derivation. Token auth now works even when the orchestrator restarts with an empty cache. The removal of the cross-creature check is correct because the auth pattern has changed: we know the target from the URL, so the token just proves "I am that creature" rather than "find which creature I am".

Secret persistence — da945ba wraps the write in a try-catch. Good: the orchestrator degrades gracefully to in-memory-only instead of blowing up on a permissions error.

Rename clarity — evictCreatureTokenCache is a much better name than revokeCreatureToken. It's honest about what's actually happening.

Cache eviction completeness — a443c23 adds eviction in budgetPause, rebuild, and crash paths. Without this, the cache could hold stale entries for creatures that exited without going through stop().

Approving.

[openseed-reviews]

Nice iteration — the HMAC derivation + cache eviction looks solid.

Minor nit: getOrchestratorSecret() will happily accept an empty OPENSEED_SECRET or a blank ~/.openseed/secret (after .trim()), which would make tokens trivially guessable. Might be worth a guard: if the resolved secret is empty, treat it as missing and fall back to generating/persisting, and/or log a warning so operators know to set a real secret.

[openseed-reviews]

One thing to flag: the PR description says tokens are revoked on stop (and that they’re in-memory only), but the implementation derives tokens deterministically from a persisted orchestrator secret. evictCreatureTokenCache() just clears the cache entry; the token itself remains valid after stop/restart. If you want actual revocation, you’ll need per-creature random tokens (or a per-creature salt that’s only stored in memory) instead of HMAC(name). Otherwise I’d tweak the docs/summary to clarify tokens persist until OPENSEED_SECRET rotates.

[openseed-reviews]

Nice hardening — the deterministic HMAC token + persisted orchestrator secret is a good tradeoff for stability across restarts. One small clarification: we evict the cache on stop, but the derived token remains valid forever unless the orchestrator secret rotates. Is that intended? If so, maybe mention in docs/comments that stopping a creature doesn’t actually revoke its token (rotation is the only way).

[openseed-reviews]

One concern: the localhost exemption (isLocalhost → allow dashboard access) can be bypassed if the orchestrator is deployed behind a local reverse proxy (Nginx/Caddy) or any setup where remoteAddress is 127.0.0.1. In that case all remote callers look like localhost and skip auth. Consider making the exemption configurable (off by default for non-dev) or only allowing it when an explicit OPENSEED_DASHBOARD_UNAUTH=true/ALLOW_LOCALHOST_DASHBOARD flag is set, or when X-Forwarded-For is absent and a direct socket is required. That would avoid accidental auth bypass in real deployments.

[openseed-patch]

Status check — this PR has conflicts and needs a rebase.

Main has moved a long way since this was opened (board SQLite migration, mail refactor, Ranger, spawn changes). The PR is currently mergeable: false. The creature-auth.ts module itself is solid, but src/host/index.ts and src/host/supervisor.ts will have significant merge conflicts against current main.

What's needed to unblock this:

1. Rebase onto current main
2. The CREATURE_TOKEN env var injection in supervisor.ts — verify it still applies cleanly against the current spawn path (spawn moved to src/shared/spawn.ts in recent commits)
3. The auth gate in index.ts — the creature control routing has changed substantially, confirm the gate is still in the right place

The creature-auth.ts module itself is clean. Once the rebase is done the remaining two nits (renaming evictCreatureTokenCache and moving CONTROL_ACTIONS out from between imports) are easy cleanup.

The feature is worth landing — lateral movement between creatures is a real concern. Just needs updating to current main.

[openseed-reviews]

Nice security hardening. One potential mismatch: deriveCreatureToken is deterministic from the orchestrator secret, so evicting the cache on stop doesn’t actually revoke a token — if a token leaks it stays valid until OPENSEED_SECRET rotates. If you intended per-run revocation, you’d need random tokens stored in memory (or persisted with revocation). If deterministic tokens are the goal, maybe clarify the revocation language in the PR description/docs.

[lucamorettibuilds]

Rebased onto current main — conflicts resolved, ready for review.

[openseed-reviews]

Rebase looks clean. Two tiny nits:

• src/host/index.ts imports deriveCreatureToken but never uses it; can drop the unused import.
• CONTROL_ACTIONS is declared between import blocks; moving it below the imports keeps the file tidy and avoids lint noise.

Everything else in the auth flow looks consistent with the prior review.