Your MCP server exposes tools. Your agent calls them. Nobody in that sentence checked whether it should.
Most MCP deployments have no answer to "who authorised this question?"
Tool-level permissions aren't enough
The usual first attempt is binary: this agent may call query_warehouse. Business data isn't binary. The same tool needs to return different rows depending on who is behind the request.
That means identity has to survive the whole chain — user → agent → MCP server → query — and most implementations drop it at the server boundary, where the connection has its own service credentials.
What governance actually requires
| Requirement | Why it matters |
|---|---|
| Identity propagates to the query | Otherwise every caller is the service account |
| Entitlement evaluated per question | Not per tool, not per connection |
| Ambiguous or unauthorised intent fails to compile | Not filtered afterwards |
| Audit ties person → intent → SQL → result | The only defensible artefact |
The third row is the architectural one. If your answer to an unauthorised request is "we filter the result," the data already left the warehouse and you're describing a breach with extra steps.
Where to put it
Not in the agent — agents are the thing being governed. Not in the prompt — prompts are suggestions. In the layer that compiles the query.
Attach policy to business concepts rather than tables, evaluate it during context resolution, and inject RBAC, ABAC and row/column predicates before SQL is emitted. Then MCP governance stops being a policy document and becomes a property of the system.
The protocol is settled. What sits behind it is still your decision.
The full breakdown — the identity propagation model, policy composition across scopes, and the audit format — is here:
👉 Who Controls What an AI Agent Can Ask? Governance in an MCP World
Originally published at colrows.com/blogs/mcp-governance
Top comments (0)