v0.2+: TEE-side access control / security groups for child paths

[hanwencheng]

Summary

In the MSK-derived stateless TEE architecture, unpair is disabled — the master-child key relationship is a permanent mathematical derivation. Access control (suspend/resume) for child paths must be implemented as TEE-side policy, not as key destruction.

This issue tracks the design and implementation of security-group-like permission settings for child derivation paths, where each path has an implicit permission state that defaults to disabled (deny-by-default).

Context

With MSK-derived keys (see wiki/blockchain-tee-architecture.md), the child key at any path is always derivable:

child_privkey = soft_derive(KDF(MSK, H(identity)), "/agent-1/0")

This derivation is a mathematical fact — it can't be "undone." So "unpair" (destroying the key relationship) is impossible. Instead, the TEE must maintain access control policy that determines which paths are active (JWT issuance allowed) vs suspended (JWT issuance denied).

Proposed design

Security group model

Each derivation path has an associated permission set:

path: "/agent-1/0"
permissions:
  active: false          ← JWT issuance denied (default for new paths)
  scope: [openrouter]    ← allowed services (set at pair time)
  rate_limit: 100/min    ← per-session read cap
  valid_until: block N   ← optional hard expiry

Default-deny

New paths start with active: false. A path must be explicitly activated (via the pair approval flow) before the TEE will issue JWTs for it. This means:

• An attacker who knows a valid path can't get a JWT without the master's approval
• The TEE won't derive keys for unapproved paths even though it mathematically could

Suspend operation

master CLI → TEE: suspend_path("/agent-1/0")
  → TEE submits on-chain suspend event (durable, survives TEE restart)
  → TEE refuses to issue new JWTs for this path
  → existing JWTs expire naturally (bounded by TTL)

Resume operation (future)

master CLI → TEE: resume_path("/agent-1/0")
  → TEE submits on-chain resume event
  → TEE starts issuing JWTs again for this path

Where permission state lives

• On chain (recommended): suspend/resume events are on-chain extrinsics. The TEE reads chain state to check path permissions. Durable across TEE restarts, replicates across TEE partitions.
• TEE-internal (fallback): in-memory denylist for fast checks. Not durable. Useful as a cache layer on top of on-chain state.

Priority

Low. The pair approval flow already provides implicit activation (the TEE only issues JWTs for paths that have been paired). Explicit suspend is an enhancement for operational control — useful but not blocking for v0.1.

The on-chain revocation list (wiki/blockchain-tee-architecture.md Section 4) provides the immediate revocation mechanism. This issue is about building richer, security-group-style permission management on top of that foundation.

References

• wiki/blockchain-tee-architecture.md — stateless TEE architecture, revocation model
• docs/spec/plans/development-stages.md Stage 9 — MSK-derived key design decisions
• Issue v0.1: TEE-side per-session read rate limit (abuse defense) #4 — TEE-side per-session read rate limit (complementary abuse defense)