Add isolated MCP auth-binding demo for Foundry-style tool calls

[Copilot]

Description

Adds a minimal, isolated demo proving the app can bind a trusted user identity to MCP client calls and have MCP enforce authorization server-side regardless of model behavior. This follows existing repo patterns for MCP transport and Foundry-style tool orchestration while avoiding production-path changes.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code refactoring
• Performance improvement
• Test addition/improvement

Related Issues

N/A

Changes Made

• Isolated mock MCP server

  • Added src/mock_mcp_auth_demo/server.py and src/mock_mcp_auth_demo/app.py
  • In-memory USERS + PERMISSIONS
  • Tools: get_my_data, get_sensitive_data
  • Server-side auth reads trusted identity from MCP request context (x-demo-user) and denies unauthorized calls with clear errors

• Foundry-style identity-bound demo flow

  • Added scripts/mock_mcp_foundry_identity_demo.py
  • App sets trusted identity in code (alice@example.com / bob@example.com)
  • MCP client is bound to that identity via request headers
  • Simulates LLM tool selection and demonstrates:
    • authorized user → sensitive tool success
    • unauthorized user → sensitive tool denied by MCP

• Docs + tests for the demo

  • Added src/mock_mcp_auth_demo/README.md with run instructions, trust-boundary explanation, and dev tunnel public endpoint steps
  • Added focused tests in src/a2a_servers/tests/test_mock_mcp_auth_demo.py
  • Linked module in src/README.md

async with httpx.AsyncClient(headers={"x-demo-user": trusted_identity}) as http_client:
    async with streamable_http_client(mcp_url, http_client=http_client) as (read_stream, write_stream, _):
        async with ClientSession(read_stream, write_stream) as session:
            await session.initialize()
            await session.call_tool("get_sensitive_data", arguments={})

Testing

• All existing tests pass
• Added new tests for new functionality
• Manually tested the changes
• Updated documentation

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Screenshots (if applicable)

N/A (no UI changes)

Additional Context

This change is intentionally isolated under src/mock_mcp_auth_demo and does not alter existing production MCP/A2A flows.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• learn.microsoft.com
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Before you start
• Read Azure AI Foundry + MCP tool integration docs first.
• Look at my A2A server code to understand how Foundry calls are currently made.
• You do NOT need to fully run Foundry locally if credentials are missing — focus on a realistic mock aligned with how Foundry works.

Goal

Build a small isolated demo showing this pattern:

The application chooses a trusted user identity, and binds it to the MCP client when making an LLM call — so MCP authorization is enforced independently of anything the LLM says.

What to build

1. Mock MCP server
   • Create a new, isolated mock MCP server (don’t use existing one)
   • No database — use in-memory data
   • Include:
   • simple users list
   • simple permissions map
   • Add at least 2 tools, e.g.:
   • get_my_data
   • get_sensitive_data
   • Enforce authorization server-side using the user identity passed through the MCP session/request
   • Return clear errors for unauthorized access

2. Demo app flow

Create a small script or endpoint that:
• sets a trusted identity in code (e.g. "alice@example.com")
• initializes/configures an MCP client bound to that identity
• makes an LLM call (Foundry-style, based on repo patterns)
• allows the model to call MCP tools

Important:
• The user identity must come from the app code, NOT from the model output.

3. Show both cases
   • Authorized user → success
   • Unauthorized user → denied by MCP server

4. Public endpoint
   • MCP server needs to be publicly reachable
   • Use dev tunnels for this (totally fine for the demo)

Deliverables
• New mock MCP server code (isolated folder)
• Demo script / endpoint
• Short README explaining:
• where user identity is set
• how MCP client is bound to that user
• where authorization is enforced
• Clear run instructions

Key question this should answer

Can the app layer bind a trusted user identity to the MCP client during an LLM call, so MCP enforces auth regardless of what the LLM says?

Constraints
• Keep it minimal and readable
• Don’t overengineer
• Don’t modify production code heavily
• Prefer reusing existing repo patterns (especially A2A + Foundry call structure) unless changes are needed. Right now a2a foundry calls are simply retrieving an agent made in the foundry portal, you will probably need to either retrieve and modify the tool definitions, or create from scratch via code