Knowledge · MCP

    Tenant, role and entitlement enforcement in MCP

    Three separate gates every agent tool call must pass: the right organization, a role that holds the capability, and an entitlement that includes the module.

    What must an MCP tool call check before it runs?

    Three things, independently: the organization the caller belongs to, resolved on the server; whether the caller's role holds the capability the action requires; and whether the business's plan actually includes the module being touched. Passing one gate says nothing about the other two.

    Key takeaways

    • Organization is derived server-side from membership, never from the request.
    • Role checks are capability checks, not menu checks.
    • Entitlement is a commercial gate and is separate from permission.
    • A caller with ambiguous membership should fail closed.
    • Database policies re-check the same question at the row level.

    Why org_id must be derived, never accepted

    If an organization identifier can be supplied in a tool argument, the assistant can be persuaded to supply a different one. Deriving it from verified membership removes that entire class of problem: the caller cannot name a tenant, only be one.

    Ambiguity has to fail closed too. An identity that resolves to more than one organization is not a licence to pick one.

    Role is about capability, not visibility

    Agent access makes menu-based thinking dangerous, because an assistant never sees a menu. It calls the endpoint directly. The only meaningful role check is the one that asks whether this role holds this named capability, evaluated where the data lives.

    Entitlement is a third, different question

    • Permission asks: may this person do this.
    • Entitlement asks: does this business have this module at all.
    • A permitted user on a plan without the module should still be refused.
    • Refusals should be explicit, so the assistant reports a reason instead of guessing.

    Where URBLD fits

    URBLD resolves the organization from membership records on the server for every MCP call and rejects identities that do not resolve to exactly one organization. Each catalog action maps to a required capability, and row-level database policies apply the same tenant boundary underneath the application layer.

    FAQ

    Frequently Asked Questions

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

    More in MCP

    The protocol that lets AI do work instead of describing it.

    Browse MCP
    Share this page