Access keys and revocation

1. IssueA key is created in your deployment, for one team or one tool.lc_…7f2a · sales team
2. ConnectThe client presents endpoint plus key. No key, no connection.endpoint + key
3. Use, loggedEvery call is recorded against the key: who, what, when.facet · orders · 09:14
4. RotateA new key on a schedule; the old one stops working.quarterly
5. RevokeA leaked or departed key is ended in a moment.revoked

No key, no connection

Every AI client that reaches your data through an MCP server does so with two things: the endpoint, which is an address, and an access key, which is permission. The address can be known by anyone; the key is what makes a connection possible. Without one, the server does not answer. That single rule is the whole access model, and everything on this page is about how keys are issued, used, rotated and ended.

Issued by you

Keys come from your deployment, not from the AI tool's vendor. When the sales team wants to use ChatGPT with the orders data, an administrator in your organization creates a key for that purpose and hands it over. The vendor of the AI tool never holds a credential to your data; it holds whatever a user pasted into a configuration screen, which you issued and can end. This is the difference between integrating your data with a tool and giving a tool your data.

What the client is given

• NameLipiCore
• Endpointhttps://lipicore.yourcompany.com/ai/mcp
• Access keylc_••••••••••••••••7f2a · revocable

One per team or tool

A single company-wide key is simple and wrong. The moment it leaks, every client is cut off when it is revoked, and the log cannot say which team asked what. One key per team, or per tool, keeps each decision small: the engineering key is rotated on its own schedule, the contractor's key is ended when the contract is, the pilot team's key is revoked when the pilot stops. The log, written against the key, tells you which of them has been asking what.

What a key can reach

A key opens the server, and the server publishes a list of tools; what the key can do is exactly that list. For business data the tools search, filter and aggregate over indexed collections, and a key cannot reach past them - not to the production database, which is never on the path, not to writes, which the server does not publish. Ask any vendor what a key can reach, in those terms, because the answer is the server's tool list, and a key is only as narrow as the list is.

Handing a key over

A key is only as safe as the way it travels. It should go into the client's configuration - the place ChatGPT, Claude or Cursor keeps its MCP servers - and nowhere else: not in a chat message, not in a shared document, not in a screenshot of the setup for the team wiki. The person who issues it should be the person who can revoke it, so that the two actions sit with the same role. And the client keeps the key, not the person: once it is configured, nobody has to remember it, which is the main reason a leaked key is usually a copied one. Treat the key like the credential it is, and the rest of the model does its job.

Rotation

Keys age. A key issued a year ago has been in more configuration files and more clipboards than anyone can account for, which is why keys are rotated on a schedule: a new key is issued, the client is updated, and the old key stops working. Rotation is cheap when keys are per team - one team updates one configuration - and expensive when a single key is everywhere, which is one more reason not to have one.

Revocation

Revocation is rotation without the replacement. A key that is leaked, a person who has left, a tool that is no longer approved: the key is ended in your deployment and the next call it makes is refused. Nothing else changes. The server, the data and every other key carry on. This is the moment the access model is judged, and the question to ask a vendor is how long it takes: it should be the time it takes to click.

The log

Because every call carries a key, every call can be recorded against one: the key, the tool, the arguments, the time: the sales key ran a facet over orders at 09:14. That record is what turns an AI rollout from a leap of faith into something reviewable - which teams use it, for what, how often - and what answers an auditor's question months later. A server that does not log per key cannot tell you who did what, and "who did what" is the question keys exist to answer. The enterprise MCP server places the log among the other things a team-grade server needs.

Keys and the boundary

Keys govern who may ask. They do not change what leaves: the requested results still go to the client that asked, and on to that client's AI provider, under your agreement with that provider. The key is the control on the door, and the door should be the only way in. Data flow map describes what passes through it.

Related

EXPLAINER The enterprise MCP server One endpoint a whole company connects to, inside its own infrastructure, with keys it issues and a log it owns. What a team-grade MCP server needs that a laptop one does not. EXPLAINER Data flow map: what leaves your environment, per product One boundary, four flows. What goes in, what stays, what goes out, to whom, and who controls it - for each product separately, because the honest answer differs. EXPLAINER MCP server explained A small service that publishes a list of tools and answers calls to them with structured results. For business data, the right tools are search, filter and aggregate over indexed collections - not raw SQL.