Skip to main content

Peliqan

Custom MCP Server Authentication and Authorization

Recent videos

Peliqan data platform

All-in-one Data Platform

Built-in data warehouse, superior data activation capabilities, and AI-powered development assistance.

Giving an AI assistant a tool is easy. The hard part is making sure it answers for the right person, with the right data. On a custom Peliqan MCP server, four layers handle that, and each one narrows what the assistant can reach.

The four layers

  1. 1Who is asking. Every request identifies a user before anything else runs. You can accept a personal API key, or you can use single sign-on through Google, Microsoft Entra or Peliqan itself. From then on the server holds a connection scoped to that person rather than to a shared service account.
  2. 2What data they reach. Peliqan groups decide which datasets each user sees. So the server lists only the datasets that sit in a group they belong to, and customer invoicing stays well away from HR data without any logic in your tool.
  3. 3Which tools they can use. Each tool carries its own minimum access level. Running a read-only query, drafting an invoice and sending one therefore sit at three different bars, so a junior can do the first without ever triggering the third.
  4. 4Which rows they can see. Finally, the query filters on the signed-in username and joins your own permissions table. That way a rep in Sales Europe gets Europe rows from the same tool that gives Sales USA theirs.

What each layer protects you from

  • Shared credentials: without the first layer, every answer comes from one service account, so you cannot tell who asked.
  • Over-broad access: without the second, a tool you built for sales quietly reaches HR data as well.
  • Read and write treated alike: without the third, anyone who can query can also send.
  • One team seeing another’s rows: without the fourth, a single tool hands the whole table to whoever calls it.

Where the credentials live

All four layers use the account and connections you already have. Because of that, credentials for the underlying systems stay in Peliqan instead of moving into the tool. Move someone between groups and their access follows them, so you never redeploy the server.

Ready to build this on your own data? Get started with Peliqan.

FAQs

No. The server acts as that user, so dataset access, tool access and row filters all resolve against their own permissions.

Not for datasets and tools, which use Peliqan groups and an access level per tool. Row level rules use your own permissions table, joined into the query.

Google, Microsoft Entra and Peliqan. A personal API key is the alternative when single sign-on is not an option.

Move them between Peliqan groups and their dataset access changes with them. There is nothing to redeploy on the MCP server.

Get instant access to all your company data

Connect 300+ sources, serve any BI tool, and give every AI agent one governed endpoint to read, and write back where the app supports it.