Scopes and middleware on tool calls: where does the authority decision live?

[javmann100]

I maintain mnki, an open trust layer for agents: identity, delegated authority with constraints, and a signed evidence list per decision. It sits underneath MCP and A2A rather than replacing them, and NeMo-Relay is the closest runtime design I have seen to where I think that decision belongs: scopes so runs, turns, tools, LLM calls and subagents have clear boundaries, and middleware on the tool call itself.

The question I would like your view on: when a tool call enters your middleware, should "is this agent, acting for this principal, allowed to make this call with these arguments" be a middleware the runtime ships, a plugin the operator installs, or a check outside the runtime that the middleware merely calls? I have built the third (a verifier the runtime can call in-process or over HTTP) and I want to know whether that fits your model or fights it.

Twenty minutes would help me a great deal; a reply here is fine too. Reference implementation, Apache-2.0: https://github.com/MNKIAgentOS/agent-trust; integration paths: https://mnki.com/docs/integrations. Thank you for NeMo-Relay; a multi-language runtime with lifecycle events as a first-class concept is rare.

[willkill07]

First, I want to apologize for the delay. I did not notice this discussion post until this morning.

When a tool call enters your middleware, should "is this agent, acting for this principal, allowed to make this call with these arguments" be:

1. a middleware the runtime ships
2. a plugin the operator installs
3. or a check outside the runtime that the middleware merely calls?

Unfortunately the answer is "it depends". I don't have the bandwidth or capacity to go through external code.

Direct Middleware should be registered when you have intrinsic behavior embedded into your Relay-enabled agent.

Plugins should be used when you want portable support across multiple Relay-enabled agents. Or if you have multiple middleware with some common shared state.

As for what the middleware invokes, that's entirely up to design requirements. Conditional execution guardrails make sense to leverage some sort of "external" decision or guardrail API.