Agents with no access aren’t useful, but agents with too much get shut down. Chalk MCP Gateway fixes that: give each agent the tools and data it needs, based on the user it's acting for, and nothing more. Agents never see the credentials for the systems they reach, and every tool call is checked against policy and traced.
Why agents stall in prototype
Agents become useful when they can act: query a database, open a ticket, read from an internal service, update a field. Today that usually means giving the agent an API key or a service account token directly.
That leaves the team approving the agent with four problems:
- Credentials live inside the agent or its sandbox, so revoking access means finding every place a key was copied.
- Nothing checks a call before it runs.
- Each service gets its own one-off auth setup. There's no single place to see or change what an agent can reach.
- When an agent does something unexpected, there's no record of which tool it called, with what arguments, or why the call was allowed.
Security teams won't approve agents that can reach internal systems without a policy check and an audit trail. So agents that work in a demo stay out of production.
How MCP Gateway works
MCP Gateway sits between your agents and the MCP servers they call. When an agent calls a tool, the gateway checks who the call is for, makes the call with credentials it holds, and returns the result.
Each MCP server is registered with its transport and credential type.
- Register once, scope per agent. You register approved MCP servers once, then choose which agents can use which tools.
- Agents never hold secrets. The credential exchange happens at the gateway. The agent and its sandbox never see the credentials for the system on the other end, and you rotate a secret in one place.
- Every call is checked against policy. A Rego policy evaluates each call on the user, scopes, backend, tool and arguments, and returns the decision with its reasons. You can simulate a new policy before you apply it, so you test what it will block beforehand.
- Every call is traced. Each MCP tool call records who called which tool, with which arguments, and what the policy decided. When an agent does something unexpected, you can see what it called and why the call was allowed.
The gateway works with MCP servers that use OAuth, plain HTTP or SSE, so one set of controls covers every tool instead of a separate auth setup per service. It runs with your Chalk deployment, and no tool traffic leaves your account unless you register an external server.
Example: an agent querying your data
Register Chalk's MCP server behind MCP Gateway and connect your Claude agent to the gateway. When the agent runs a SQL query against one of the restricted tables in your Chalk data sources, a policy that denies it blocks the call. Change the policy to allow it, and the trace shows the query the agent ran, its arguments, and the decision.
Where it fits
MCP Gateway is part of Chalk's platform for building production-ready AI. Model Gateway governs the LLMs your agents call, with per-key budgets, model allow-lists and failover. MCP Gateway governs their data and tools. They also work alongside:
- Sandboxes run agent-generated code in isolation. Pair them with MCP Gateway and there’s nothing in the sandbox to leak.
- Agent Evals replay an agent against historical data, with one cutoff time applied to every tool call. MCP Gateway is where Chalk enforces that cutoff, so an eval shows what the agent would have done with only what it could see at the time.
Try it today
MCP Gateway is built for platform, AI engineering and security teams that want agents reaching internal systems, with a policy check and a record of every call. If that's you, talk with the Chalk team today and we'll get you set up.
