[MCP-01] Define tenant, authorization, consent, and audit threat model for MCP tools

[jaavid]

Background

CoreLink is one product across multiple implementation repositories. This work is owned by mcp-server under EPIC-02.

Problem

The repository does not yet provide a supported, reproducible and acceptance-tested way to define tenant, authorization, consent, and audit threat model for MCP tools.

Goal

Define tenant, authorization, consent, and audit threat model for MCP tools, aligned with tagged contracts and the shared CoreLink release train.

Parent

• Primary Product Epic: EPIC-02
• Backlog ID: MCP-01

Scope

• Deliver the title outcome inside mcp-server.
• Reconcile contract version, authentication, tenancy, error, compatibility, packaging and documentation behavior where applicable.
• Retain evidence for the Developer Platform gate.

Out of Scope

• Hand-written divergence from the normative contracts.
• Unsupported production claims before an artifact and conformance evidence exist.
• A separate repository roadmap.

Acceptance Criteria

• The outcome is reproducible from documented inputs and tagged dependencies.
• Expected, error, retry/recovery and compatibility behavior is verified.
• Authentication, tenant context and sensitive-data handling are safe where applicable.
• Installable artifacts or explicit scaffold status are documented accurately.
• Examples and documentation are versioned and runnable.
• Conformance evidence is linked to the parent Epic.

Technical Notes

Generated artifacts must identify immutable contract provenance. Security-sensitive tools use least privilege, explicit consent, audit and safe token handling. Package channels must distinguish prerelease from stable.

Dependencies

• Blocked by: EPIC-02 actor contract
• Blocks: Resolved during refinement.
• Cross-repository: Link concrete contract, mock, documentation and release Issues.

Planning Metadata

• Type: Technical Task
• Priority: P0
• Product milestone: Developer Platform
• Domains: security, devex
• Area: backend
• Complexity: M
• Initial status: Triage
• DRI: Unassigned
• Intended labels: type:technical-task, priority:p0, domain:security, domain:devex, area:backend

Definition of Done

• Acceptance criteria demonstrated.
• Tests/conformance and required evidence pass.
• Contracts are updated or confirmed unaffected.
• Security and tenancy boundaries are reviewed.
• Packaging, provenance and rollback are verified.
• Documentation and release notes are updated.
• Pull request(s) are merged and linked.