feat(mcp): server-level wing access control via --allowed-wings / --blocked-wings

[brodheadw]

Summary

• New WingPolicy class enforces wing-level access control on every MCP tool that touches palace data.
• Two CLI flags on mempalace-mcp: --allowed-wings (allowlist) and --blocked-wings (denylist; takes precedence).
• Default is no-op — when neither flag is set, all wings pass.
• 18 wing-addressable tools now policy-gated via four enforcement patterns (hard block, soft filter, post-filter, ID lookup).
• 18 new tests, all passing.

Problem

A user running multiple agents shouldn't have to trust every agent with every wing. Today, any agent with the mempalace MCP server configured can read or write any wing the server has access to — there's no way to scope an agent to its own project's wing, hide a financial wing from a general assistant, or give a "master" agent broader access than its sub-agents. WingPolicy adds that scoping at the server-process level.

Change

mempalace-mcp now accepts:

• --allowed-wings WINGS — comma-separated allowlist; all unlisted wings denied
• --blocked-wings WINGS — comma-separated denylist; takes precedence over allowlist

Each agent's MCP server invocation carries its own policy:

// master agent — no flags, full access
"mempalace": { "command": "mempalace-mcp" }

// project-scoped agent
"mempalace": {
  "command": "mempalace-mcp",
  "args": ["--allowed-wings", "wing_user,wing_myproject"]
}

// general assistant, financial wings off-limits
"mempalace": {
  "command": "mempalace-mcp",
  "args": ["--blocked-wings", "wing_financial,wing_surveillance"]
}

All instances share ~/.mempalace/ data on disk; isolation is enforced server-side per process.

Enforcement matrix

Pattern	Tools
Hard block (access_denied on explicit-wing requests)	list_rooms, search, find_tunnels, add_drawer, diary_read, diary_write, list_drawers, create_tunnel, list_tunnels, follow_tunnels
Soft filter (silently omit blocked wings from aggregates)	status, list_wings, get_taxonomy, list_rooms (unfiltered), list_drawers (unfiltered)
Post-filter (drop blocked-wing hits from result arrays)	search, check_duplicate, diary_read (spans-all-wings), list_tunnels (either endpoint), follow_tunnels (destination)
ID lookup → policy check	get_drawer, update_drawer (old AND new wing), delete_drawer, delete_tunnel (both endpoints)

Also bundled: a one-line .gitignore fix for per-process .coverage.* artifacts that slipped past the existing literal .coverage rule.

Tests

• WingPolicy allowlist + blocklist + precedence logic
• Soft filter omits blocked wings from status, list_wings, get_taxonomy
• list_rooms unfiltered drops rooms unique to blocked wings
• Hard block on explicit wing requests across read + write tools
• search post-filter drops blocked hits when no wing arg given
• check_duplicate suppresses blocked-wing matches (no existence-leak)
• delete_drawer / update_drawer / get_drawer enforce via ID lookup
• update_drawer also blocks moves into a blocked wing
• create_tunnel blocks when either endpoint is blocked
• list_tunnels drops tunnels where either endpoint is in a blocked wing
• delete_tunnel enforces on either endpoint via tunnel-id lookup
• follow_tunnels hard-blocks origin and post-filters destinations

ruff format + ruff check clean. All 18 new TestWingPolicy tests pass; rebased onto current main.

What's NOT in this PR

• traverse_graph / graph_stats — full enforcement requires policy-aware traversal inside palace_graph.py. Inline notes added to both tools' docstrings flagging the gap. Happy to do as a follow-up.
• KG tools (kg_query, kg_add, kg_invalidate, kg_timeline, kg_stats) — the knowledge graph is entity-keyed, not wing-keyed. Different scoping model.
• Hook / settings / reconnect tools — not data-bearing.
• Per-sub-agent scoping — WingPolicy operates at the MCP server process level. Hosts that spawn sub-agents which share the parent's MCP connection will see those sub-agents inherit the parent's policy. True per-sub-agent scoping requires the host to launch each sub-agent with its own mempalace-mcp invocation — a host-side concern, not a server-side one. Worth a note in any user docs that mention per-agent policies.

[brodheadw]

Open to discussing further with maintainers. I know this might read as a significant change, but it's totally opt-in, no flags, every agent still has full access. Felt necessary for cleanly managing multi-agent access to memory, especially with overlapping projects. My email's in my profile.