Agent Skills › openchamber/openchamber › isolated-space-boundary

isolated-space-boundary

GitHub

指导修改隔离空间信任边界的安全技能,涵盖容器加固、网络策略、执行限制及凭证管理。要求遵循设计契约,追踪安全保证,确保在代理可能篡改自身环境时仍能有效执行防护和证据验证。

.agents/skills/isolated-space-boundary/SKILL.md openchamber/openchamber

Trigger Scenarios

修改容器安全或网络策略 调整隔离空间的权限与凭证 变更代码传输或执行生命周期规则

Install

npx skills add openchamber/openchamber --skill isolated-space-boundary -g -y
More Options

Non-standard path

npx skills add https://github.com/openchamber/openchamber/tree/main/.agents/skills/isolated-space-boundary -g -y

Use without installing

npx skills use openchamber/openchamber@isolated-space-boundary

指定 Agent (Claude Code)

npx skills add openchamber/openchamber --skill isolated-space-boundary -a claude-code -g -y

安装 repo 全部 skill

npx skills add openchamber/openchamber --all -g -y

预览 repo 内 skill

npx skills add openchamber/openchamber --list

SKILL.md

Frontmatter
{
    "name": "isolated-space-boundary",
    "description": "Use when changing isolated-space trust boundaries: container hardening, networks and gatekeeper policy, exec and lifecycle, grants and credentials, code transfer and apply, dispatcher isolation, preview content, or tests of these protections."
}

Isolated Space Boundary

Treat the agent inside a space as hostile. A restriction must hold even when the agent changes its own files, environment, tools and server responses. The agreed guarantees belong to Design in packages/web/server/lib/spaces/DOCUMENTATION.md; this skill guides changes to their enforcement and evidence.

Read The Owning Contract

Read Design in packages/web/server/lib/spaces/DOCUMENTATION.md, the boundary rule, the words and the numbered decisions, and the escape checks and the evidence rule under Tests there.

Then load the branch-specific context before editing:

Change Required context
Container restrictions, networks, environment, command or lifecycle packages/web/server/lib/spaces/DOCUMENTATION.md, Hardening, The gatekeeper container, Lifecycle, and the owning section for the changed operation
Corridor, window, control or journal The matching section under The gatekeeper in the module documentation, including Known limits
Exec requests, server token or responses from inside The module documentation, Token, The exec channel and Process rules
Grants or credentials The module documentation, Design (words, decisions 4, 5 and 13), Window, Control and Grants
Code transfer or apply The module documentation, Code in and Code out, with decision 7 under Design
Dispatcher, session identity or preview content The module documentation, Dispatcher and Preview, and the nearest documentation for the changed route, transport or state owner

openchamber-change-discipline owns change scope and validation risk. Follow desktop-shell for child processes. Dispatcher and event changes also use ui-api-decoupling, relay-transport and sync-state-invariants for their respective contracts.

Trace The Guarantee

Before changing enforcement, identify each affected guarantee, what the user authorized, what the agent controls, and which host, gatekeeper or runtime mechanism enforces it. Name the existing test or the missing proof. Context gathering is complete when every affected guarantee has that mapping.

Ask what could the agent do from inside to undo or bypass this restriction? Trace the request or data through the actual enforcement point, including parsing, normalization and the operation that consumes it. A space's configuration can help tools cooperate, but enforcement must survive the agent replacing that configuration.

Keep these distinctions explicit:

  • Corridor and window have different authority. The corridor applies network-mode policy to agent-selected destinations. The window serves an upstream the host granted from the user's decision, which may be private. Read each contract before applying one path's restrictions to the other. Space-provided requests are untrusted input to a host decision, never authority to create a grant.
  • Host, gatekeeper and space are different secret holders. A "uses without seeing" credential lives in the gatekeeper and stays hidden from the space. A "handed over" credential is deliberately readable by the agent. The space server's token is also readable by the agent; it protects against others. Classify the credential before deciding whether its presence is a leak.
  • Create arguments are intent; inspected state is evidence. Keep each hardening builder aligned with its own checker and behavior test. Verify before starting either container, and preserve the manager's verification of the place's result. For changes to start or restart, trace policy loss and re-granting against the documented lifecycle rather than assuming memory survived.
  • Space output stays untrusted on the host. Check where it can become a command, filesystem write, session identity or browser content. For transfer and apply, follow the quarantine and host-built patch contract. For forwarding, follow the credential-stripping, directory, identity and origin rules under Dispatcher in the module documentation.

Preserve the fail-closed start and account for the known limits in the owning contract. A change that needs a broader permission must make that user decision explicit rather than quietly weakening a mode. Resolve a conflict with the agreed design before implementing it.

Prove The Protection

Choose the test level where the failure can occur. Container and network guarantees need attempts from inside a real space. Parser and socket-lifecycle defects may need controlled local tests to expose the exact failure. Use the module documentation's Tests section for the required suites and the escape checks.

For a new or changed protection, or an escape test whose assertion or setup changes:

  1. Make the regression discriminate. It must fail on the defective behavior and pass with the protection. A refusal caused by a missing tool, failed DNS or an offline upstream is not proof; establish the applicable positive control.
  2. Prove it by removing it. In a disposable copy, remove the protection or restore the original defect, run the test that claims to prove it, and watch it go red. The run is the evidence: a mutation you describe and do not run proves nothing. Confirm it fails for the promised violation, not a setup error. If an independent protection still blocks the attempt, identify it and isolate the changed layer's test. A surviving defense is not itself a test defect.
  3. Restore the protection, run the test again, and watch it go green. Record the mutation, control, result and any blocked verification in the validation evidence. Update owning documentation when the guarantee, mechanism or known limit changes. Keep transient run history in the task or PR evidence.

For a behavior-preserving refactor, establish the existing behavior and rerun the affected regression tests. Add a sensitivity check when the refactor changes what those tests exercise or exposes a gap in their proof.

Stage 2 showed why sensitivity matters: a one-directional download test passed with the broken tunnel teardown; a full-duplex test exposed truncation. Exercise the interaction that caused the defect, not just an easier neighboring path.

Use these controls where they apply:

  • For name filtering, include alternative address spellings and normalization, then verify the connection uses the checked address without a second lookup. The corridor's exact name and address rules live in Corridor.
  • For secret containment, prove a disposable credential works at a controlled upstream. Collect the space's observable data and search it on the host. Sending the hidden credential into the space as a search pattern invalidates that proof.
  • For refusals and journal changes, verify both what the space learns and what the host can still read under hostile input. Internal policy reasons belong in the journal; the public refusal contract belongs to the relevant listener.
  • For connection caps, use a small test cap and confirm server acceptance before exceeding it. Completed client handshakes alone do not prove the server accepted the connections.
  • For journal assertions, identify records produced by the attempt without depending on cross-process clock precision. Keep controlled DNS and upstreams local as the escape-test rules require, with their explicit internet-baseline exception.

Completion

Every affected guarantee has evidence or an explicit blocker, and the normal allowed operation still works. Report unit, live and mutation results separately, with platform and runtime conditions for measurements. A local test does not establish container isolation; a live refusal does not establish correct transfer teardown. Keep the documented promise within what the evidence proves.

Version History

  • bf977d2 Current 2026-10-19 13:04

    设计文档路径从 docs/isolated-spaces/DESIGN.md 迁移至 packages/web/server/lib/spaces/DOCUMENTATION.md,以配合功能隐藏策略及模块文档整合。

  • 336e192 2026-09-22 17:58

Same Skill Collection

.agents/skills/changelog-authoring/SKILL.md
.agents/skills/clack-cli-patterns/SKILL.md
.agents/skills/communication-style/SKILL.md
.agents/skills/desktop-shell/SKILL.md
.agents/skills/drag-to-reorder/SKILL.md
.agents/skills/enterprise-boundary/SKILL.md
.agents/skills/locale-ui-patterns/SKILL.md
.agents/skills/openchamber-change-discipline/SKILL.md
.agents/skills/opencode-v2/SKILL.md
.agents/skills/performance-engineering/SKILL.md
.agents/skills/pr-review/SKILL.md
.agents/skills/relay-transport/SKILL.md
.agents/skills/rtl-layout/SKILL.md
.agents/skills/serve-sim/SKILL.md
.agents/skills/settings-ui-patterns/SKILL.md
.agents/skills/sync-state-invariants/SKILL.md
.agents/skills/theme-system/SKILL.md
.agents/skills/triage-issues/SKILL.md
.agents/skills/triage-prs/SKILL.md
.agents/skills/ui-api-decoupling/SKILL.md
.agents/skills/update-changelog/SKILL.md
.agents/skills/writing-for-agents/SKILL.md

Metadata

Files
0
Version
bf977d2
Hash
db8ca1ae
Indexed
2026-09-22 17:58

Accueil - Wiki
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-10-31 21:38
浙ICP备14020137号-1