cafalchio pointed me here from IBM/mcp-context-forge#6014, where we'd shipped a tool_pre_invoke plugin (invinoveritas Review -- an independent, signed verdict on a specific proposed action before it executes) and the repo is consolidating plugins toward a shared marketplace instead of per-repo entries.
Real distinction this plugin makes concrete, and I think it maps cleanly onto CPEX's own pipeline: APL/PDP policy decides whether an action is ELIGIBLE at all (identity, delegation, information-flow labels -- deterministic, rule-based). A separate independent verdict decides whether THIS specific payload is SOUND given its actual content -- not a rule match, a judgment call, checkable after the fact against a published key without trusting the party that issued it. The "invoke plugins" step in your enforcement pipeline reads like the right seam for that second kind of check to compose at, after the deterministic PDP/policy phase has already cleared the operation as eligible.
Is there a real submission process/spec for a plugin like this yet (crates.io being the 0.2 Rust core makes me suspect the hook contract may look different from the mcp-context-forge one), or is that still being defined? Happy to build against whatever the actual interface ends up being once it exists.
cafalchio pointed me here from IBM/mcp-context-forge#6014, where we'd shipped a
tool_pre_invokeplugin (invinoveritas Review -- an independent, signed verdict on a specific proposed action before it executes) and the repo is consolidating plugins toward a shared marketplace instead of per-repo entries.Real distinction this plugin makes concrete, and I think it maps cleanly onto CPEX's own pipeline: APL/PDP policy decides whether an action is ELIGIBLE at all (identity, delegation, information-flow labels -- deterministic, rule-based). A separate independent verdict decides whether THIS specific payload is SOUND given its actual content -- not a rule match, a judgment call, checkable after the fact against a published key without trusting the party that issued it. The "invoke plugins" step in your enforcement pipeline reads like the right seam for that second kind of check to compose at, after the deterministic PDP/policy phase has already cleared the operation as eligible.
Is there a real submission process/spec for a plugin like this yet (crates.io being the 0.2 Rust core makes me suspect the hook contract may look different from the mcp-context-forge one), or is that still being defined? Happy to build against whatever the actual interface ends up being once it exists.