DEV Community: Juan Antonio Osorio

Bringing AI Agents to CI/CD: Using ToolHive and Buildkite to Bring Intelligence to Vulnerability Scanning

Juan Antonio Osorio — Mon, 18 Aug 2025 18:14:16 +0000

Continuous Integration and Continuous Deployment (CI/CD) pipelines have traditionally relied on deterministic scripts and predefined workflows, offering predictable results. What if your CI/CD pipeline could think, analyze, and make intelligent decisions? What if it could adapt to complex scenarios, understand context, and provide insights beyond simple pass/fail results?

This is where agentic workflows come in. With the new ToolHive Buildkite Plugin, you can now seamlessly integrate AI agents into your CI/CD pipelines using the Model Context Protocol (MCP).

Use Case: Agentic Vulnerability Scanning

Traditional CI/CD treats all issues equally. A medium-severity CVE gets the same treatment whether it's in a critical path or an unused dependency. Agents change this by understanding:

Context: Where and how a vulnerability can be exploited in your specific architecture.
Impact: The actual risk to your application, not just a generic score.
Remediation: Specific steps that work for your codebase, not generic advice.

Instead of a binary pass/fail, you get nuanced analysis with actionable recommendations. The agent doesn't just tell you there's a problem – it explains why it matters and how to fix it.

In the context of CI/CD, this means your pipeline can become more than just a series of tests – it becomes an intelligent system that understands your codebase, security posture, and deployment requirements. The technology stack for this approach: MCP, ToolHive, and Buildkite.

ToolHive: The MCP Engine

ToolHive is your starting point for running MCP in production. It handles:

Server Lifecycle: Starting, stopping, and managing MCP server instances.
Transport Methods: Supporting multiple communication protocols (stdio, SSE, streamable-http).
Security: Managing secrets, permissions, and isolation.
Discovery: Providing a registry of available MCP servers.

Buildkite: The CI/CD Platform

Buildkite provides a flexible, scalable CI/CD platform that's perfect for running agentic workflows because of its:

Plugin Architecture: Extensible system for adding functionality.
Container Support: Native Docker/Podman integration.
Parallel Execution: Ability to run multiple agents simultaneously.
Artifact Management: Built-in support for storing and sharing results.

How the ToolHive Buildkite Plugin Works

To bring this use case — agentic vulnerability scanning — to life, we created the ToolHive Buildkite Plugin. It bridges these technologies and enables you to spawn MCP servers directly in your CI/CD pipeline. Here's how it works:

Plugin Configuration

In your Buildkite pipeline, you simply add the plugin to any step:

steps:
  - label: "🔍 Security Analysis"
    command: "run-security-scan"
    plugins:
      - StacklokLabs/toolhive#v0.0.2:
          server: "osv"  # OSV vulnerability database server
          transport: "sse"
          proxy-port: 8080

Automatic MCP Server Provisioning

When the pipeline runs, the plugin:

Downloads ToolHive if not already available.
Spawns the MCP server in a containerized environment.
Configures networking to make the server accessible to your agent.
Manages lifecycle ensuring proper cleanup after execution.

Agent Connection

Your AI agent can then connect to the MCP server and use its tools. Here's a snippet from a simple Python agent using the PydanticAI framework:

from pydantic_ai import Agent
from pydantic_ai.mcp import MCPServerSSE

# Connect to the MCP server spawned by the plugin
osv_server = MCPServerSSE("http://localhost:8080/sse")

# Create an agent with access to OSV tools
agent = Agent(
    model=model,
    mcp_servers=[osv_server],
    system_prompt="You are a security analyst..."
)

# The agent can now use OSV tools to analyze vulnerabilities
result = await agent.run("Analyze security vulnerabilities...")

Real-World Example: Intelligent Vulnerability Scanning

Let's look at a concrete example from our demo repository that showcases agentic vulnerability scanning, comparing a traditional approach to an agentic approach

Traditional CI/CD Security Scanning:

# Run a vulnerability scanner
osv-scanner --json > results.json

# Check if any high severity vulnerabilities exist
if grep -q '"severity": "HIGH"' results.json; then
  echo "High severity vulnerabilities found!"
  exit 1
fi

This approach is limited in several ways. There’s a binary pass/fail decision, no context or explanation, no intelligent categorization and no actionable recommendations. In short, it’s functional, but not very useful.

Agentic Security Scanning:

steps:
  - label: "🔍 Intelligent Vulnerability Analysis"
    command: |
      uv run buildkite-demo-agent \
        --packages-file examples/packages.json \
        --fail-on-vulnerabilities \
        --severity-threshold high
    plugins:
      - StacklokLabs/toolhive#v0.0.2:
          server: "osv"
          transport: "sse"

This agent provides a lot more value. It will deliver intelligent analysis by using Claude Code to understand vulnerability context; it will classify the severity of CVEs based on actual impact and not just CVSS scores; and it will offer detailed explanations and specific remediation steps.

The Agent's Intelligence in Action

Here's what happens when the agent analyzes a vulnerability:

Query OSV Database: The agent uses MCP tools to query vulnerability data.
Contextual Analysis: Claude analyzes the vulnerability considering:
- The specific package and version
- The type of vulnerability (RCE, DoS, data exposure)
- The ecosystem and common usage patterns
Intelligent Categorization: Instead of relying solely on CVSS scores, the agent considers:
- Exploitability in your environment
- Actual impact on your application
- Availability of patches or workarounds
Structured Output: Returns actionable information:

Conclusion

There’s a lot of energy around MCP, and we need to channel that into putting the protocol to work in production environments. Agentic vulnerability scanning is a compelling use case and it hints at the potential of agentic workflows in CI/CD pipelines. If you want to give this a try, we created the ToolHive Buildkite Plugin to be simple and secure. Of course, we also encourage you to check out ToolHive for other MCP use cases; you can explore our GitHub repo or reach out directly via Discord.

Vibe Coding an MCP Server (with ToolHive)

Juan Antonio Osorio — Fri, 30 May 2025 08:42:04 +0000

I’ve been writing MCP servers for fun and profit lately, and noticed that with the right tools, it’s not just easy — it’s actually pretty fun!

A few people have asked for a guide on how I set things up. So here it is: my day-to-day stack, a working philosophy, and an example that you can reuse. This isn’t just a tech guide — it’s how to vibe while building real stuff.

🐝 The Stack I Use

🔧 ToolHive (core runtime)

Disclaimer: I am a maintainer in the ToolHive project. That being said, I do use the tool in my day-to-day, so I consider it a foundational piece of my workflow. ToolHive is a lightweight, developer-friendly MCP runtime I use to run, test, and deploy MCP servers — whether they’re containerized or not. It handles authentication, transports, and common runtime concerns so I can focus on building servers, not plumbing.

Servers I use ToolHive to run every day:

fetch: Lets the AI client fetch URLs and embed markdown into context.
github: Lets the AI client read GitHub repositories and create PRs.

ToolHive is open source and flexible — it can run your server locally or as a container without requiring a Dockerfile. Just point it to a Go binary or MCP server image and go.

🛠️ Check out ToolHive

💻 Golang + `mcp-go`

Go makes writing MCP servers minimal and straightforward. I’ve been using mcp-go and mcp-go/server to implement the protocol, and it’s been incredibly smooth.

🐳 ko (build tool)

I use ko to build container images for my Go projects without needing Dockerfiles. It produces minimal, secure, and production-ready containers — great for MCP servers.

🔍 Testing & Linting

testify – for expressive Go unit tests
golangci-lint – for enforcing style and catching issues early

🌐 Anthropic’s Claude Sonnet 4

I’ve been using Claude Sonnet 4 with a lot of success lately. It’s great for coding!

🦘 Roo Code

Roo Code provides just what I need in terms of an LLM client. I don’t have a very complex setup, just MCP servers with the LLM I mentioned above, plus some custom prompts to take my Fedora Silverblue + toolbox Linux setup into account.

🌱 Philosophy: Vibe Coding Principles

Here are the core values I follow when writing MCP servers:

Principle	Why it matters
Minimalism	Don’t over-engineer. Use the fewest tools that do the job well.
Observability	Understand every layer: protocols, requests, and failures.
Security	Prefer non-root containers, minimal base images, and validated input.
KISS + DRY	Simplicity and reuse always win over clever hacks.
Rapid feedback	Run tests and linters constantly to stay in flow.
Dev-First UX	Use tools like ToolHive that reduce friction and empower iteration.

💡 Sample Prompt

Here's the kind of prompt I give myself when starting a new MCP server:

I'd like to start a new golang project. It'll be an MCP server that queries an OCI registry and image references. It'll be an SSE MCP server. We'll be using https://pkg.go.dev/github.com/mark3labs/mcp-go/mcp and https://pkg.go.dev/github.com/mark3labs/mcp-go/server so query those before going forward. Also, query https://pkg.go.dev/github.com/google/go-containerregistry and its subpackages since I'd like to use that library to query the registry. Let's gather all the information and plan ahead first. I'd like to have a very minimal and handy set of tools only. Let's also write tests using testify and run those often. Finally, in the container use golangci-lint to lint.

Run linting tools and unit tests often to ensure changes are correct.

Please think step by step about whether there exists a less over-engineered and yet simpler, more elegant, and more robust solution to the problem that accords with KISS and DRY principles.

You can copy this and adjust it for your own project — it's like setting your mindset before you even write the first main().

🏗️ Vibe Coding Dev Loop

I wish I could tell you that I just press enter and forget; But this is not the case. While I do allow the client to read files in the repository (I never have secrets in the repository anyways), I don’t allow any execute or write operations. So, I tend to read all diffs, and verify what the LLM is trying to execute. I look at this as more of a pair-programming exercise, where I have a conversation with the LLM and ensure it’s going the right way and following best practices. Sometimes this may be very fast, sometimes, not so much.

🧪 Dev Loop with ToolHive

ToolHive makes it easy to go from idea → tested server → deployed runtime:

1. Write your MCP server in Go using mcp-go
2. Add tests with testify
3. Add linting with golangci-lint
4. Build with ko (or just run it directly via ToolHive!)
5. Test locally with ToolHive:
   $ thv run go://./cmd/my-server
6. Iterate fast, deploy when ready

You can run SSE servers, HTTP-based ones, or even non-containerized ones locally using just a single thv run command.

🔒Lock it down!

Finally, don't forget that the regular software engineering best practices apply:

Do automatic updates
Use minimal container images
Run vulnerability scanning constantly
Set up vulnerability disclosure
Publish signatures and provenance
Publish an SBOM

All of these things are easy to do and you can even leverage an LLM to help you implement these!

Don't worry! In ToolHive we'll soon publish a list of heuristics for you to follow to publish a quality MCP server... Stay tuned!

🧭 TL;DR

Leverage MCP servers to enhance your workflow. fetch and github are great!
Write servers in Go with mcp-go and go-containerregistry
Build minimal, secure images with ko
Keep dev feedback tight: testify + golangci-lint
Start with a clear prompt and let simplicity guide the implementation
Use ToolHive to simplify running and testing MCP servers

No Dockerfile? No problem! Running Node and Python MCPs with ToolHive

Juan Antonio Osorio — Thu, 24 Apr 2025 06:23:40 +0000

Containerizing your MCP server is great—until it isn’t. Maybe you're moving fast, testing a new idea, or you just don’t want to write a Dockerfile. We’ve been there.

That’s why ToolHive now supports running MCP servers powered by npm or uv, without needing them to be containerized up front.

ToolHive will now dynamically build a container image for you based on the MCP reference. That means:

No Dockerfile.
No need to install uv or npm on your system.
Just write your code and run.

How it works

We’ve added support for special transport-prefixed references to MCP servers:

For Node.js projects:

thv run npx://my-cool-server

For Python projects using uv:

thv run uvx://my-python-server

When ToolHive sees one of these prefixes (npx:// or uvx://), it knows to:

Build a container image dynamically behind the scenes
Include the appropriate runtime (Node.js or Python + uv)
Execute your server just like any other MCP—no container authoring required

This all happens without you needing to install npm, npx, or uv on your local machine.

Why this matters

This feature is a huge win for:

Quick iterations: Skip the Dockerfile and get straight to testing.
Lightweight environments: Don’t want to install runtime tools globally? No problem.
Clean CI/CD pipelines: ToolHive encapsulates the runtime without polluting your environment.

It’s never been easier to run an MCP server with ToolHive, even if all you’ve got is a main.py or index.js.

Behind the magic

Under the hood, ToolHive builds a container image on-the-fly using the MCP reference you pass in. It wraps your package with the right runtime environment and proxies traffic into it, just like any other server launched through ToolHive.

This means you get all the benefits of the ToolHive runtime—clean shutdown, traffic proxying, process supervision—without needing to containerize anything yourself.

Get started

Just run:

thv run npx://<your-npm-package>

thv run uvx://<your-python-package>

ToolHive will take it from there.

E.g. If you’re interested in running the Playwright MCP, simply do:

thv run npx://@playwright/mcp@latest

For more details, check out the README .

Try it out and join the fun!

We're excited to keep making ToolHive easier to use, especially for devs who want to focus on building—not on container plumbing. Got feedback or ideas? Open an issue or talk to us on Discord. We’d love to hear from you.

Happy hacking 🐝

Secure-by-Default Authorization for MCP Servers powered by ToolHive

Juan Antonio Osorio — Wed, 16 Apr 2025 05:50:44 +0000

As more teams start deploying MCP servers to power tool-calling agents, one question comes up fast: how do you control who can call what? It’s not just about verifying identity, it’s about enforcing the right permissions, without bloating every server with bespoke auth logic. ToolHive was built to solve exactly this problem. It separates authentication from authorization, integrates cleanly with existing identity providers, and uses Amazon’s Cedar policy language to define clear, auditable access rules. The result is a simple but powerful way to lock down tool access without embedding auth logic into every server you run.

Authentication vs Authorization: Separate Concerns

In my previous blog post, I outlined a fundamental design choice in ToolHive: the strong separation of authentication (authN) and authorization (authZ). Authentication verifies identity (proving who you are), while authorization determines what that identity is allowed to do. ToolHive treats these as two distinct steps – first authenticate the caller, then check what they can access. In practice, ToolHive uses OpenID Connect (OIDC) to handle authentication (e.g., verifying a user's JWT from a trusted identity provider) and only afterwards applies its own permission rules for MCP actions. By explicitly separating authN and authZ, ToolHive can rely on well-proven identity systems and avoid conflating identity with access control, leading to a cleaner, more secure design. This separation matters because it lets ToolHive plug into existing single sign-on/IdP solutions for identifying users, while maintaining a clear, flexible policy model for what those users can do within MCP servers.

ToolHive’s Authorization Framework Overview

A few weeks ago, I had lunch with Lucas Käldström and had a good chat about authorization primitives and the work he’s been doing with Amazon’s Cedar policy language in relation to Kubernetes. Let’s just say that chat was exciting enough for me to try it out, and an authorization framework for ToolHive was born!

As mentioned before, ToolHive’s authorization system is built on Amazon’s Cedar policy language and is designed as a layer on top of the base MCP server. This authorization layer is tightly integrated with ToolHive’s existing JWT-based authentication middleware. In a typical deployment, the request flow is: a JWT validator middleware first verifies the user's identity token, and then the Cedar authorization middleware runs next. This means ToolHive acts as a gateway in front of the MCP server, handling auth on the server’s behalf. The MCP server itself doesn’t need to implement OAuth or check tokens – ToolHive has it covered.

How Authorization Works in ToolHive

Once an MCP server is launched with ToolHive’s authZ enabled (by passing an --authz-config file), every client request goes through an authorization check before reaching the server logic. At a high level, the process is as follows:

Authenticate – ToolHive’s JWT middleware verifies the client’s token (e.g., an OIDC ID token or other JWT) and, if valid, attaches the user’s identity and claims to the request context. This tells ToolHive who is making the request (the principal).
Extract Request Info – The authorization middleware then examines the incoming MCP request. It determines what operation is being attempted and on what resource. For example, it might see a JSON-RPC call for the method tools/call with tool name "weather". From this, ToolHive derives the Action (like "call_tool") and the Resource (like the "weather" tool) being requested.
Policy Evaluation – ToolHive invokes the Cedar authorizer with the gathered context (the principal identity, the action type, and the resource target). The Cedar engine checks the loaded policies to decide if this principal is permitted to perform that action on that resource. This evaluation considers any relevant policy rules defined in the config file, including conditions based on user attributes or tool attributes (more on this below).
Allow or Deny – If the policies permit the action, the request is forwarded to the MCP server’s normal processing. If not (no policy allowed it, or an explicit deny policy matches), ToolHive stops the request and returns an HTTP 403 Forbidden error (or an error in the SSE/JSON-RPC response) to the client. The MCP server never sees unauthorized requests.

In essence, ToolHive acts as a policy enforcement point in front of the MCP server. Unauthorized tool invocations, prompt fetches, etc., are blocked at the gate. This design greatly reduces the risk of a malicious or unauthorized request ever hitting the actual model server logic.

Policy Model: Cedar in ToolHive

The heart of ToolHive’s authorization is the Cedar policy language. Cedar is a flexible, expressive, and formally verified language for access control, supporting both role-based and attribute-based rules. ToolHive leverages Cedar to define who can do what in terms of MCP operations.

Principals, Actions, Resources: In Cedar (and ToolHive’s usage), every access policy involves these three entities. ToolHive defines them in the context of MCP as follows:

Principal – the client or user making the request. In ToolHive, principals are identified by the OIDC/JWT subject. For example, a user with ID "user123" would be represented as Client::user123 in policies. (ToolHive uses a Client entity type for principals.)
Action – the operation being performed. ToolHive categorizes MCP operations like calling a tool, reading a resource, listing prompts, etc. Examples include Action::"call_tool", Action::"get_prompt", Action::"list_tools", and so on. The authorization middleware translates each incoming request to the appropriate action tag.
Resource – the target object of the action. This could be a specific tool name, a prompt name, or a resource identifier. In policies, resources are namespaced by type, like Tool::"weather" for the "weather" tool, Prompt::"greeting" for the "greeting" prompt, Resource::"data" for a resource called "data", or even a category like FeatureType::"tool" to represent “any tool” in a list operation.

Using these, you can write fine-grained rules. A Cedar policy generally looks like:

permit(principal, action, resource) when { <conditions> };

This means "allow this principal performing this action on this resource if certain conditions hold." (Cedar also supports forbid rules to explicitly disallow actions.) In ToolHive’s config, policies are defined as strings. For example, the ToolHive docs show a simple policy set that permits any user to call the "weather" tool, get the "greeting" prompt, and read the "data" resource:

{
  "version": "1.0",
  "type": "cedarv1",
  "cedar": {
    "policies": [
      "permit(principal, action == Action::\\\"call_tool\\\", resource == Tool::\\\"weather\\\");",
      "permit(principal, action == Action::\\\"get_prompt\\\", resource == Prompt::\\\"greeting\\\");",
      "permit(principal, action == Action::\\\"read_resource\\\", resource == Resource::\\\"data\\\");"
    ],
    "entities_json": "[]"
  }
}

Each string in the policies array is a Cedar rule. For instance, the first rule above says any principal can call_tool on the weather tool. If a request comes in to invoke the weather tool, this policy would allow it (assuming no conflicting denies).

Attributes and Conditions: One of the strengths of Cedar (and ToolHive’s approach) is the ability to use attributes in policies for richer conditions – this is essentially attribute-based access control (ABAC). ToolHive’s middleware automatically makes certain attributes available to policies:

JWT Claims – All standard claims from the authenticated user's JWT are added as attributes on the principal, prefixed with claim_. For example, if a user's token has a claim roles: ["admin"], then in policy you can refer to principal.claim_roles to check that. A policy might require principal.claim_roles.contains("admin") in its condition to restrict an action to admins only. Similarly, principal.claim_name could be their name, etc., allowing policies to target specific users or user properties.
Tool Arguments – If the MCP action involves calling a tool with arguments (for example, a calculator tool with an operation argument "add" vs "subtract"), those arguments are exposed as attributes on the resource, prefixed with arg_ . This means policies can even inspect the parameters of a tool invocation. For instance, you could allow use of a tool only for certain argument values. The ToolHive docs show a policy that permits calling the "calculator" tool only if the operation is "add" or "subtract", by checking resource.arg_operation in the policy condition.

For convenience, these attributes are also exposed in the authorizer’s context. That is, you can access them via the context key.

Additionally, administrators can define custom resource attributes via the entities_json in the config. This JSON string can enumerate entities (like specific tools) with custom attributes (like an owner or sensitivity label). At runtime, the Cedar authorizer will include those entity definitions. For example, you could mark the "weather" tool entity with an "owner": "user123" attribute, and then write a policy that permits access only if resource.owner == principal.claim_sub . This would mean only the owner of a tool can use it, effectively implementing per-tool ownership controls.

Policy Decision Logic: ToolHive’s policy evaluation follows a secure-by-default logic: if nothing explicitly allows a request, it’s denied. In fact, Cedar policies can be either permit or forbid rules, and ToolHive applies them with deny precedence – any matching forbid rule will override permits. During evaluation: (1) if any forbid policy matches, the request is denied; (2) otherwise, if any permit policy matches, the request is allowed; (3) if no policies match, the request is denied by default. This default-deny approach ensures that in the absence of a rule, access is not allowed (principle of least privilege). As a ToolHive admin, you therefore list out what is permitted (and optionally what is explicitly forbidden), and everything else is automatically blocked.

Example: Writing and Using Policies

Let’s illustrate a few typical authorization rules you might implement in ToolHive (using Cedar syntax):

Allow everyone to use a specific tool: For instance, to open up a weather info tool to all users, you’d add a policy:

permit(principal, action == Action::"call_tool", resource == Tool::"weather");

This means any authenticated principal can call the weather tool. (You might pair this with other policies to keep other tools locked down.)

Restrict a tool to certain users: Suppose only the user with ID "alice123" should use an internal admin tool. You could write:

permit(principal == Client::"alice123", action == Action::"call_tool", resource == Tool::"admin_tool");

This permits only that specific user (principal) to call the admin_tool. No one else’s principal ID will match, so others will be denied (by default).

Role-based rule: If your JWT tokens include roles, you can use them. For example:

permit(principal, action == Action::"call_tool", resource) 
  when { principal.claim_roles.contains("premium") };

This would allow any user with the role "premium" to call any tool (maybe to grant paying users access to certain features), while denying calls from users without that role.

Tool argument condition: As mentioned, you can gate based on tool parameters. For a calculator tool that has an argument "operation", you might write:

permit(principal, action == Action::"call_tool", resource == Tool::"calculator") 
  when { resource.arg_operation == "add" || resource.arg_operation == "subtract" };

This ensures the calculator tool can only be used for addition or subtraction, and would block other operations like "multiply" if the tool supports them.

These examples show the expressive power of ToolHive’s authorization policies. This approach makes it easy for developers and operators to reason about who can do what on their MCP servers without modifying the server code itself.

ToolHive vs. MCP Specification’s Authorization Guidance

It’s worth noting how ToolHive’s approach compares to the official Model Context Protocol (MCP) specification’s guidance on authorization. The MCP spec (as of the 2025-03-26 revision) outlines an OAuth 2.1-based authorization model for HTTP transports. In other words, an MCP server could implement a standard OAuth flow: clients obtain an access token (via some OAuth authorization server), present that token to the MCP server, and the server validates it and checks scopes/permissions. The spec makes this kind of transport-level authorization optional but recommended for HTTP-based MCP servers. It even describes a scenario where an MCP server might delegate to an external OAuth provider (like redirecting the user to sign in with a third-party, then exchanging tokens).

ToolHive takes a different path. Rather than turning every MCP server into an OAuth resource server (or running a full OAuth authorization dance for each tool), ToolHive centralizes auth in its proxy layer. It uses OIDC for authentication (OAuth2 under the hood, but handled by an external IdP) and then its Cedar policy engine for fine-grained authorization. This means as a developer or admin, you don't have to implement OAuth flows in each MCP server or manage scope definitions for each tool. Instead, you configure ToolHive with the identity provider of your choice (Google, GitHub, corporate SSO, etc. for OIDC login) and write straightforward policies to declare what’s allowed. The heavy lifting of token verification is done once in ToolHive’s front door, and the permission logic is under your control via Cedar policies.

In summary, the MCP spec focuses on a standardized mechanism (OAuth 2.1) to allow clients to access restricted servers – great for interoperability, but it can be complex to implement directly. ToolHive’s approach is built for convenience and control: it uses standard OIDC to know who the user is, but then gives you a powerful, code-driven way to define authorization rules without a separate OAuth service for each server. This approach trades the spec’s one-size-fits-all OAuth solution for a more flexible policy model that is easily tailored to the needs of different tools and deployments.

Security and Usability

ToolHive’s approach to authorization within MCP emphasizes secure defaults, integration with existing identity systems, and a developer-friendly policy model. By separating authN and authZ, using a powerful policy language, and acting as a smart proxy, ToolHive achieves a balance of security and usability. Developers can spin up MCP servers with confidence that only the right people (or services) can invoke the right tools, all configured through a clear and versionable policy file. This makes running MCP servers in production (especially in enterprise environments) much more manageable and auditable, without sacrificing the flexibility that makes the Model Context Protocol so powerful.

Getting Authentication Right is Critical to Running MCP Servers

Juan Antonio Osorio — Mon, 14 Apr 2025 06:16:35 +0000

Any time you’re connecting APIs, you have to consider security implications. The same is true for Model Context Protocol Servers. In our experience, it’s important to have a strong separation of authentication (verifying who you are) and authorization (deciding what you can do).

We built ToolHive to make it easier and more secure to run MCP Servers. In this post, we’ll explore why ToolHive leverages OpenID Connect (OIDC) for authentication, how it distinguishes authn vs authz, and real-world scenarios it enables – from Google sign-ins to Kubernetes service tokens. (A follow-up post will dive into ToolHive’s built-in authorization framework in detail.)

Authentication vs Authorization in ToolHive

It’s crucial to understand the difference between authentication (authn) and authorization (authz). Authentication is about identity – proving who is making a request (e.g. via a login or token). Authorization is about permissions – determining if that identity is allowed to perform a given action. ToolHive treats these as separate concerns.

In practice, this means ToolHive first ensures it knows who the caller is (authenticating via OIDC), and only then applies rules about what that caller can do (ToolHive’s own permission model). By explicitly separating authn and authz, ToolHive can rely on well-proven identity systems for authentication and avoid conflating identity with access control. This leads to a cleaner, more secure design.

Why OpenID Connect for Authentication?

OpenID Connect (OIDC) is a widely adopted protocol for user authentication built on OAuth 2.0. It provides a standard way to get an identity token (usually a JWT) that confirms a user’s identity, issued by a trusted Identity Provider (IdP). In other words, OIDC lets ToolHive outsource the heavy lifting of verifying identities to providers like Google, GitHub, or corporate SSO systems, and then consume a verifiable assertion of the user’s identity (How OpenID Connect Works - OpenID Foundation). This has several advantages:

Standard and Interoperable – OIDC is an interoperable auth protocol based on OAuth2, simplifying identity verification. Because of this, ToolHive can integrate with any OIDC-compliant identity provider without custom code. The protocol even supports features like discovery and JWT signature verification out-of-the-box, making integration easier and less error-prone.
Proven and Secure – By using OIDC, ToolHive leverages the security of battle-tested identity systems. OIDC providers handle the user login UI, multi-factor auth, password storage, etc., so ToolHive itself never sees raw passwords or credentials. ToolHive simply trusts the ID token from the provider if it’s correctly signed and not expired.
Decoupled Identity Management – Adopting OIDC means ToolHive doesn’t have to be its own identity service. Instead of reinventing user management, it “piggybacks” on existing identity solutions. For organizations, this is huge: you can plug ToolHive into your existing SSO/IdP (Google, Microsoft Entra ID, Okta, etc.) and instantly use those identities.
Flexible for Humans and Services – OIDC isn’t just for interactive user login. It also works great for service-to-service auth via JWTs. ToolHive’s use of OIDC means it can authenticate both end-users and other services in a unified way (more on this below). The common factor is that identity is conveyed through a trusted OIDC token, whether it came from an OAuth web flow or from a service account in Kubernetes.

OIDC Use Cases in ToolHive

How does this OIDC-based authentication play out in practice? Here are two common scenarios where ToolHive’s approach shines:

🔐 User Login via Google (OIDC) – Imagine a developer wants to run an MCP server that requires user authentication, and they prefer using their Google credentials. Because Google’s identity platform supports OpenID Connect, ToolHive can delegate the login to Google. The user would be redirected to sign in with Google, Google would then provide an ID token to ToolHive representing the user’s Google identity (email, user ID, etc.). ToolHive trusts this token (after verifying its signature and issuer). The end result: the user is authenticated and can use the MCP server using their Google account.

🤖 Service-to-Service Auth with Kubernetes – In some cases, you might want to call an MCP server from a service running in a Kubernetes cluster. With ToolHive’s OIDC support this can be done fairly seamlessly. Kubernetes can issue service account tokens that are actually OIDC JWTs (specifically, bound service account tokens are OIDC identity token). This means a microservice in your cluster can present its Kubernetes JWT to ToolHive; ToolHive will recognize and validate it as an OIDC token. The beauty here is that the service doesn’t need a separate API key or password – its cluster-issued token is enough to prove its identity. This is perfect for scenarios like an internal app calling an MCP server managed by ToolHive; the auth is secure, token-based, and fully automated by existing infrastructure.

How ToolHive Builds on the MCP Spec’s Recommendations

If you’ve read the MCP specification, you might know that the MCP world has been gravitating towards OAuth 2.x for securing tool access. The latest MCP spec (as of early 2025) actually standardizes an OAuth 2.1-based authorization flow for MCP servers. In essence, the spec suggests that an MCP server should use OAuth 2.1 so that clients can obtain tokens to access it, rather than using simplistic API keys. This is a great step for security!

However, the spec’s approach couples authentication and authorization together in the OAuth flow. It essentially envisions the MCP server itself acting as both the Authorization Server and Resource Server in OAuth terms. This means an MCP server developer would need to implement OAuth endpoints (authorization, token, client registration, etc.) and manage tokens, which is non-trivial. In other words, every MCP server might end up reinventing identity and auth if following the spec naively – a recipe for inconsistent implementations and potential security issues.

ToolHive’s philosophy is to leverage existing best practices instead of coming up with our own thing. Rather than turning every MCP tool into an OAuth mini-server, ToolHive acts as the gateway that handles auth on behalf of the MCP servers it runs. It can use OIDC for authentication (as described earlier) to validate the user or service’s identity, and then applies its own authorization logic to decide if that identity can access a given tool. This clean separation aligns with best practices and the principle of least privilege. The MCP spec’s OAuth guidance is not thrown away. In fact, ToolHive aligns with it by using the OIDC/OAuth standards.

What does it look like?

ToolHive has built-in support for OIDC token validation. Enabling it in your server would look as follows:

$ thv run \
    --oidc-audience "some-audience" \
    --oidc-client-id "some-client" \
    --oidc-issuer https://some-oidc-issuer.com/ \
    --oidc-jwks-url https://some-oidc-issuer.com/path/to/jws \
    $MY_MCP_SERVER

Using those flags, the MCP server proxy that ToolHive spawns will validate the OIDC token with the relevant information.

Let’s look at this in a Kubernetes setup. Let’s say our deployment looks as follows:

Service account name: my-service
Namespace: mcp-servers
Audience expected by the MCP server: toolhive
The OIDC issuer for your cluster (usually the Kubernetes API server): https://kubernetes.default.svc
The JWKS URL (location of public keys used to verify the JWT signature): https://kubernetes.default.svc/openid/v1/jwks

The ToolHive pod would look as follows:

apiVersion: v1       
kind: Pod                    
metadata:        
  labels:                                    
    app: thv-everything          
    app.kubernetes.io/name: thv-everything  
  name: thv-everything
  namespace: mcp-servers          
spec:                                        
  containers:    
    - args:                          
        - run                
        - --foreground=true                      
        - --port=8080  
        - --transport=stdio
        - --name=mcp-everything
        - --oidc-audience "toolhive"
        - --oidc-issuer=https://kubernetes.default.svc
        - --oidc-client-id=my-service.mcp-servers.svc.cluster.local
        - --oidc-jwks-url=https://kubernetes.default.svc/openid/v1/jwks
        - docker.io/mcp/everything               
      image: ghcr.io/stackloklabs/toolhive:latest
      name: toolhive     
      serviceAccountName: toolhive-sa
      ports:                                 
        - containerPort: 8080
          name: http                                             
          protocol: TCP

This will only allow requests coming from a pod that has the my-service service account in the mcp-servers namespace.

Did we ever mention we have Kubernetes support? We do! In fact, this will spawn an MCP server instance in Kubernetes. We’ll talk about this in detail later on.

What’s next?

With OIDC, ToolHive is able to validate identities, which is a great first step. However, this is not the end of the road when locking down a deployment. Authorization or Access Control is a very important piece that needs to be considered. Authorization itself can be challenging, but the ToolHive team decided to give it a go anyways!

Stay tuned for a follow-up post, where we’ll dive into ToolHive’s built-in authorization framework. We’ll see how ToolHive defines and checks permissions for MCP servers, ensuring that once a user/service is authenticated via OIDC, they only get to do what they’re allowed to. By separating authn and authz, ToolHive makes it easier to reason about security in your AI toolchain – and ultimately, to keep your MCP servers both easy and secure.

ToolHive: Making MCP Servers Easy, Secure, and Fun

Juan Antonio Osorio — Wed, 09 Apr 2025 08:08:50 +0000

We are excited about the potential of Model Context Protocol (MCP) servers and inspired to make it more consistent to set up, easier to configure and overall secure. So, we're releasing ToolHive as an open-source project that uses existing technology (e.g. Docker and Kubernetes) for better packaging, security utilities, and more. Let's build on MCP together!

TL;DR

ToolHive helps you run MCP servers in an easy, secure, and opinionated way.
ToolHive leverages container runtimes (e.g. the Docker runtime) to do so.
ToolHive is open source, and we welcome contributions!
Here's the repository
Join us in Discord!

How it started

MCP has generated a lot of hype recently in the AI ecosystem. When we first heard about it, it felt just right: a formalization of how AI clients and agents can interact with external APIs, a potential ecosystem, and a lot of opportunities. So, to get myself better acquainted with this, I decided to try it out. There were already a lot of folks building MCP servers and many tutorials on setting them up, so this part wasn’t too hard. However, when I started going through the tutorials, some things felt off. I was sure I wasn’t the only one, so I kicked off an exploration phase with a colleague, and we started gathering information. We landed on three main points of friction:

Search & Discovery Challenges
Inconsistency & Installation Friction
Credential & Permission Concerns

Let’s go through the three friction points and expand.

Search & Discovery Challenges

When exploring the tooling, I and everybody I talked to had different answers to how we found servers. Docker provides a set of official MCP servers in a dedicated namespace, Anthropic has a set of examples, there are a bunch of “Awesome MCP” lists, and nowadays there are even services that allow you to use hosted MCPs. But a lot of questions lingered:

Which MCP is the right one for me?
How do I know if I can trust it?

Finding MCP servers is not as simple as it could be, and finding the right one has its challenges. We clearly aren’t the only ones thinking about this; the recent disclosure of Tool Poisoning Attacks presents issues relating to this realm.

Inconsistency & Installation Friction

Once you’ve found a subset of MCP servers that work for your use case, the next issue is learning how to install and use them.

At the time of writing, we found several implementations that didn’t work. Don’t get me wrong, software quality issues are common, especially in a community as new and fast-moving as MCP. But it is challenging for us early adopters. Before going forward, I must give props to Docker and Anthropic for their curated lists of MCP servers since they’re what’s worked the best for me so far.

So, when looking at MCP installation instructions, they’d often look like this:

{
  "mcpServers": {
    "some-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@namespace/mcp-name"
      ]
    }
  }
}

I have to install npx? I’m one of those people who run an immutable Linux distribution (Fedora Silverblue) as my daily driver. If I need a tool, I’ll run a dedicated container or a toolbox for that. I’m not keen on allowing my IDE to run npx commands…

But anyway, let’s see other implementations and figure out how to run them. And this is where I saw a lot of divergence. Some use uv, some use docker, and there are a lot more invocation styles for this!

Credential & Permission Concerns

Finally, when looking at other implementations, I stumbled upon something like this:

{
  "mcpServers": {
    "some-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@namespace/mcp-name"
      ],
      "env": {
        "MCP_API_KEY": "YOUR_API_KEY_HERE"
      }
    }
  }
}

Do I have to copy my API key into a clear text configuration file? As a security engineer, this feels like a no-go for me. And, once I run it, how do I know if it’s not sending my keys elsewhere?

Enter ToolHive

To address this, we decided to start project ToolHive to run MCP servers in an easy, consistent, and secure manner. This is not a problem that a single company can and should fix alone. And, given that security and community are our backbone, we’re open-sourcing it!

ToolHive is an opinionated way of running MCP servers that takes best practices and packages them in a simple utility.

Simply use the command thv run to get an MCP server running locally.

ToolHive can also help configure your clients by automatically inserting the MCP entry into the right config file. Today we support Cursor, Roo Code, and GitHub Copilot in VS Code, with more to come.

Docker (OCI) images are here to stay

Packaging software can be challenging, but we already have solutions to this. And, coming from the Cloud Native community, we believe that Docker images sure get us a lot closer to the state we’d like in packaging MCP servers. They allow for better consistency in packaging plus they allow us to leverage a lot of the security utilities that have been developed over recent years:

Container signatures
SBOMs tied to image tags
Attestations
Vulnerability Scanning

There’s a lot we can inherit from the ecosystem by simply converging on this format.

Containers, containers, containers

ToolHive itself does not re-invent the wheel. It simply is a wrapper that leverages existing technologies to do its job. In a local experience, ToolHive uses Docker (or any other container runtime of your choice) to spawn containers that run the server. It then spawns a proxy that ensures one way of serving that utility. Today, we’ve implemented HTTP SSE as the transport protocol of choice. This was done given current client support for this. However, when more clients start adopting the new Streamable HTTP transport, we’ll likely migrate to that.

So, you end up with one endpoint per MCP server you run.

We’re aware that a local experience is not going to be the only one that folks want to leverage, so we also added a Kubernetes runtime! This way, you can run your servers as you see fit, where you see fit.

Let secrets be secret

We’re not very keen on API keys leaking, and thus we decided to implement secret storage as part of this. Simply use the command thv secret set <key>, to store an API key securely. To use it, you can reference the key as follows:

thv run --secret secret-key,target=ENV_API_KEY <MCP name>

There is no need to copy secrets across configuration files!

Here’s how they’d look in the end:

{
  "mcpServers": {
    "fetch": {
      "url": "http://localhost:23971/sse#fetch"
    },
    "brave-search": {
      "url": "http://localhost:23872/sse#brave-search"
    },
    "sequentialthinking": {
      "url": "http://localhost:29313/sse#sequentialthinking"
    }
  }
}

ToolHive encrypts your secrets to keep them safe, including keyring support for Linux and macOS! We’ll dedicate a later blog post to this topic.

Find your tools

We’ve also implemented a basic MCP registry to allow you to easily find the tools you need depending on your use case. The thv search command allows you to search by tag or keyword, and the thv registry list allows you to view all the registry entries we’ve packaged so far.

The intention is not for us to be the ultimate gatekeepers of this. We’re happy to help curate entries, and we’re also glad to keep adding entries, but this is somewhere we welcome the community to engage. We’d like to make this more pluggable, and we’d like to have the community help in curation. This tool is meant for everyone, and we believe the community can do a better job in shepherding this effort.

Let’s lock things down

To address some of the security concerns we’ve encountered with MCP servers, we decided to propose a permission system for ToolHive. A sample would look as follows:

{
  "read": [],
  "write": [],
  "network": {
    "outbound": {
      "insecure_allow_all": false,
      "allow_transport": [
        "tcp"
      ],
      "allow_host": [
        "docs.github.com",
        "github.com"
      ],
      "allow_port": [
        443
      ]
    }
  }
}

This allows the MCP to access GitHub through port 443 and nothing else.

With this, we’re hoping to address concerns of keys leaking to external and unauthorized servers. Implementation of this is still in progress, so it’s a good time to join and chime in!

Wait… But there’s more!

We added support for running MCPs over Kubernetes, which allows you to host your tools in your own cluster.

We are also looking into authentication and authorization, bringing end-to-end security for the framework.

We’ll be talking about these in detail in further blog posts. There are a lot of things to come!

Join the fun!

ToolHive is open source, and we welcome contributions!

Whether you want to propose new MCP servers for the registry, add new functionality and features, or help us with documentation, we welcome everybody to join! It is only as a community that we can thrive.

Join us on Discord and check out the repo!

I’ll take some time to write further about the challenges we’re solving and dig deeper into each of the friction points, as well as the solutions that ToolHive proposes. Stay tuned!

Shield Your Agents: Integrating LangGraph’s workflows with CodeGate's Security Layer

Juan Antonio Osorio — Tue, 11 Mar 2025 10:52:26 +0000

Authors:

Juan Antonio "Ozz" Osorio is a Mexican software engineer living in Finland. He has worked in security with cloud-related open source projects such as OpenStack and Kubernetes, as well as security for bare metal environments. He's currently working at Stacklok building tools to make software supply chain and AI security easier and friendlier.

Radoslav Dimitrov is a Senior Software Engineer at Stacklok with a background in supply chain security. Previously at VMware, he is an open-source maintainer of go-tuf and is currently working on CodeGate, a gateway that enhances AI coding assistants by improving privacy, cost efficiency, and performance across multiple models.

The Challenge: Securing Your AI Agents

As AI developers build increasingly sophisticated LLM-powered applications, two critical challenges emerge:

Security vulnerabilities - LLMs can inadvertently expose sensitive data, recommend insecure code, or suggest vulnerable dependencies
Model management complexity - Juggling multiple AI providers, API keys, and model configurations across applications creates friction

These challenges are especially pronounced when building multi-agent systems with frameworks like LangGraph, where multiple LLM calls occur within complex workflows. What if there was a simple way to add a security layer without disrupting your existing architecture?

Enter CodeGate + LangGraph: A Powerful Combination

CodeGate acts as a protective gateway between your LangGraph applications and AI providers, handling security and model management while preserving your application's core logic. The integration requires minimal code changes but delivers substantial benefits.

What is CodeGate?

CodeGate is a local AI gateway that enhances security and streamlines management of other AI assistants, models and applications. CodeGate includes:

Custom instructions: Set up workspaces with prompts engineered for specific stages of your workflow
Model routing (muxing): Route requests to different models based on criteria like file types or project needs
Security features: Automatic redaction of secrets and PII from prompts
Session insights: Track all interactions in a centralized dashboard including prompt history and security alerts

What is LangGraph?

LangGraph extends LangChain to enable stateful, multi-agent applications with LLMs:

Build directed graphs defining how agents communicate
Manage state across multiple interactions
Create complex workflows with conditional logic
Combine different LLM-powered components

Real-World Example: HAIstings Security Assistant

To demonstrate how simple the integration is, we’ll use HAIstings as an example, an AI-powered companion that prioritizes Kubernetes vulnerabilities using LangGraph - https://github.com/StacklokLabs/HAIstings

HAIstings analyzes vulnerability reports from Kubernetes clusters, including potentially sensitive infrastructure details, making it a perfect candidate for CodeGate's security features.

Integration: Step-by-Step

1. Install and run CodeGate

First, deploy CodeGate using Docker:

docker run --name codegate -d -p 8989:8989 -p 9090:9090 \
  --mount type=volume,src=codegate_volume,dst=/app/codegate_volume \
  --restart unless-stopped ghcr.io/stacklok/codegate:latest

Once running, CodeGate’s gateway is available at http://localhost:8989 and you can access the CodeGate dashboard at http://localhost:9090.

2. Configure your LangChain app to use CodeGate

In your LangGraph application, point your LLM initialization to CodeGate's muxing endpoint:

from langchain.chat_models import init_chat_model
llm = init_chat_model(
    model="gpt-4",  # Model name is handled by CodeGate's muxing
    model_provider="openai",
    api_key="not-needed",  # CodeGate manages API keys
    base_url="http://127.0.0.1:8989/v1/mux"  # CodeGate's muxing endpoint
)

This single change routes all LLM calls through CodeGate, instantly adding security features without changing your application's logic.

3. Create your LangGraph workflow (no changes needed)

Your LangGraph workflow remains unchanged! Here's how HAIstings implements its conversation flow:

# Define graph nodes and connections
graph_builder = StateGraph(State)
graph_builder.add_node("retrieve", retrieve)
graph_builder.add_node("generate_initial", generate_initial)
graph_builder.add_node("extra_userinput", extra_userinput)

# Add edges
graph_builder.add_edge(START, "retrieve")
graph_builder.add_edge("retrieve", "generate_initial")
graph_builder.add_edge("generate_initial", "extra_userinput")

# Add conditional edges
graph_builder.add_conditional_edges(
    "extra_userinput", 
    needs_more_info, 
    ["extra_userinput", END]
)

# Compile the graph
graph = graph_builder.compile(checkpointer=memory)

4. Setup your workspaces

Access the CodeGate dashboard at http://localhost:9090 to configure your LLM provider and set up a workspace with your desired muxing rules (see the docs for more).

In our case, this looks like:

5. Run your application

Now when you run your application, all LLM interactions pass through CodeGate, which:

Checks for and redacts sensitive information, i.e. secrets or PII
Routes to the appropriate model based on your desired workspace settings
Logs interactions for audit and monitoring
Scans for security issues in generated code

For more details, check out the CodeGate documentation and LangGraph documentation.

CodeGate dashboard view:

The CodeGate dashboard now displays all interactions, showing redacted secrets and providing a complete audit trail:

Benefits of the Integration

Adding CodeGate to your LangGraph applications provides several key advantages:

Enhanced security

Automatic secrets detection: API keys, passwords, and credentials are identified and redacted
PII protection: Personal identifiable information is kept secure
Safe code generation: Generated code is scanned for security issues

Simplified model management

Centralized configuration: Manage all API keys and provider settings in one place
Model flexibility: Change models without modifying application code
Workspace isolation: Select different models for different projects

Improved observability

Centralized logging: View all LLM interactions across applications
Security alerting: Get notified about potential issues
Prompt history: Review past interactions for debugging

Operational advantages

Privacy-first: All processing happens locally
Minimized vendor lock-in: Switch between AI providers easily
Cost optimization: Route to different models based on needs

Common Questions

Q: Will CodeGate slow down my LangGraph application?

A: CodeGate adds minimal latency while providing significant security benefits.

Q: What if I'm using different model providers?

A: CodeGate supports OpenAI, Anthropic, Ollama, and more. You can mix providers across workspaces.

Q: How does model muxing work with LangGraph?

A: CodeGate's muxing routes requests to different models based on rules you define. Your LangGraph code remains unchanged.

Conclusion

Integrating CodeGate with LangGraph provides a powerful security layer for your AI applications with minimal effort. The HAIstings example demonstrates how seamlessly these technologies work together to create secure, sophisticated AI systems.

By focusing on security from the beginning, you can build LangGraph applications that protect sensitive data while remaining flexible and maintainable.

Start building more secure multi-agent systems today by adding CodeGate to your LangGraph applications! We invite you to join our Discord to stay up to date on dev-focused AI news, get notified of CodeGate releases, or send us a note with what you’d like to see next.

DEV Community: Juan Antonio Osorio

Bringing AI Agents to CI/CD: Using ToolHive and Buildkite to Bring Intelligence to Vulnerability Scanning

Use Case: Agentic Vulnerability Scanning

ToolHive: The MCP Engine

Buildkite: The CI/CD Platform

How the ToolHive Buildkite Plugin Works

Real-World Example: Intelligent Vulnerability Scanning

The Agent's Intelligence in Action

Conclusion

Vibe Coding an MCP Server (with ToolHive)

🐝 The Stack I Use

🔧 ToolHive (core runtime)

💻 Golang + mcp-go

🐳 ko (build tool)

🔍 Testing & Linting

🌱 Philosophy: Vibe Coding Principles

💡 Sample Prompt

🏗️ Vibe Coding Dev Loop

🧪 Dev Loop with ToolHive

🔒Lock it down!

🧭 TL;DR

No Dockerfile? No problem! Running Node and Python MCPs with ToolHive

How it works

Why this matters

Behind the magic

Get started

Try it out and join the fun!

Secure-by-Default Authorization for MCP Servers powered by ToolHive

Authentication vs Authorization: Separate Concerns

ToolHive’s Authorization Framework Overview

How Authorization Works in ToolHive

Policy Model: Cedar in ToolHive

Example: Writing and Using Policies

ToolHive vs. MCP Specification’s Authorization Guidance

Security and Usability

Getting Authentication Right is Critical to Running MCP Servers

Authentication vs Authorization in ToolHive

Why OpenID Connect for Authentication?

OIDC Use Cases in ToolHive

How ToolHive Builds on the MCP Spec’s Recommendations

What does it look like?

What’s next?

ToolHive: Making MCP Servers Easy, Secure, and Fun

TL;DR

How it started

Search & Discovery Challenges

Inconsistency & Installation Friction

Credential & Permission Concerns

Enter ToolHive

Docker (OCI) images are here to stay

Containers, containers, containers

Let secrets be secret

Find your tools

Let’s lock things down

Wait… But there’s more!

Join the fun!

Shield Your Agents: Integrating LangGraph’s workflows with CodeGate's Security Layer

The Challenge: Securing Your AI Agents

Enter CodeGate + LangGraph: A Powerful Combination

What is CodeGate?

What is LangGraph?

Real-World Example: HAIstings Security Assistant

Integration: Step-by-Step

1. Install and run CodeGate

2. Configure your LangChain app to use CodeGate

3. Create your LangGraph workflow (no changes needed)

4. Setup your workspaces

5. Run your application

CodeGate dashboard view:

Benefits of the Integration

Enhanced security

Simplified model management

Improved observability

Operational advantages

Common Questions

Conclusion

💻 Golang + `mcp-go`