Keeping API keys out of your tool code
Encrypted project secrets, added to outbound requests by the egress gateway, so neither your code nor the calling client ever holds them.
In this post
- Where secrets live on Glxymesh
- What the calling client can and cannot see
- Where to read more
A tool that calls a payment API or a database needs a credential. That credential should never sit in source code, and it should never travel to the AI client that calls the tool.
Secrets belong to a project#
On Glxymesh, secrets are encrypted and scoped to a project. Each tool names the secrets it uses and binds each one to the hosts it may be sent to. The value never appears in your repository, your code or the tool's response.
Added on the way out#
Every request a tool makes leaves through the egress gateway. It checks the host is one the tool lists, then adds the bound secret as a header or a query parameter. Your code asks for the request; it never holds the key, so a bug or a log line can't leak it.
The client never sees them#
An AI client authenticates to your project with its own Glxymesh access token. When your tool calls a data or model API, that outbound call carries the service credential. The inbound MCP session never does.
- The client holds a Glxymesh access token
- The egress gateway adds the service key, only to the hosts it's bound to
- Each organization's data is kept separate
Read more#
The keys and network guide covers allowed hosts, storing keys and binding them: docs.glxymesh.com/guides/keys-and-network
