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
- 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.
- 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.
- 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.
- 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.