MCPifex Security: Data Storage, Credentials and Tool Access

MCPifex security comes down to one rule: an MCP client can only call the tools you switched on for an instance. Anything else is refused by the gateway, including tools we never added to our catalog. This page covers what MCPifex stores, how your credentials are handled, how tool access is enforced, and how a session starts and ends.

What does MCPifex store?

An instance holds the settings its MCP server needs to run, plus the API key you generated for it. For PostgreSQL that means a host and password. For Google Search Console it means a connected Google account. A keyless server like Google Trends needs nothing.

The portal also keeps a call log for each instance and daily usage counts. You can see which tool a key called and when, not just that it signed in. To see which servers you can host, browse the marketplace.

How are credentials handled?

Credentials are encrypted in transit and masked in the portal once saved. Your MCPifex API key, which starts with mcpx_, shows as ••••••••••••, and so does a database password you saved for a server.

Click Test connection before you finish setup. It runs a real health-check tool call with the saved credentials, so a wrong password shows up right away instead of on your client's first request.

As of September 2026, Google Search Console is the hosted server that uses OAuth. It has a separate Connect Google account step. The Google account you connect doesn't have to be the one you sign in to the portal with.

How does the gateway enforce tool access?

The gateway checks every call itself. It doesn't rely on the MCP server package or the client to behave.

• tools/list only returns tools enabled on that instance. A disabled tool is invisible to the client.
• tools/call on a tool that exists but isn't enabled is refused.
• A tool that isn't in the MCPifex catalog for that server is always refused. No setting turns it on.

The PostgreSQL package's own connect_db tool is the example. It isn't in our catalog, so a client can never use it to point the server at a different database. Write tools such as execute start switched off, and you enable them one instance at a time. The instances and tools doc shows how.

What should you do on your side?

Give each instance the narrowest credential the server allows. For a query-only workload, use a read-only PostgreSQL role, not an admin login. For Search Console, connect an account that only has the property the agent needs.

Turn off tools the agent doesn't need, and revoke keys you no longer use. The fewer tools a key can reach, the less a leaked key can do. The MCP security guide covers why this matters for agents in particular.

How do sessions work?

Each client session gets its own isolated server process. It ends when the client closes the session or after it sits idle, and the next call from that client starts a fresh one.

If you revoke a key in the portal, new calls stop within about a minute. A session that's already open is cut off on its next tool call. The troubleshooting doc explains the errors a client can see, such as 401, instance_disabled and connection_revoked.