Problem
PluginRpcHandlers methods are typed as (input) => output — one parameter, the parsed input, and nothing else (bb-plugin-sdk.d.ts, PluginRpcHandlers<Contract>). A handler has no way to learn who called it: not the calling plugin, thread, or any host-verified identity.
Any RPC whose semantics depend on the caller must therefore trust caller-supplied fields in input. That inverts the trust boundary: a caller can claim any identity, and a handler that needs "exclude the requesting caller" or "attribute this action to the caller" cannot bind the decision to anything real.
Concrete shape today
type PluginRpcHandlers<Contract> = {
[Method in keyof Contract]: (input: InputOf<Method>) => OutputOf<Method> | Promise<OutputOf<Method>>;
};No second parameter, no context object, no per-call attribution.
Requested capability
Pass host-verified caller context to RPC handlers — e.g. a second context argument (calling plugin id, calling thread id if any, origin kind), analogous to what agent-tool registration contexts already receive. Handlers could then bind request-scoped decisions (exclusions, attribution, rate keys) to the actual caller instead of trusting input.
Related family: #1541 (host-issued operator receipts for invocation contexts) — same root theme, host-verified attribution for plugin invocations; that one is about operator authority, this one is about caller identity.
Workaround
None from inside a handler. Plugins either trust input (unsafe for the cases above) or refuse the operation.
Problem
PluginRpcHandlersmethods are typed as(input) => output— one parameter, the parsed input, and nothing else (bb-plugin-sdk.d.ts,PluginRpcHandlers<Contract>). A handler has no way to learn who called it: not the calling plugin, thread, or any host-verified identity.Any RPC whose semantics depend on the caller must therefore trust caller-supplied fields in
input. That inverts the trust boundary: a caller can claim any identity, and a handler that needs "exclude the requesting caller" or "attribute this action to the caller" cannot bind the decision to anything real.Concrete shape today
No second parameter, no context object, no per-call attribution.
Requested capability
Pass host-verified caller context to RPC handlers — e.g. a second
contextargument (calling plugin id, calling thread id if any, origin kind), analogous to what agent-tool registration contexts already receive. Handlers could then bind request-scoped decisions (exclusions, attribution, rate keys) to the actual caller instead of trusting input.Related family: #1541 (host-issued operator receipts for invocation contexts) — same root theme, host-verified attribution for plugin invocations; that one is about operator authority, this one is about caller identity.
Workaround
None from inside a handler. Plugins either trust input (unsafe for the cases above) or refuse the operation.