Enforce user, agent, and exact-target authority for the first ToolHive integration

Outcome

For the selected first ToolHive-backed integration, an allowed operation is performed only for the verified user, by the permitted named agent, on the exact resolved target. A denied request reads no stored credential and reaches no provider.

Proposed approach

Use the protected-operation authority path to verify the admitted workload and agent evidence, intersect it with user authority and the exact target/operation, and perform credential lookup only after successful admission. Pin a ToolHive release whose behavior is demonstrably sufficient for this proof.

Not in this issue

A generic resource-policy language, every provider, scheduled authority, or fallback service credentials.

Dependencies

The external broker boundary (#1562) and selected ToolHive upstream capabilities — see stacklok/toolhive#6199 (spiffe_jwt/spiffe_x509 client auth) and stacklok/toolhive#6204 (scope intersection). Do not begin production wiring until the required release and compatibility matrix are explicit.

Proof

Use two agent definitions with different authority (for example, a read-only reviewer and a write-capable deployer). Prove the reviewer cannot obtain the deployer's authority, the denied path performs no credential read, and successful results contain no credential material.

Start with the protected-operation authority path and the external broker boundary in #1562, then review ToolHive issues #6199 and #6204. Establish the required release and compatibility matrix before production wiring, and prove reviewer/deployer separation, no credential read on denial, and no credential material in successful results.