Can an assistant do more than the user who connected it?

It should not. The agent acts within that user's role and entitlements. Anything beyond that is a privilege escalation, not a feature.

Is the OAuth audience claim an authorization check?

No. It confirms the token was meant for this resource. Whether the identity may perform the action is a separate decision made against roles and records.

What happens when a role changes mid-session?

With per-call authorization, the next call reflects the new role. With connection-time caching, it does not.

Knowledge · MCP

Authentication vs authorization in MCP

Connecting an AI assistant to an MCP server proves identity. It does not grant permission. How authorization has to be re-evaluated on every tool call.

Does connecting an assistant to MCP grant it permission?

No. Authentication establishes which user the assistant is acting for. Authorization decides whether that user may run that specific tool on that specific record. A connected assistant with a valid token still has to pass a permission check on every single call, evaluated on the server.

Key takeaways

A connected client is an identified client, not an entitled one.
Permission is evaluated per tool call, never once at connection time.
The agent inherits the user's ceiling — it never exceeds it.
Authorization belongs on the server, beside the data.
Token audience and scope are not a substitute for role checks.

What the connection actually establishes

A completed authorization flow tells the server one thing: this stream of tool calls is being made on behalf of a known account. That is identity. It carries no statement about which records that account may read, which actions it may run, or whether the plan the business is on includes the module the tool touches.

Three checks that must run on every call

Tenant: which organization does this identity belong to, resolved server-side.
Role: does this role hold the capability the tool requires.
Entitlement: is the module the tool touches actually enabled for this business.

Why per-call evaluation is not optional

Sessions outlive permission changes. A user demoted this morning may hold a token minted last night. If entitlement is cached at connection time, the assistant keeps operating at yesterday's privilege level until the token expires. Re-checking on each call closes that window to a single request.

Where URBLD fits

URBLD's MCP server verifies a bearer token issued by the platform's own authorization server and then resolves the organization from membership records on the server side. Every action the catalog exposes is mapped to a required capability; a call whose action has no capability mapping fails a build-time parity check rather than shipping.

Security at URBLD

FAQ

Frequently Asked Questions

Straight answers about how URBLD runs the business end-to-end.

Related knowledge

MCP Security

OAuth MCP vs API-key MCP

Authentication vs authorization

Server-derived organization identity