Add backend-scoped vMCP authorization

[Sanskarzz]

Summary

VirtualMCPServer currently exposes each tool as a Cedar Tool entity whose only resource parent is the vMCP itself. As a result, administrators cannot grant access to every tool from one discovered backend without enumerating tools or relying on conflict-resolution name prefixes.

• Carry each aggregated tool's trusted logical BackendID into Cedar authorization.
• Make the request's Tool entity a child of both the vMCP MCP entity and a materialized Backend entity.
• Apply the same backend metadata during tool-list filtering and tool-call authorization.
• Preserve configured Backend entities so attributes and transitive parent hierarchies continue to work.
• Document backend-scoped policies and the behavior for composite tools.

Fixes #5483

Type of change

• Bug fix
• New feature
• Refactoring (no behavior change)
• Dependency update
• Documentation
• Other (describe):

Test plan

• Unit tests (task test)
• E2E tests (task test-e2e)
• Linting (task lint-fix)
• Manual testing (describe below)

Verified the changed packages with the repository's race-test flags:

go test -ldflags=-extldflags=-Wl,-w -v -race \
  ./pkg/authz/authorizers \
  ./pkg/authz/authorizers/cedar \
  ./pkg/vmcp/core

The focused tests pass, including matching-backend allow, different-backend deny despite a misleading tool name, empty-backend deny, list/call parity, and configured Backend hierarchy preservation. Focused golangci-lint v2.12.2 reports zero issues for ./pkg/authz/authorizers/... and ./pkg/vmcp/core/.... task build and task license-check also pass.

The full task lint-fix currently reaches six unrelated pre-existing SA1019 warnings in operator files not changed by this PR. A full task test run was stopped after 15 minutes; the changed packages were then verified independently as listed above.

Changes

File	Change
pkg/vmcp/core/admission.go	Forwards the tool's trusted BackendID for both list and call decisions.
pkg/authz/authorizers/resource_metadata.go	Adds typed internal context plumbing for trusted resource metadata.
pkg/authz/authorizers/cedar/	Adds the Backend entity relationship, materializes request Backend entities, and preserves configured Backend hierarchies.
pkg/vmcp/core/admission_test.go	Exercises backend-scoped list/call behavior and guards against name-prefix spoofing.
docs/authz.md, docs/arch/10-virtual-mcp-architecture.md	Documents the policy model, trust boundary, and composite-tool behavior.

Does this introduce a user-facing change?

Yes. Cedar policies for a VirtualMCPServer can authorize all tools originating from one backend with resource in Backend::"<backend-id>", without listing individual tools or depending on advertised tool names.

Implementation plan

Approved implementation plan

1. Use vmcp.Tool.BackendID, which is attached by the aggregation layer, as the trusted backend identity.
2. Carry that identity through vMCP admission without changing the generic Authorizer interface or the external authorization contract.
3. For Cedar tool decisions, add Backend::<BackendID> as a resource parent and materialize that parent in the request entity map so Cedar's in operator can traverse it.
4. Keep the existing MCP::<vMCP-name> parent to preserve current policies.
5. When entities_json already defines the Backend, retain the configured entity so its attributes and parent hierarchy are not overwritten by the request placeholder.
6. Use the same metadata path for list filtering and call enforcement, and add focused tests and documentation.

Special notes for reviewers

• The BackendID comes from the server-side aggregated capability. It is never inferred from client arguments or the advertised tool name.
• A minimal Backend entity is created per request because adding only its UID as a parent is insufficient for Cedar hierarchy traversal.
• Existing exact-tool and vMCP-scoped policies are unchanged because the original MCP parent remains.
• Composite tools have an empty BackendID because they may span multiple backends, so this PR intentionally gives them no Backend parent.
• If static entities_json defines the same Backend, that configured entity wins over the request placeholder, enabling policies through Backend attributes or transitive groups.
• This is intentionally tool-scoped. Backend-scoped resource and prompt authorization can be added separately once their admission semantics are designed.
• No CRD, generated manifest, or operator ConfigMap shape changes are required.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.17%. Comparing base (6e6c67b) to head (13fa0c6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6487      +/-   ##
==========================================
- Coverage   78.18%   78.17%   -0.01%     
==========================================
  Files         769      770       +1     
  Lines       74995    75013      +18     
==========================================
+ Hits        58633    58643      +10     
- Misses      16357    16365       +8     
  Partials        5        5              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.