Python: Add multi-tenant hosting hosting security consideration to a2a sample

[TaoChenOSU]

Motivation & Context

This pull request adds important documentation about security considerations when using the a2a-sdk in multi-tenant hosting scenarios. It explains the default ownership behavior and provides a code example for implementing a tenant-aware owner_resolver to ensure proper isolation between tenants.

Description & Review Guide

• Added a section to the README.md in python/samples/04-hosting/a2a explaining the need for a tenant-aware owner_resolver when hosting tenant-bearing routes, including a sample implementation using InMemoryTaskStore.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Pull request overview

Adds security-focused documentation to the Python A2A hosting sample to highlight multi-tenant isolation risks when relying on default A2A store ownership scoping, and to show how to supply a tenant-aware owner_resolver when hosting tenant-bearing endpoints.

Changes:

• Added a new “Security considerations for multi-tenant hosting” section to the A2A hosting sample README.
• Included a short owner_resolver example for InMemoryTaskStore to scope ownership by tenant+user.

[github-actions]

Automated Code Review

Reviewers: 5 | Confidence: 82%

✓ Correctness

This PR adds a documentation section to the A2A hosting sample README about multi-tenant security considerations. The import path from a2a.server.tasks import InMemoryTaskStore is confirmed correct by existing usage in the codebase (e.g., python/samples/04-hosting/a2a/a2a_server.py and python/packages/a2a/agent_framework_a2a/_a2a_executor.py). The owner_resolver parameter and context attributes (context.tenant, context.user.user_name) reference the external a2a-sdk API which is not installed in the review environment, so they cannot be verified or refuted. The use of a null byte separator for compound keys is a sound technique for preventing key collision in multi-tenant scoping. No correctness issues found.

✓ Security Reliability

This is a documentation-only change adding a multi-tenant security considerations section to a sample README. The advice (using a tenant-aware owner_resolver for proper isolation) is sound security guidance. The referenced APIs (InMemoryTaskStore, owner_resolver parameter) come from the external a2a-sdk package and cannot be verified within this repository. No code changes are made, so there are no runtime security or reliability concerns introduced by this PR.

✓ Test Coverage

This PR adds a documentation-only change to a sample's README.md explaining security considerations for multi-tenant hosting with a2a-sdk. Since this is purely a documentation addition with a code example referencing an external SDK's API (a2a-sdk's InMemoryTaskStore and owner_resolver), there is no new behavior in this repository that requires test coverage. The existing test files (test_a2a_executor.py, test_a2a_agent.py) cover the framework's own A2AExecutor logic, and this README section is advisory guidance for downstream users.

✓ Failure Modes

This PR adds a documentation section to the a2a hosting sample README about multi-tenant security considerations. It's purely advisory documentation with a code example showing how to pass an owner_resolver to InMemoryTaskStore. No production code is changed. The a2a-sdk package (>=1.0.0) is an external dependency and I cannot verify the owner_resolver parameter exists without installing it, but the existing codebase already uses InMemoryTaskStore from a2a.server.tasks in multiple places, and the PR author is documenting a known API extension point. No concrete failure modes are introduced by this documentation change.

✓ Design Approach

The new security note is directionally useful, but the sample resolver currently derives its tenant component from the A2A request itself rather than from authenticated hosting context. That means the documentation's “ensure proper isolation between tenants” claim is overstated and can guide readers toward a security boundary that the repo’s own A2A docs say not to trust.

---

Automated review by TaoChenOSU's agents