We're building an MCP server for internal tool access, and our authorization logic is a mess. The protocol gives us tools (resources, prompts) but the spec is silent on *how* to decide who gets what. We've tried to bolt it on ourselves and now it's un-auditable.

The problem: authorization checks are scattered. We have them in:
* The initial connection handler (checking the client token against an allowlist)
* Individual resource `read` methods (checking if the user's department matches the resource "owner")
* Tool `execute` methods (checking ad-hoc permissions based on the tool name and arguments)
* And now we need to add data residency checks for resources hosted in specific regions.

This violates every compliance principle we have. There's no single source of truth for who can do what. Logging is inconsistent, so proving access controls for an audit means grepping across a dozen files.

We're using a mix of:
* JWT claims parsed at connection time
* Hard-coded role mappings in some tool functions
* Database lookups in others
* It's a policy enforcement nightmare.

What are others doing? We need a pattern that:
* Centralizes policy decisions (maybe a `PolicyEngine` class?)
* Works with MCP's nested context (client info, tool/resource name, parameters)
* Produces standardized audit logs suitable for SOX/GDPR purposes.
* Doesn't kill performance on every tool call.

Specific questions:
* Are you evaluating permissions at the session level, the tool level, or both?
* How are you mapping MCP client identities (like `clientInfo.name`) to your internal roles?
* Has anyone implemented a PEP/PDP pattern inside an MCP server successfully?
* Are we overcomplicating this? Should we just reject connections at the door if they don't have broad access?