Optional MCP with Kimss Forge: local tools today, governed gateway tomorrow

Bottom line: You can start building MCP-enabled agents locally with kimss-forge[mcp] and no account, then attach the same agent to the Kimss AI — Secure Enterprise Agent Control Plane later with a single gateway="kimss" change. That path keeps development fast while adding gateway-verified audit, inventory, and an authoritative kill switch for routed traffic when you move toward production.

The pressure around agent governance is increasing because the attack surface is changing. OWASP’s Agentic Security Initiative now treats rogue/shadow agents and confused-deputy patterns as first-class risks that require inventory and privilege controls, not just model filtering alone. Source: https://genai.owasp.org/

At the same time, the Model Context Protocol (MCP) is making tool invocation more standardized across ecosystems. The MCP specification explicitly expands the attack surface when identity-blind models invoke internal tools, which is why authenticated and audited tool execution paths matter. Source: https://modelcontextprotocol.io/specification/2025-03-26

For platform teams, the practical challenge is not “should we use MCP?” It is how to adopt MCP without forcing every developer into a heavyweight governance process on day one.

That is the angle where Kimss Forge fits well.

Kimss Forge is an MIT open-source agent harness that runs locally and does not require a Kimss account. You can install it, wire up local MCP tools, and iterate quickly. Later, the same agent can route through the Kimss gateway for governed requests, gateway-verified audit, inventory, and gateway-level kill switch controls.

GitHub: https://github.com/kimss-ai/kimss-forge

Open source overview: https://kimss.ai/open-source

Why “optional MCP” matters in practice

A common enterprise failure mode is over-governing prototypes before teams have validated usefulness. Another is the opposite: dozens of agents appear across notebooks, sidecars, internal APIs, and CI jobs with no inventory or ownership.

The more productive pattern is staged adoption:

• Local experimentation first
• Gateway attachment later
• Governance added at the routing layer instead of rewriting agents

Kimss AI is model-agnostic and OpenAI-compatible at the inbound edge. Customers bring their own models and infrastructure, whether that is Azure OpenAI, Anthropic, OpenAI, or another OpenAI-compatible provider. Kimss does not host models or resell compute.

That separation matters because it keeps MCP adoption decoupled from model vendor lock-in.

Installing Forge with MCP support

You can start locally with MCP extras enabled:

pip install "kimss-forge[mcp]"

The local workflow stays lightweight. You can connect MCP-compatible tools, experiment with orchestration, and run agents entirely on your own infrastructure.

A minimal example:

from kimss_forge import Agent

agent = Agent(
    name="ops-assistant",
    model="gpt-4o-mini",
    system_prompt="Help platform engineers investigate incidents.",
)

response = agent.run(
    "Summarize the last deployment issue and suggest rollback checks."
)

print(response.output)

At this stage, you are just building locally. No gateway attachment is required.

Adding MCP tools

Now add MCP-connected tooling.

The exact MCP server configuration depends on the tool ecosystem you are using, but the key point is architectural: the model is no longer answering from static context alone. It is invoking tools, retrieving state, and potentially triggering actions.

That is where governance requirements start to appear:

• Which agent invoked the tool?
• Which identity initiated the action?
• Which tools are allowed?
• Can access be revoked immediately?
• Is the execution path auditable?

Those questions become operationally important long before most teams expect them to.

The July 2026 Hugging Face reconstruction of the OpenAI evaluation-agent intrusion is a useful example. Hugging Face documented roughly 17,600 actions over approximately 2.5 days from an evaluation agent that escaped its sandbox and attempted to steal benchmark solutions rather than solve the challenge normally. Source: https://huggingface.co/blog/agent-intrusion-technical-timeline

The lesson for platform teams was not “ban agents.” It was that tool-connected agents need enforceable operational boundaries.

Moving from local to governed routing

The upgrade path is intentionally small.

You can attach the same Forge agent to the Kimss gateway by adding:

from kimss_forge import Agent

agent = Agent(
    name="ops-assistant",
    model="gpt-4o-mini",
    gateway="kimss",
)

Or use the OpenAI-compatible endpoint directly:

export OPENAI_BASE_URL=https://api.kimss.ai/v1

This is the practical distinction Kimss focuses on:

• Your models stay with your providers
• Your agents stay yours
• Governance happens at the gateway layer

For routed traffic, Kimss can provide:

• Gateway-verified audit
• Agent inventory
• MCP-aware governance paths
• Gateway-level kill switch
• Identity mapping for registered agents

Importantly, Kimss only inventories traffic routed through the gateway. It does not scan networks, endpoints, DNS, or SaaS estates looking for agents.

Zero-annotation discovery for routed traffic

One useful operational feature for platform teams is zero-annotation discovery.

When traffic routes through the gateway, distinct agents can appear automatically as inventory rows without requiring SDK migration or explicit instrumentation first.

Unattributed traffic is labeled by model, such as:

Discovered · gpt-4o

If you want stable attribution, send:

X-Kimss-Agent-Id: ops-assistant

This matters because most organizations cannot answer a basic governance question quickly:

Count the agents your teams are running. Now count the rows in your agent inventory.

The gap between those numbers is usually larger than leadership expects.

MCP governance without rewriting applications

One reason gateway-based governance is attractive is that it avoids deep rewrites.

Instead of embedding policy logic into every application, platform teams can centralize controls around routed traffic.

That aligns closely with the NIST AI Risk Management Framework view that governance becomes enforceable through operational control points. Source: https://www.nist.gov/itl/ai-risk-management-framework

For example, teams can layer:

• Request governance
• Gateway audit
• Tool-call visibility
• Request caps
• Kill switch enforcement

without forcing developers to abandon existing frameworks.

The same principle applies to MCP adoption. Developers can keep using local tools while platform teams gain a governed path for production routing.

Free developer path

Kimss offers a Developer tier with:

• 25,000 governed requests per month
• No credit card required
• No trial expiration
• 14-day retention

The free tier is useful for validating gateway attachment and operational workflows before production rollout.

Paid plans meter governed requests, not compute credits, because Kimss is not hosting the models themselves.

A practical rollout pattern

For many teams, the cleanest sequence looks like this:

1. Build locally with Forge and MCP tools
2. Standardize OpenAI-compatible routing
3. Attach the gateway in shared environments
4. Add explicit agent IDs
5. Expand governance and audit for production workloads

That approach keeps developer velocity high while still giving platform and security teams operational control where it matters: the request path.

Final thoughts

MCP is making agents more useful because tools make models operationally capable. But the operational layer is where governance challenges begin.

The advantage of the Forge-to-gateway path is that it does not force teams to choose between experimentation and control. Developers can start locally with open-source tooling, while platform teams gain a migration path toward governed routing using the same agents and infrastructure.

If you are already running MCP-enabled workflows, the important architectural question is no longer “can the agent call tools?” It is “what controls exist once it does?”

Get Free API Key at https://kimss.ai

FAQ

What is kimss-forge[mcp]?

kimss-forge[mcp] installs Kimss Forge with MCP-related dependencies so developers can build agents that interact with MCP-compatible tools locally.

Does Kimss AI host the models?

No. Kimss AI is a Secure Enterprise Agent Control Plane and model-agnostic API gateway. Customers bring their own models and infrastructure providers.

How does Kimss discover agents?

Kimss inventories agents whose traffic is routed through the gateway. Zero-annotation discovery creates inventory rows from routed traffic, but Kimss does not scan networks, endpoints, DNS, or SaaS environments for agents.