Add Secure Tool Invocation via Metadata Binding

[rabbidave]

Document & Config

[davidlabianca]

@rabbidave Let's create an issue that covers the problem and the proposal as a way to begin the CoSAI community review of this proposal.

[santosomar]

Good job on the documentation and configuration changes for enabling secure tool invocation via metadata binding.
I don’t see any issues from my side that need further discussion.
If there are no objections raised or pending discussions, I’ll approve and merge this PR.

[rabbidave]

@rabbidave Let's create an issue that covers the problem and the proposal as a way to begin the CoSAI community review of this proposal.

Happily, any specifics on how? Else happy to open an issue with a blurb that points here to this PR for risk-rm

Also adding one on maturity models; love the framework

[rabbidave]

Good job on the documentation and configuration changes for enabling secure tool invocation via metadata binding. I don’t see any issues from my side that need further discussion. If there are no objections raised or pending discussions, I’ll approve and merge this PR.

Sounds good and TY. Gonna add another pattern here shortly and trying not to mess up y'all's repo

[rabbidave]

@rabbidave Let's create an issue that covers the problem and the proposal as a way to begin the CoSAI community review of this proposal.

Just found this link, LMK if y'all want it as an issue or just the PR. Adding the md/yaml for the maturity model now

[davidlabianca]

@rabbidave Let's create an issue that covers the problem and the proposal as a way to begin the CoSAI community review of this proposal.

Just found this link, LMK if y'all want it as an issue or just the PR. Adding the md/yaml for the maturity model now

Thanks @rabbidave for the PR and the comments...

I do think we need to have a full discussion on this approach in an issue - we should start with issue creation so that we can get the group to review and opine...

Happy to collaborate on that issue creation and we can then address the following comments as well as garner WS1 feedback/engagement.

update: I opened issue #129 to discuss this addition, etc...

---

Re the PR itself:

• It should target develop not main as it is a content update and requires CoSAI workstream governance / review

re: the schema.yaml file...

• I may be reading this incorrectly but it looks more like a yaml impl vs the schema for the yaml... We should entertain a json schema validation that would validate that yaml - unless there is a bog standard schema it conforms to that we can use with check-jsonschema
• If this is a schema - we should restructure as a json schema and drop it in schemas/ following the project approach

re: the cosai-rm.yaml file...

• We should specify which schema will validate it...

re: risks and controls highlighted in the *.mds and other files

• I'd imagine it is our intent to create aligned CoSAI-RM risks and controls for these in the respective controls.yaml and risks.yaml files?

[rabbidave]

Adding issue/discussion here for posterity

[nik-kale]

Solid foundation! The axiom-based approach and tiered implementation model are well structured. My comments focus on one theme: extending the standard to cover delegated/multi-hop invocations common in agentic architectures, without breaking the simplicity of the Tier 1 model. Proposed a new invariant (INV-7), risk (RISK-06), and control (CTRL-07) for delegation chain integrity at Tier 2+

[nik-kale]

The "No delegation, no scope expansion" statement works for direct user-to-tool invocations, but agentic architectures commonly involve delegation chains (User -> Orchestrator -> Sub-agent -> Tool). Worth scoping this explicitly so it doesn't read as a blanket prohibition on delegation, which would make the standard inapplicable to most multi-agent scenarios.

Suggested change

	The token MUST bind a specific identity to a specific tool. No delegation, no scope expansion.
	The token MUST bind a specific identity to a specific tool. In direct invocation, no delegation or scope expansion is permitted. For delegated invocations (Tier 2+), see Delegation Chain Integrity (INV-7): each hop in a delegation chain must carry a verified identity and must narrow or maintain - never expand - the authorized scope.

RFC 8693 (Token Exchange) provides the act claim for tracking delegation chains, and SPIFFE provides cryptographic workload identity at each hop. The Checkmarx MCP findings from November 2025 showed what happens when scope isn't validated per-hop: OAuth tokens get reused across MCP servers without verifying that the downstream server should have that scope.

[rabbidave]

I'm down with delegates; we can always profile the runtime and sign the artifacts

adding those links to the PR so folks can affect Invariant 7 :) Appreciate y'all.

@davidlabianca think we're good to go otherwise on merging the base patterns. LMK otherwise!

[rabbidave]

Added Inv-7 and updates to the patterns/yaml

[nik-kale]

INV-7, RISK-06, and CTRL-07 all look good. Scope narrowing assertion is the right call, and mapping to LLM08 makes sense since the confused deputy problem is really about excessive agency with valid credentials. Glad to see INV-7 required at Tier 2+ and showing up in the validation sequence at step 7. The persona responsibility additions are a nice touch too. Having clear accountability per invariant makes the whole thing more auditable. Good to merge from my side.