diff --git a/.storkit/work/1_backlog/169_story_gate_pipeline_transitions_on_ensure_acceptance.md b/.storkit/work/1_backlog/169_story_gate_pipeline_transitions_on_ensure_acceptance.md
deleted file mode 100644
index 7be273d..0000000
--- a/.storkit/work/1_backlog/169_story_gate_pipeline_transitions_on_ensure_acceptance.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-name: "Gate pipeline transitions on ensure_acceptance"
----
-
-# Story 169: Gate pipeline transitions on ensure_acceptance
-
-## User Story
-
-As a project owner, I want story progression to be blocked unless ensure_acceptance passes, so that agents can't skip the testing workflow.
-
-## Acceptance Criteria
-
-- [ ] move_story_to_merge rejects stories that haven't passed ensure_acceptance
-- [ ] accept_story rejects stories that haven't passed ensure_acceptance
-- [ ] Rejection returns a clear error message telling the agent what's missing
-- [ ] Existing passing stories (all criteria checked, tests recorded) still flow through normally
-
-## Out of Scope
-
-- TBD
diff --git a/.storkit/work/1_backlog/359_story_harden_docker_setup_for_security.md b/.storkit/work/1_backlog/359_story_harden_docker_setup_for_security.md
new file mode 100644
index 0000000..4dc2774
--- /dev/null
+++ b/.storkit/work/1_backlog/359_story_harden_docker_setup_for_security.md
@@ -0,0 +1,25 @@
+---
+name: "Harden Docker setup for security"
+---
+
+# Story 359: Harden Docker setup for security
+
+## User Story
+
+As a storkit operator, I want the Docker container to run with hardened security settings, so that a compromised agent or malicious codebase cannot escape the container or affect the host.
+
+## Acceptance Criteria
+
+- [ ] Container runs as a non-root user
+- [ ] Root filesystem is read-only with only necessary paths writable (e.g. /tmp, cargo cache, claude state volumes)
+- [ ] Linux capabilities dropped to minimum required (cap_drop: ALL, add back only what's needed)
+- [ ] no-new-privileges flag is set
+- [ ] Resource limits (CPU and memory) are configured in docker-compose.yml
+- [ ] Outbound network access is restricted where possible
+- [ ] ANTHROPIC_API_KEY is passed via Docker secrets or .env file, not hardcoded in compose
+- [ ] Image passes a CVE scan with no critical vulnerabilities
+- [ ] Port binding uses 127.0.0.1 instead of 0.0.0.0 (e.g. "127.0.0.1:3001:3001") so the web UI is not exposed on all interfaces
+
+## Out of Scope
+
+- TBD
diff --git a/.storkit/work/1_backlog/35_story_agent_security_and_sandboxing.md b/.storkit/work/1_backlog/35_story_agent_security_and_sandboxing.md
deleted file mode 100644
index bfd0262..0000000
--- a/.storkit/work/1_backlog/35_story_agent_security_and_sandboxing.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-name: Agent Security and Sandboxing
----
-# Story 34: Agent Security and Sandboxing
-
-## User Story
-**As a** supervisor orchestrating multiple autonomous agents,
-**I want to** constrain what each agent can access and do,
-**So that** agents can't escape their worktree, damage shared state, or perform unintended actions.
-
-## Acceptance Criteria
-- [ ] Agent creation accepts an `allowed_tools` list to restrict Claude Code tool access per agent.
-- [ ] Agent creation accepts a `disallowed_tools` list as an alternative to allowlisting.
-- [ ] Agents without Bash access can still perform useful coding work (Read, Edit, Write, Glob, Grep).
-- [ ] Investigate replacing direct Bash/shell access with Rust-implemented tool proxies that enforce boundaries:
-  - Scoped `exec_shell` that only runs allowlisted commands (e.g., `cargo test`, `npm test`) within the agent's worktree.
-  - Scoped `read_file` / `write_file` that reject paths outside the agent's worktree root.
-  - Scoped `git` operations that only work within the agent's worktree.
-- [ ] Evaluate `--max-turns` and `--max-budget-usd` as safety limits for runaway agents.
-- [ ] Document the trust model: what the supervisor controls vs what agents can do autonomously.
-
-## Questions to Explore
-- Can we use MCP (Model Context Protocol) to expose our Rust-implemented tools to Claude Code, replacing its built-in Bash/filesystem tools with scoped versions?
-- What's the right granularity for shell allowlists — command-level (`cargo test`) or pattern-level (`cargo *`)?
-- Should agents have read access outside their worktree (e.g., to reference shared specs) but write access only within it?
-- Is OS-level sandboxing (Docker, macOS sandbox profiles) worth the complexity for a personal tool?
-
-## Out of Scope
-- Multi-user authentication or authorization (single-user personal tool).
-- Network-level isolation between agents.
-- Encrypting agent communication channels (all local).
diff --git a/.storkit/work/1_backlog/360_story_run_storkit_container_under_gvisor_runsc_runtime.md b/.storkit/work/1_backlog/360_story_run_storkit_container_under_gvisor_runsc_runtime.md
new file mode 100644
index 0000000..a723e03
--- /dev/null
+++ b/.storkit/work/1_backlog/360_story_run_storkit_container_under_gvisor_runsc_runtime.md
@@ -0,0 +1,21 @@
+---
+name: "Run storkit container under gVisor (runsc) runtime"
+---
+
+# Story 360: Run storkit container under gVisor (runsc) runtime
+
+## User Story
+
+As a storkit operator, I want the container to run under gVisor so that even if a malicious codebase escapes the container's process namespace, it cannot make raw syscalls to the host kernel.
+
+## Acceptance Criteria
+
+- [ ] docker-compose.yml specifies runtime: runsc
+- [ ] PTY-based agent spawning (Claude Code via PTY) works correctly under runsc
+- [ ] rebuild_and_restart (exec() replacement) works correctly under runsc
+- [ ] Rust compilation inside the container completes successfully under runsc
+- [ ] Document host setup requirement: runsc must be installed and registered in /etc/docker/daemon.json
+
+## Out of Scope
+
+- TBD