Beitrag

–

Connecting remote MCP securely: demo project

Giving AI agents access to protected enterprise systems without thinking carefully about access security is not a good idea. In organizations, systems like GitLab are protected deliberately, and access is granted through users, roles, groups, and policies. An AI agent should be able to operate such systems safely, not bypass their security model.

What we want to show here is how connecting internal systems can unlock remarkable potential when it happens in a secure environment.

Use case

A team works with an agent such as Codex inside a project. During a development session, the agent discovers a defect in the source code. The developer instructs it to create a ticket in GitLab, describe the issue, and ideally document an initial proposal for a solution. Later, the same agent can work on that ticket either together with a developer or with a high degree of autonomy.

In a scenario like this, the agent needs secure access to protected resources in GitLab.

Open-source example

If you want to explore these ideas not only in theory but in a concrete technical setup, this open-source example is a useful starting point: Open-source project: mcp-oauth-demo.

Project takeaways

  • In enterprise environments, remote MCP is not just an interface topic. It is a question of identity and authorization.
  • OAuth 2.0, OpenID Connect, and PKCE keep passwords with the identity provider, not inside the client.
  • A protected MCP server must validate signature, issuer, audience, and roles cleanly.
  • Local or desktop-adjacent clients need a controlled browser login and a clean callback path.
  • A strong open-source demo makes security architecture concrete enough for teams to discuss seriously.

Tunneling with API keys

API keys absolutely have a legitimate place in automation. They are often used in CI/CD pipelines, scheduled jobs, or backend processes that run in a controlled environment. In those cases, a system usually operates inside clearly defined physical and logical boundaries, and credentials are managed carefully. A nightly build job on a dedicated build server is a good example. The process needs repository access and runs in an environment designed for exactly that purpose. Access to repositories is commonly granted through API keys or API tokens that authorize access to protected resources.

Credential theft

API tokens become problematic when they are used in security-sensitive AI workflows. That is increasingly common in agent-based automation and so-called vibe coding scenarios. Users describe a desired result, and an AI agent orchestrates the necessary steps. This approach can create quick wins, but it also encourages a dangerous shortcut: “Which API key do you need?” becomes a normal question regardless of where that key ends up. In most cases, this kind of vibe coding does not happen inside a protected boundary, at best only within the access rights of the currently signed-in user.

Chat logs are usually stored locally, synchronized to the cloud, inspected by tools, or pulled into future contexts. The moment credentials are revealed to an agent, control over them is already slipping away.

If a token appears in chat histories, prompt contexts, terminal histories, logs, screenshots, or generated configurations, it becomes easier to extract and abuse. An attacker will use the same automation and AI techniques to search for leaked credentials.

Credential proliferation

There is a second risk that is less obvious but just as dangerous: once credentials are known inside an agent context, they can also be used unintentionally. An agent with broad access can perform actions nobody meant to authorize simply because the necessary credentials are already available to it.

So the problem is not only the theft of secrets. It is also the potential damage to systems caused by credentials that are circulating without control.

Decisions in a professional environment

Of course, not every automation scenario carries the same risk. If someone wants to use an assistant to summarize appointments from a personal calendar or collect public specialist articles on a topic, they may consciously accept that risk. In a professional environment, however, competence matters. As soon as systems, source code, tickets, production data, or internal services are involved, credentials must be handled with much stricter discipline and within the applicable security policies.

Automation is fantastic. It can increase speed, reduce repetitive work, and improve process quality. But those advantages only hold when automation is designed deliberately and within clear rules.

These three rules form a minimal foundation:

  • Do not disclose credentials or API keys in AI chats. Never hand credentials to a party or channel you do not trust.
  • If credentials need to be exchanged, use a secure and encrypted channel that reflects the current state of the art.
  • Store credentials in a credential manager such as KeePass, Apple Keychain, or Windows Credential Manager. They do not belong in unencrypted files, improvised notes, or other places that tools and agents can easily read.

These rules are not new, and they are not specific to MCP. They are general security practices for handling confidential information. The same principles apply to any third party, any automation stack, and any sensitive information that is supposed to remain under controlled access.

First steps

This project demonstrates how an MCP server can operate inside a protected boundary while using Keycloak for user authentication and a server-side GitLab token for access to the GitLab API. The central point is simple: the MCP client, and therefore in many cases the AI agent, should receive neither the user’s password nor the GitLab API token. These are the intended usage scenarios when working with the agent:

  • “Analyze issue XY and create a ticket for it in the current project.”
  • “Resolve ticket #2345 and comment on your solution in the ticket.”
  • “Close ticket #2345.”

The demo shows in compact form how a protected MCP server can be connected to an identity provider. In this project setup, Keycloak is used as the OIDC provider, FastAPI as the protected Python application, FastMCP as the protected streamable HTTP MCP server, and a browser-based login via the authorization code flow with PKCE.

The decisive point is this: the user authenticates in the browser against Keycloak. Username and password do not need to be passed to the Python server. The server works with validated tokens instead and verifies signature, issuer, audience, and roles.

More than a login example

This project is not interesting simply because it combines AI and MCP with OAuth. It is interesting because it solves a recurring real-world integration problem in a form that is actually relevant for AI and MCP scenarios.

The demo makes it visible how a local or desktop-adjacent client triggers a browser login, how the callback for a localhost target is processed, how access tokens are then used for protected HTTP and MCP endpoints, and how the same identity checks are consistently enforced in front of MCP tools and resources.

That complete chain is missing from many early MCP examples. They often show only how to expose a tool. What they do not show is what authentication, authorization, and token validation look like in a setup that is truly relevant for enterprises.

What companies can take from this in practice

  • How internal systems can be combined with AI agents into genuinely powerful working systems.
  • What a clean login flow looks like for local or desktop-based clients.
  • How a remote MCP server can be connected to existing identity infrastructure.
  • Which claims and roles need to be validated on the server side.
  • How to prevent passwords or static credentials from ending up in the wrong places.
  • How the same security framework can be used for classic API endpoints and MCP alike.

For internal demos, architecture alignment, and security conversations, an example like this is often more valuable than a theoretical presentation. It shows not only the target state, but a realistic technical path to get there.

Why SilverQ frames the topic this way

Introducing AI agents is not only a question of tools and model vendors. The real potential lies in connecting systems that already exist, and that always includes the question of security and governance. Anyone who wants to integrate infrastructure productively needs to clarify early on how existing security principles can be extended to AI-supported access.

SilverQ helps companies answer these questions in practical terms and turn governance into something that actually works together with AI.

Conclusion

Introducing AI productively does not just mean choosing an agent and a vendor. It means designing governance in a way that lets AI tools work with real enterprise systems under control.

This demo project helps make those necessary steps tangible and shows how the productivity gains now available through AI can be unlocked with competence and confidence.

Demo project

Would you like more information on the topic or on the demo project?

Request an initial consultation

Sources