research(plugins): declared filesystem/secrets/network capability boundaries for plugin manifests (IronClaw reborn-substrate parity, ironclaw-v0.28.0)

[bug-ops]

Description

IronClaw (nearai/ironclaw), a Rust-based reference agent tracked in .claude/rules/continuous-improvement.md Competitive Parity Monitoring, shipped a major architectural change in ironclaw-v0.28.0 (2026-05-07, "reborn" integration substrate): host foundation crates, capability host, runtime dispatcher, process lifecycle, and filesystem/secrets/network/extension-manifest-registry boundaries. This establishes a capability-based sandboxing model where an extension's manifest declares required filesystem/secrets/network access, and a host-level capability dispatcher enforces those boundaries at runtime — not just at install time.

zeph's plugin.toml manifest (crates/zeph-plugins/src/manifest.rs) has no fields for declaring filesystem/secrets/network capability scope, and there is no capability-host enforcing per-plugin runtime access boundaries. Installed plugins' skills and MCP servers run with the same trust/access level as the rest of the agent.

This is distinct from two already-tracked, related-but-different concerns:

• parity: zeph-plugins lacks install-time reputation/typosquat scanning (IronClaw pattern) #5864 (P3) — install-time reputation/typosquat scanning, a supply-chain-trust concern (structural/content checks before install, not runtime capability enforcement).
• research(security): AgentTrap runtime trust failures in third-party agent skills — capability drift detection (arXiv:2605.13940) #3961 (P4, AgentTrap) — runtime trust-failure detection for skills via post-hoc deviation logging against declared trigger/tool scope (detection-only, not a structurally-enforced boundary; also skill-scoped, not plugin-scoped).

This finding is about preventive, structurally-enforced runtime capability scoping declared in the plugin manifest itself.

Reproduction Steps

1. Inspect crates/zeph-plugins/src/manifest.rs — PluginManifest has only name/version/skills/mcp.servers/config overlay fields, no capability/permission schema.
2. Inspect crates/zeph-plugins/src/manager/security.rs — validate_manifest_for_install, validate_overlay_keys, validate_mcp_commands are structural/content validation only, no capability declaration or runtime enforcement.
3. Observe: an installed plugin's skills/MCP servers execute with full-agent trust — no per-plugin filesystem/secrets/network scoping exists.

Expected Behavior

Plugin manifests can optionally declare required capability scope (filesystem paths, secrets/vault keys, network egress), and a host-level enforcement layer restricts a plugin's skills/MCP-server-spawned processes to that declared scope at runtime, independent of install-time trust checks.

Actual Behavior

No capability declaration schema exists in plugin.toml; no runtime enforcement layer scopes plugin filesystem/secrets/network access below full-agent trust level.

Environment

• Version/commit: HEAD 3911df290d8d7b73b955b657ea8f51541002eb6b
• Reference: IronClaw ironclaw-v0.28.0 (2026-05-07) release notes — https://github.com/nearai/ironclaw/releases/tag/ironclaw-v0.28.0

Priority Reasoning

P3 per this project's own parity severity table (.claude/rules/continuous-improvement.md): P2 requires the capability to be present in 2+ reference agents; only IronClaw (single reference project) has shipped this pattern so far. Useful, low-urgency.

Spec

.local/specs/082-plugin-capability-manifest-boundaries/spec.md