DEV Community: Ricardo Rodrigues

An immutable audit trail for AI agent actions (FastAPI + async SQLAlchemy)

Ricardo Rodrigues — Tue, 02 Jun 2026 11:39:49 +0000

Rule zero: the audit log is append-only

The single most important design decision is a discipline, not a library: the audit table is never updated and never deleted from. Not by a feature, not by a migration, not by an admin in a hurry. An event happened, so a row exists, forever.

That sounds obvious until you realise how many ORMs make UPDATE and DELETE one method call away. So the rule has to be enforced by convention and by review: in this codebase, the audit module exposes exactly one operation — append.

from datetime import datetime, timezone
from sqlalchemy import String, DateTime, JSON
from sqlalchemy.orm import Mapped, mapped_column, DeclarativeBase
import uuid


class Base(DeclarativeBase):
    pass


class AuditLog(Base):
    """Append-only. Never UPDATE, never DELETE."""
    __tablename__ = "audit_logs"

    id: Mapped[str] = mapped_column(String, primary_key=True,
                                    default=lambda: str(uuid.uuid4()))
    event_type: Mapped[str] = mapped_column(String, index=True)   # "action.blocked", ...
    actor: Mapped[str | None] = mapped_column(String, nullable=True)
    resource_type: Mapped[str | None] = mapped_column(String, nullable=True)
    resource_id: Mapped[str | None] = mapped_column(String, nullable=True)
    details: Mapped[dict | None] = mapped_column(JSON, nullable=True)
    timestamp: Mapped[datetime] = mapped_column(
        DateTime(timezone=True), default=lambda: datetime.now(timezone.utc), index=True
    )

Note the indexes on event_type and timestamp — you will query this by "what happened to this agent, in this window," and you don't want a sequential scan over millions of rows when an auditor is waiting.

Rule one: writing the log must never break the agent's path

If your audit write is in the hot path and the database hiccups, you've just taken down the agent over a log line. That's backwards. Logging is critical for compliance but it must not be a single point of failure for execution.

FastAPI's BackgroundTasks is the simple, dependency-free way to defer the write until after the response is sent:

from fastapi import APIRouter, BackgroundTasks
from sqlalchemy.ext.asyncio import AsyncSession

router = APIRouter()


async def append_audit(
    session_factory,
    *,
    event_type: str,
    actor: str | None,
    resource_type: str | None,
    resource_id: str | None,
    details: dict | None,
) -> None:
    """One operation, append-only. Runs after the response is returned."""
    async with session_factory() as session:  # type: AsyncSession
        session.add(AuditLog(
            event_type=event_type,
            actor=actor,
            resource_type=resource_type,
            resource_id=resource_id,
            details=details,
        ))
        await session.commit()


@router.post("/v1/actions")
async def submit_action(payload: dict, background_tasks: BackgroundTasks) -> dict:
    decision = evaluate(payload)  # from the policy engine

    background_tasks.add_task(
        append_audit,
        session_factory,
        event_type=f"action.{decision.outcome}",
        actor="agent:" + payload["agent_id"],
        resource_type="action",
        resource_id=payload["action_id"],
        details={"violations": decision.violations, "reason": decision.reason},
    )
    return {"status": decision.outcome}

A couple of async gotchas worth saying out loud, because they cost me time:

Use the asyncpg driver (postgresql+asyncpg://...), never a sync driver, in an async app. Mixing sync DB calls into an async event loop is a classic way to block everything.
If your DATABASE_URL comes from an environment variable, .strip() it. A trailing newline pasted into a dashboard env var produces connection errors that look like everything and nothing. ## Rule two: make it tamper-evident, not just append-only

Append-only protects you from your own code. It does not, on its own, prove to a third party that no one with database access quietly edited a row. For that you want each entry to be cryptographically chained to the one before it — the same idea behind a hash chain.

Here's the technique. When you append an event, you hash its contents together with the hash of the previous event:

import hashlib
import json


def hash_entry(prev_hash: str, event: dict) -> str:
    # Canonical serialization matters: same input must always produce same bytes.
    payload = json.dumps(event, sort_keys=True, separators=(",", ":"))
    return hashlib.sha256((prev_hash + payload).encode("utf-8")).hexdigest()

Store that hash on each row. Now, to verify the trail hasn't been altered, you recompute the chain from the start: if any single row was changed, deleted, or reordered, every hash after it breaks, and the final hash won't match. You don't have to trust the storage layer — you can prove integrity by recomputation.

(I'm being honest about state here: the append-only, non-blocking design above is what's running. The hash-chaining is the direction I'm adding next — if you build the same thing, do them in this order, because immutability-by-discipline is what makes the chaining meaningful.)

Why this is the unglamorous core

Nobody demos an audit table. But it's the thing that turns "we think the agent behaved" into "here is the record, in order, provably unaltered, exportable as evidence." In a bank, an insurer, a hospital — that distinction is the difference between an agent that stays a prototype and one that's allowed into production.

https://horkos.eu — a governance layer that sits in front of AI agents. If you've had to defend an automated system to an auditor, I'd love to know what they actually asked you for. That's the spec I'm trying to hit.

Should this AI agent be allowed to act? Building a policy gateway in FastAPI

Ricardo Rodrigues — Tue, 02 Jun 2026 11:37:55 +0000

AI agents have quietly crossed a line. They no longer just suggest text — they act. They send emails, write to databases, call internal APIs, trigger refunds. In a toy project that's fine. In a company where one of those actions touches customer data or moves money, "the agent decided to" is not an answer anyone in security or risk will accept.

The missing piece isn't a smarter model. It's a decision point in front of every action — somewhere you can ask, before anything happens: is this allowed?

I've been building exactly that as an open project called Horkos. This post walks through the core idea — a policy gateway that intercepts an agent's action and returns one of three outcomes: allow, block, or require human approval. The code below is simplified from the real thing to keep it readable, but the shape is the shape.

The model: an action is a thing you evaluate before you run it

Most agent frameworks execute a tool call and then (maybe) log it. That ordering is the whole problem. By the time you have a log, the money already moved.

So the first move is to treat every action as data that flows through a checkpoint before execution:

agent wants to act
        │
        ▼
  evaluate against policy
        │
   ┌────┴────┐
 BLOCKED   ALLOWED
   │         │
   │    requires approval?
   │      ┌──┴──┐
   │     YES    NO
   │      │      │
   │   pause   execute
   │      │      │
   └──────┴──────┴──► always write to the audit trail

Every path ends in the same place: a log. The decision is the interesting part.

A minimal action payload

The agent (or an SDK wrapper around it) describes what it wants to do:

from enum import Enum
from typing import Any, Optional
from pydantic import BaseModel, Field


class RiskLevel(str, Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"


class ActionRequest(BaseModel):
    action_type: str = Field(..., examples=["send_email", "db_query", "wire_transfer"])
    input_data: dict[str, Any] = Field(default_factory=dict)
    risk_level: RiskLevel = RiskLevel.MEDIUM

Notice there's no output_data yet — the action hasn't run. We're deciding whether it's allowed to.

The policy engine

Policies are just data. Keeping them as JSON means a non-engineer can change what's blocked without a deploy:

DEFAULT_POLICY = {
    # Substrings that should never reach a tool, regardless of action type.
    "block_patterns": [
        "DROP TABLE",
        "DELETE FROM",
        "UNION SELECT",
        "--",
        "ignore previous instructions",
        "disregard the system prompt",
    ],
    # Action types that always need a human before they run.
    "require_approval_for": [
        "wire_transfer",
        "create_admin",
        "delete_data",
        "export_customer_data",
    ],
    # Risk threshold above which we escalate to a human.
    "require_approval_above": "high",
}

Two things are happening here, and they map to two real-world fears:

block_patterns catches the "the agent got prompt-injected / hallucinated a destructive command" case. A DROP TABLE or an ignore previous instructions in the input is a hard stop.
require_approval_for catches the "this action is legitimate but too consequential to be fully autonomous" case. Moving money is allowed — by a human, this time. Now the evaluator:

from dataclasses import dataclass, field


@dataclass
class Decision:
    outcome: str               # "allow" | "block" | "require_approval"
    violations: list[str] = field(default_factory=list)
    reason: str = ""


_RISK_ORDER = {"low": 0, "medium": 1, "high": 2, "critical": 3}


class PolicyEngine:
    def __init__(self, policy: dict) -> None:
        self.policy = policy

    def evaluate(self, action: ActionRequest) -> Decision:
        haystack = self._flatten(action.input_data)

        # 1. Hard blocks — destructive or injection-like input.
        hits = [
            p for p in self.policy["block_patterns"]
            if p.lower() in haystack.lower()
        ]
        if hits:
            return Decision(
                outcome="block",
                violations=hits,
                reason="Input matched blocked patterns",
            )

        # 2. Action types that always need a human.
        if action.action_type in self.policy["require_approval_for"]:
            return Decision(
                outcome="require_approval",
                reason=f"Action type '{action.action_type}' requires approval",
            )

        # 3. Risk threshold escalation.
        threshold = _RISK_ORDER[self.policy["require_approval_above"]]
        if _RISK_ORDER[action.risk_level.value] >= threshold:
            return Decision(
                outcome="require_approval",
                reason=f"Risk '{action.risk_level.value}' is at or above threshold",
            )

        return Decision(outcome="allow")

    @staticmethod
    def _flatten(data: dict) -> str:
        """Turn nested input into one searchable string."""
        parts: list[str] = []
        for value in data.values():
            if isinstance(value, dict):
                parts.append(PolicyEngine._flatten(value))
            else:
                parts.append(str(value))
        return " ".join(parts)

It's not magic. It's a checkpoint with rules you can read. That readability is a feature — when an auditor asks "why was this blocked?", the answer is a line in a JSON file, not a model's vibes.

Wiring it into a FastAPI endpoint

from fastapi import APIRouter, Depends, BackgroundTasks

router = APIRouter()
engine = PolicyEngine(DEFAULT_POLICY)


@router.post("/v1/actions")
async def submit_action(
    action: ActionRequest,
    background_tasks: BackgroundTasks,
) -> dict:
    decision = engine.evaluate(action)

    if decision.outcome == "block":
        # The action never runs. We record the attempt.
        background_tasks.add_task(write_audit, "action.blocked", action, decision)
        return {"status": "blocked", "violations": decision.violations}

    if decision.outcome == "require_approval":
        # Pause. A human gets pinged (Slack, email, whatever).
        background_tasks.add_task(write_audit, "approval.requested", action, decision)
        background_tasks.add_task(notify_approver, action, decision)
        return {"status": "awaiting_approval", "reason": decision.reason}

    # Allowed — the caller is cleared to execute.
    background_tasks.add_task(write_audit, "action.allowed", action, decision)
    return {"status": "allowed"}

The audit write goes to a BackgroundTasks so logging never slows down or breaks the agent's path. Whatever the decision, the attempt is recorded.

Three outcomes, one demo

Same agent, three actions:

Routine notification → allowed, logged.
A query containing DROP TABLE users → blocked before it ever reaches the database.
A €50,000 transfer → awaiting_approval; a human approves or denies, and the agent waits. That third one is the part people underestimate. "Human-in-the-loop" gets said a lot; what it actually means in code is: the action pauses, state is persisted, a human decision flips it, and the agent resumes or stops. The policy decides which actions deserve that treatment — not the agent.

Where this is

Horkos it's live at horkos.eu with a Python SDK that wraps an agent in a few lines. I'm a platform engineer working on infrastructure in a regulated industry, and this is the layer I kept wishing existed before signing off on anything autonomous.

If you're putting agents anywhere near production, I'd genuinely like to hear where your security or compliance team draws the line. That's the design input I care about most right now — drop it in the comments.

The Governance Layer AI Agents Are Missing

Ricardo Rodrigues — Mon, 01 Jun 2026 22:11:14 +0000

Enterprises learned to govern data. Tool governance is the parallel layer almost no one has built yet.

Over the last decade, enterprises built a real discipline around data. Not just storing it — governing it. Cataloging what exists, defining who owns it, controlling who can access it, and proving where it came from and where it went. The question "who is using this data, how, and was it allowed?" went from unanswerable to routine.

The Model Context Protocol just recreated that question one layer up. And almost no one has the answer yet.

From assistants to agents

MCP did something quietly significant: it turned AI clients into agents. Through it, tools like Claude, Cursor, and Windsurf can reach real systems — query databases, read repositories, call internal APIs, trigger deployment workflows. The protocol itself is clean and well-designed. The governance around it is where every enterprise will eventually get stuck.

MCP works beautifully for an individual developer. It becomes a problem the moment a team adopts it.

What it looks like inside most teams

Right now, MCP adoption inside organizations tends to look like this:

Zero governance. Developers install servers ad hoc. Security has no approved list, no process, and no visibility into which tools are connected to AI clients.
Shared access. Teams pass around the same tokens and config files. Everyone effectively gets the same access, regardless of role.
Local chaos. Many MCP servers run as local stdio processes on laptops. They can't be centrally monitored, shared, revoked, or audited.
No forensics. When an agent queries a production database or triggers a workflow, no one can reconstruct who initiated it, when, and whether it was permitted. The buyer pain here is not discovery. There are plenty of directories to find MCP servers. The pain is safe operationalization — adopting MCP without creating shadow AI tooling, uncontrolled credentials, and untraceable agent activity.

The parallel layer

This is the part worth sitting with, especially if you work in data or AI governance.

Data governance answers questions about the asset: what is this dataset, who owns it, what is its sensitivity, who is allowed to use it, where did it come from.

Tool governance has to answer questions about the action: which tool did the agent invoke, who was the agent acting for, was that invocation allowed, and what happened.

These are not competing categories. They're parallel layers in the same enterprise stack, bought by the same people — platform engineering, security, and the emerging AI enablement function. And critically, each has a blind spot the other fills.

When a developer uses an AI client and an MCP server to query a governed table, the data platform sees the table but not the agent's tool call. A tool-governance layer sees the tool call but not the data's classification. Connected, the two produce something neither has alone: end-to-end lineage from a business data asset all the way to the AI agent invocation that touched it.

Put simply: data governance explains the asset. Tool governance explains the agent action.

What the tool-governance layer actually needs

If you accept the framing, the requirements fall out naturally. They mirror what an identity provider brought to applications, applied to AI tool calls:

A single governed endpoint per team, so AI clients connect to one controlled surface instead of dozens of ungoverned servers.
Per-member identity — individual credentials, so every tool call can be attributed to a person and revoked independently.
Tool-level allowlists — least-privilege control over exactly which tools each member can call.
A protocol-level audit trail — an immutable operational record of every invocation: who, what, when, and the outcome.
Hosted, governable infrastructure — a way to take local stdio servers and run them as monitored, controlled services instead of processes on a laptop. None of this is exotic. It's the same governance discipline enterprises already apply elsewhere. It just hasn't been applied to AI tool usage yet, because the usage itself is only a year or two old.

Why now

The reason this matters now and not later is timing. MCP adoption is moving faster than internal security processes. By the time most organizations notice the gap, they'll already have unmanaged AI tool access spread across teams. Governance is far cheaper to introduce before broad rollout than to retrofit after.

This is the layer we're building at mcpnest.io — a governed MCP gateway, per-member access control, hosted infrastructure, and a protocol audit log for AI tool usage. If you want the full thesis, the architecture, and how it complements existing data and AI governance platforms, I put together an enterprise overview:

Read the mcpnest.io enterprise overview (PDF)

If you lead platform, security, or data governance and you're thinking about how AI tool adoption gets controlled in your organization, I'd value your perspective on where this framing holds and where it breaks.

The Day Your AI Agent Has the Keys to Everything

Ricardo Rodrigues — Sun, 24 May 2026 13:06:47 +0000

There's a moment coming in your company, if it hasn't arrived already.

A developer wires up an AI agent — Claude, Cursor, whatever your team uses — to a Model Context Protocol server. Suddenly the agent can query your production database, read your private repos, hit internal APIs, trigger deployments. Not suggest doing those things. Do them. Autonomously, in response to natural language, often without a human approving each action.

On a laptop, that's a productivity miracle. In production, it's a question nobody in the room can answer: who is allowed to do what, and how would we ever know what happened?

That question is the one this piece is about. Because the answer, for most companies adopting MCP today, is: we have no idea.

The pattern we've seen before

If you've been in infrastructure long enough, this rhymes with something.

A decade ago, microservices arrived the same way. Teams split monoliths apart, called the pieces "services," and shipped. The architecture was exciting; the governance was an afterthought. We spent the next five years retrofitting service meshes, API gateways, identity, and observability onto systems that were never designed to be governed. The cleanup cost more than the migration.

MCP is at the exact same stage microservices were in 2014 — explosive adoption, no governance layer, and a collective decision to worry about security later.

"Later" has a way of arriving as an incident.

The gap, stated plainly

Here is what MCP adoption actually looks like inside most teams right now:

Every developer installs their own MCP servers, with their own credentials, on their own machine. Security has no approved list and no visibility into what's connected. Many of those servers run as local processes — meaning they can't be centrally monitored, shared, revoked, or audited. And when an agent does something — queries a customer table, posts to a channel, runs a command — there is no record of who initiated it, through which identity, or whether it should have been allowed.

This isn't hypothetical. Security researchers recently found roughly 1,800 MCP servers exposed to the public internet. Of the sample they analyzed, every single one accepted unauthenticated requests. Some of those servers connect directly to internal systems that would otherwise never be reachable from outside.

Read that again: tools that can act on internal infrastructure, reachable by anyone, authenticating no one.

Why this is worse than a normal security gap

A normal vulnerability is a door someone might pick. This is different, and worse, in two specific ways.

First, the agent is unpredictable by design. A traditional application does what it was coded to do. An AI agent does what it's persuaded to do. If a developer points an agent at an untrusted web page or an unvetted codebase, an attacker can embed instructions in that content — and the agent, trying to be helpful, may call a real tool with real credentials. The infrastructure did nothing wrong. The agent was simply talked into it. Your firewall has no concept of "the model was tricked."

Second, there's no chain of custody. When the incident review happens — and at scale, it always eventually happens — the question will be: which agent, acting for which person, called which tool, against which system, and was that permitted? If your MCP setup is a pile of local configs, you cannot answer that. Not because you didn't log enough. Because the activity never passed through anywhere that could log it.

This is the part that turns a quiet adoption decision into a board-level risk: by the time you need the audit trail, it's too late to have started keeping one.

What governing this actually requires

Strip away the noise and the requirements are not exotic. They're the same disciplines identity providers brought to applications fifteen years ago — applied, now, to tool calls made by AI.

You need a single point every tool call passes through, instead of dozens of direct, ungoverned connections. You need per-person identity, so every action is attributable and individually revocable — not a shared token that gives everyone the same keys. You need tool-level permissions, so a support engineer's agent can read a ticket but not delete a database. And you need an audit trail of every call — who, what, when, outcome — that exists by default, not as something you scramble to bolt on after the first scare.

Notice what governs this can't be the individual server, and can't be the client. A local server can harden itself but can't prove custody across a team. The client can't reason about what other members are doing. The governance has to live at the layer all the traffic passes through. That's not a feature you add to MCP. It's a layer you put in front of it.

Where this goes

The companies that get this right won't be the ones with the most AI agents. They'll be the ones who can answer, on any given Tuesday, exactly what their agents did and whether it was allowed. That capability is about to separate the teams that scale AI safely from the ones that quietly accumulate risk until it surfaces.

This is the layer we build at mcpnest.io — a governed gateway for MCP, with per-member access, tool-level permissions, hosted infrastructure, and a protocol-level audit log that stores metadata, never payloads, so it's EU-resident and clean by construction. One endpoint your team connects through. Everything attributable. Everything revocable. Everything recorded.

If you're adopting MCP and the questions in this piece made you slightly uncomfortable, that discomfort is the signal. You can scan your own MCP configuration for these exact risks, free and entirely in your browser, at mcpnest.io/scan — nothing leaves your machine.

The microservices generation learned the cost of governing too late. The MCP generation doesn't have to.

Why Enterprises Will Struggle With MCP — And What to Do About It

Ricardo Rodrigues — Wed, 20 May 2026 14:35:16 +0000

What Enterprise IT Asks First

When any new technology enters an enterprise, four questions must be answered before broad deployment:

Who has access to what?
What happened, and when?
How do we remove access when someone leaves?
Can we prove compliance to an auditor?

For MCP today, in a default setup, the honest answers are: everyone has access to everything, we do not know what happened, we cannot remove access without breaking the whole team, and no we cannot prove compliance.

This is not a reason to avoid MCP. It is a reason to build the governance layer before the rollout, not after.

The Three Phases Every Enterprise Goes Through

Phase 1 — Exploration
A few developers install MCP servers individually. Cursor with GitHub integration. Claude Desktop with a database connector. Productivity improves visibly. Word spreads internally.

Phase 2 — Team Adoption
Teams start sharing configs. Someone creates a recommended MCP stack document. A workspace token gets shared in Slack. Now the entire team is using the same token with the same access to the same tools. Nobody is logging anything. Security has no visibility.

Phase 3 — The Incident
Something unexpected happens. A production query runs at an unexpected time. A file gets modified that should not have been. An internal API gets called by an agent nobody authorised. Now the question is: "what happened, and who did it?" Nobody can answer it.

This is the moment governance becomes urgent. The problem is that retrofitting governance into an existing MCP deployment is significantly harder than building it correctly from the start — because you have no historical data, no baseline, and no audit trail from before the governance layer existed.

The Seven Capabilities Enterprise MCP Requires

1. Centralised endpoint
One authenticated URL per team. Not dozens of individual JSON configs across dozens of developer machines. A single point of control, logging, and revocation.

2. Per-member identity
Every tool call attributable to a specific person. Not "the workspace called something." Individual tokens per member, so the audit trail captures who did what.

3. Tool-level access control
The ability to say "Alice can use these tools, Bob can use those." Enforced at the protocol level. The principle of least privilege applied to AI tooling.

4. Isolated server deployment
MCP servers running in defined, auditable environments — not on developer laptops. Containers with clean lifecycle management: deployable, monitorable, and terminatable centrally.

5. Quality and trust signals
A trust signal per server that goes beyond GitHub stars. Maintenance velocity, last commit date, publisher verification, config completeness — visible before installation.

6. Instant revocation
When someone leaves the team, their access gone in seconds. Without rotating the workspace token. Without reconfiguring every AI client on the team. Individual member revocation with no blast radius.

7. Protocol-level audit log
A record of every tool call — who called it, which tool, which server, when, and whether it succeeded. Not application-level logging. Protocol-level logging that captures everything that flows through the gateway.

None of these are optional for enterprise. All of them are absent from a default MCP setup.

The Retrofit Problem

The most expensive version of this problem is the one teams build toward without realising it.

A team that deploys MCP without governance for six months has six months of tool calls with no attribution, no audit trail, and no access history. When an auditor asks "what did your AI agents have access to between January and June?", the answer is "we do not know."

That answer is not acceptable in regulated industries. It is barely acceptable in any enterprise context where AI agents have access to production systems.

The teams that establish governance now will have a clean audit trail from the first tool call. The teams that wait will be unable to reconstruct the past.

The Window Is Now

MCP adoption in enterprise is in Phase 1 and early Phase 2 for most organisations. The exploration is happening. The team adoption is beginning.

The governance layer needs to arrive before Phase 3.

Building it after an incident is possible. It is just significantly more expensive — in time, in credibility, and in the irreversible absence of historical audit data.

MCPNest is the enterprise governance layer for MCP servers — Gateway, per-member access control, hosted infrastructure, and audit logging for AI engineering teams.

mcpnest.io

The MCP Security Gap No One Is Talking About

Ricardo Rodrigues — Sun, 17 May 2026 17:11:34 +0000

The MCP ecosystem is growing fast. Thousands of servers, dozens of clients, and teams across the industry moving from personal experimentation to production deployments. But there is a security architecture problem baked into how most teams are using MCP today — and most of them do not know it yet.

The Problem: One Token, Everyone

When you set up an MCP workspace for your team, you generate one Bearer token. That token goes into every team member's AI client configuration. Claude Desktop, Cursor, Windsurf — they all use the same token to authenticate against your MCP servers.

This means every team member has identical access to every MCP tool in your workspace.

Your junior developer has the same permissions as your principal engineer. Your intern can call the deployment tools. Your contractor can query the production database. There is no way to say "Alice can use the database tools but not the CI/CD tools" — not without managing separate workspaces per person, which defeats the purpose of a shared workspace entirely.

This is not a preference problem. It is a security architecture problem. And it gets worse.

The Revocation Problem

Imagine someone leaves the team. To revoke their access, you rotate the workspace token. Now you have to update the configuration of every AI client on the team. Every developer. Every machine. Every client app. Simultaneously.

In a team of ten people, this is painful. In a team of fifty, it is a production incident.

What Proper Access Control Looks Like

Enterprise security operates on the principle of least privilege. Every actor gets access to exactly what they need to do their job — and nothing else. When someone leaves, you revoke their access specifically, without affecting anyone else.

For MCP, this means per-member tokens and per-member tool allowlists.

How MCPNest Gateway Layer 2 Works

We built Gateway Layer 2 to solve this at the infrastructure level, not the application level.

Per-member Bearer tokens. Every workspace member gets their own token. The workspace token still exists for system-level access, but individual members authenticate with their own credentials. The audit trail captures member_id on every call — you know exactly who called what tool and when.

Tool allowlists per member. Admins define exactly which tools each member is permitted to call. Alice gets the database tools. Bob gets the search and retrieval tools. The deployment tools are restricted to the engineers who should have them. These allowlists are configured in the Security tab of the workspace UI — no code required.

Enforcement toggle. The workspace owner enables or disables allowlist enforcement with a single toggle. You define the allowlists first, verify they are correct, and then enable enforcement when ready.

Instant revocation. When someone leaves the team, you delete their token. Their access is gone in seconds. Nobody else is affected. No workspace token rotation. No client reconfiguration across the team.

The Audit Trail

Every tools/call through the MCPNest Gateway is logged with:

Field	Description
`workspace_id`	Which workspace
`member_id`	Which team member
`tool_name`	Which tool was called
`latency_ms`	How long the call took
`status`	Success or failure

This is not workspace-level logging. This is tool-level forensics. When something goes wrong — and in production, something always goes wrong — you know exactly what happened, who triggered it, and when.

Why This Matters Now

The MCP ecosystem is at the same inflection point that OAuth was at in 2010. Teams are moving from "I set this up on my laptop" to "we are running this in production for the whole engineering org." The security model needs to evolve at the same pace.

Right now, most teams are one credential leak away from full workspace exposure. One misconfigured client. One developer who stored their token in a public dotfile. One contractor whose access should have been revoked three months ago.

Per-member access control is not a nice-to-have for enterprise MCP deployments. It is the minimum viable security posture for any team taking this seriously.

MCPNest is the governance layer for MCP servers — Gateway, Layer 2 access control, hosted MCP infrastructure, and a marketplace of 7,554+ servers.

mcpnest.io

Ricardo Rodrigues is the founder of MCPNest and a Platform Engineer at a large financial institution in Portugal.

Why MCP Needs a Governance Layer

Ricardo Rodrigues — Thu, 14 May 2026 12:53:58 +0000

The MCP ecosystem is at an inflection point. What started as a protocol for connecting AI assistants to external tools has become the default integration layer for a generation of AI-powered engineering tools — Claude, Cursor, Windsurf, GitHub Copilot. Thousands of MCP servers exist. Tens of thousands of developers have installed them.

Almost none of them have thought about what happens when this goes to production.

The Individual Problem Is Solved

For a solo developer, MCP is close to perfect. You find a server, copy a JSON snippet, paste it into your config file, restart your AI client, and you have a new capability. GitHub integration, database access, Slack messaging, web search — all available in natural language. The friction is low enough that exploration is easy.

The MCP ecosystem solved the individual problem well.

The Team Problem Is Not

The moment a second person joins, the model breaks.

Authentication. You have a workspace token. You share it with your team. Now everyone has the same access to every tool. You cannot differentiate between what Alice is allowed to do and what Bob is allowed to do. You cannot revoke Bob's access without rotating the token — which breaks every AI client on the team simultaneously.

Deployment. Most MCP servers run as local stdio processes via npx. They exist only on the machine where they were installed. They cannot be shared across a team. They cannot be put behind a gateway. They cannot be monitored or audited. When a developer leaves, their MCP servers leave with them.

Visibility. When something goes wrong — when a production database gets queried unexpectedly, when a CI/CD pipeline is triggered by an agent, when sensitive data appears in a context where it should not — you cannot answer the most basic post-incident question: "which agent called which tool, and when?" There is no log. There is no audit trail. There is no answer.

Quality. 7,500+ MCP servers exist. GitHub stars measure historical interest, not current health. A server with 3,000 stars may not have had a commit in 18 months. There is no quality signal. There is no trust layer.

Why This Matters Now

AI agents are moving toward production infrastructure. They are not just answering questions — they are writing code, querying databases, triggering deployments, sending messages. The tools they use via MCP are real tools with real access to real systems.

The governance problem is not theoretical. It is the same problem that made API keys dangerous before OAuth, that made server access chaotic before centralised identity providers, that made network access ungovernable before Zero Trust. Every time a powerful capability becomes accessible to teams, governance follows — because it has to.

MCP is at the API key moment. The capability exists. The governance does not.

What Governance for MCP Looks Like

A governance layer for MCP needs to answer four questions consistently:

1. Who is using which tools?
Every tool call must be attributable to a specific person. Not "the workspace called something" — "Alice called the database query tool." Member-level attribution requires per-member tokens and protocol-level logging.

2. What is each person allowed to do?
Access control must operate at the tool level, not the workspace level. The security engineer should not have the same MCP permissions as the junior developer. Tool allowlists per member enforce least privilege at the protocol layer.

3. How do you revoke access instantly?
When someone leaves the team, their access must be gone in seconds. Without touching anyone else's configuration. Without rotating credentials that break the whole team. Per-member tokens make this possible.

4. Where do the servers run?
Local stdio processes are ungovernable by design. MCP servers need to run in isolated environments with defined lifecycles — deployable, monitorable, and terminatable without touching developer machines.

The Category That Does Not Exist Yet

Enterprise MCP governance is not a product category yet. It will be.

The same pattern has played out in every previous infrastructure layer. API management was chaos before control planes emerged. Identity was chaos before centralised providers. Network access was chaos before Zero Trust made it manageable.

MCP is the next layer. The governance problem is structural, not optional. And the window to define this category is open now — before the major platforms build their own solutions, before the ecosystem consolidates, before the standard emerges.

The teams that govern MCP today will not be scrambling to retrofit security into production deployments tomorrow.

Ricardo Rodrigues is the founder of MCPNest.io and a Platform Engineer at a large financial institution in Portugal. MCPNest.io is the enterprise governance layer for MCP servers — Gateway, per-member access control, hosted infrastructure, and audit logging.

mcpnest.io

From Developer Laptops to Isolated Containers — Enterprise MCP Infrastructure with MCPNest

Ricardo Rodrigues — Sat, 09 May 2026 22:56:00 +0000

The Problem

The MCP ecosystem is growing fast. Anthropic, Microsoft, Google, AWS, and Cloudflare are all publishing official MCP servers. Developers are connecting AI tools — Claude, Cursor, Windsurf — to databases, internal APIs, GitHub, and business systems.

The infrastructure for doing this at an individual level is mature. The infrastructure for doing this at an enterprise level does not exist.

Today, at most engineering teams, MCP servers run on developer laptops via npx. This means:

Credentials stored in JSON files on individual machines
No isolation between the MCP server and the host system
No central visibility into what is running
No clean offboarding when a developer leaves
No audit trail of what tools were called or what data was accessed This is not a theoretical risk. It is the default state of every engineering team that has adopted MCP tooling without a governance layer.

What We Built

The MCPNest Orchestrator is the infrastructure layer that fixes this.

Instead of running MCP servers locally, the Orchestrator manages isolated Docker containers on central infrastructure. Developers deploy from the workspace dashboard. The AI client connects to the MCPNest Gateway, which authenticates the request, checks the tool allowlist, and proxies to the hosted container.

Nothing changes in the developer workflow. Everything changes in visibility and control.

The Architecture

Claude / Cursor / Windsurf
  ↓ Bearer mng_xxx (per-member token)
MCPNest Gateway (Next.js on Vercel)
  ↓ Auth + allowlist check + audit log
MCPNest Orchestrator (FastAPI on Hetzner, Nuremberg EU)
  ↓ Docker socket
MCP Bridge Container
  ↓ stdio
MCP Server (npx package)

The Gateway handles authentication and authorisation. The Orchestrator handles the container lifecycle. The Bridge handles protocol translation between HTTP and stdio.

The MCP Bridge

Most MCP servers speak stdio — they expect to be launched as a subprocess and communicate via stdin/stdout. The Gateway speaks HTTP.

The Bridge is a FastAPI application that wraps any stdio MCP server as an HTTP endpoint. It launches the MCP server as a subprocess on startup, performs the MCP handshake, and exposes two HTTP endpoints:

POST /tools/list — returns the server tool definitions
POST /tools/call — proxies a tool call to the subprocess The Bridge image pre-installs 12 MCP server packages to avoid cold-start delays:

@modelcontextprotocol/server-filesystem
@modelcontextprotocol/server-github
@modelcontextprotocol/server-postgres
@modelcontextprotocol/server-memory
@modelcontextprotocol/server-everything
@modelcontextprotocol/server-sequential-thinking
@modelcontextprotocol/server-brave-search
@modelcontextprotocol/server-slack
@modelcontextprotocol/server-puppeteer
@upstash/context7-mcp
@notionhq/notion-mcp-server
mcp-server-sqlite

The server to run is passed via the MCP_COMMAND environment variable. The Bridge reads it on startup using shlex.split, launches the subprocess, performs the MCP initialize handshake, and begins listening on port 8080.

If the subprocess closes stdout before the handshake completes — which happens when a server requires credentials that were not provided — the Bridge raises a RuntimeError and the container exits. This is by design: servers that require credentials must have them configured before deploy.

Container Security

Every container the Orchestrator starts is hardened at the Docker level.

cap_drop ALL
Removes all Linux capabilities from the container. The MCP server process has zero elevated permissions. It cannot bind to privileged ports, modify network interfaces, or perform any operation that requires elevated access.

no-new-privileges
Prevents the process from gaining additional privileges via setuid binaries or file capabilities. Even if the MCP server package contains a setuid binary, it cannot use it.

Resource limits
CPU and memory limits are enforced per container based on the resource profile (small / medium / large). This prevents runaway processes and resource exhaustion that could affect other containers on the same host.

Dedicated Docker network
All hosted containers run on a dedicated Docker network (mcpnest_hosted), isolated from the host network. Containers cannot reach the host network directly.

Non-root user
The Bridge runs as a non-root bridge user inside the container. The MCP server subprocess inherits this user context.

Credential isolation
Credentials are passed as environment variables to the container at deploy time. They are never logged by the Orchestrator (explicitly excluded from logs), never stored in plain text in the database, and never visible to developers after submission.

Credential Management

Not all MCP servers start cleanly without configuration. Servers like the GitHub MCP server require a Personal Access Token. The PostgreSQL server requires a connection string. Slack requires a bot token and team ID.

Without credential management, these servers fail silently — the subprocess closes stdout before the handshake completes and the container exits with an error that is difficult to diagnose.

We solved this with a required_env_vars column in the mcp_allowed_images table. Each entry defines the credentials a server needs, with a key, label, type (text or password), and help text.

When a developer clicks Deploy on a server that has required credentials, a modal opens before the deploy request is sent. The modal collects the values — clearly labelled, with help text, password inputs masked. Only when all required fields are filled can the developer proceed.

The values are passed directly to the Orchestrator in the deploy request body and injected as environment variables into the container. They are never written to disk on the host and never appear in Orchestrator logs.

When a developer's access is revoked, their Bearer token is invalidated at the Gateway level. The hosted containers continue running for other team members unaffected. The credentials inside the containers are not exposed.

Deploy Flow

The full flow from click to running container:

Developer clicks Deploy in the workspace Hosted tab
If the server has required_env_vars, a modal collects the credentials before the request is sent
A POST /api/hosted request goes to the Next.js API route with the server slug and credentials
The API route creates an instance record in Supabase with status starting and forwards the deploy request to the Orchestrator
The Orchestrator checks if the Bridge image is already present locally using docker.images.get() — skips pull if found, pulls only if not cached
The Orchestrator starts the container with cap_drop ALL, no-new-privileges, resource limits, and the credentials as environment variables
The Orchestrator updates the instance record in Supabase with status running and the assigned host port
The Next.js API route returns the instance_id to the client
The workspace UI opens a terminal modal that polls /api/hosted/{id}/logs every 3 seconds
When the container reaches RUNNING + HEALTHY state (Docker health check passing), the modal updates automatically and stops polling The real-time deploy console shows the container logs as they stream. The developer sees the MCP server startup output — including any errors — in real time. There is no need to SSH into the server or use Docker CLI.

The Pull-Skip Optimisation

Early in development, every deploy attempt pulled the Bridge image from the registry, even though the image is local-only and was never pushed to Docker Hub. This caused every deploy to fail with a pull access denied error.

The fix was simple but important: check if the image exists locally before attempting a pull.

try:
    cli.images.get(req.image)
    logger.info("Image %s already present locally, skipping pull", req.image)
except Exception:
    try:
        await asyncio.get_event_loop().run_in_executor(
            None, lambda: cli.images.pull(req.image)
        )
    except Exception as exc:
        raise RuntimeError(f"Failed to pull image {req.image!r}: {exc}") from exc

This also makes deploys faster — there is no network round-trip for images that are already cached on the host.

What This Gives Enterprise Teams

Isolation
MCP servers run in sandboxed containers. A misconfigured or compromised server cannot access the host system or interfere with other containers.

Central credential management
No credentials on developer machines. No JSON files with GitHub tokens or database connection strings on laptops. Clean offboarding — when a developer leaves, their Gateway token is revoked and their access is gone immediately.

Audit trail
Every tool call is logged at the Gateway level — member, server, tool name, latency, HTTP status, timestamp. No inputs or outputs are stored. GDPR safe by design.

Consistent infrastructure
Every developer on the team deploys from the same verified catalog. No drift between machines, no manual setup, no "works on my machine" issues with MCP server configuration.

Visibility
Real-time deploy logs during startup. Per-instance log viewer for ongoing debugging. Health monitoring with automatic RUNNING + HEALTHY detection. Terminate with full cleanup — container removed, database record updated.

Current State

The Orchestrator runs on a dedicated Hetzner server in Nuremberg, EU. All state is managed in Supabase (Frankfurt, EU). The Gateway runs on Vercel's edge network.

12 verified MCP servers are available in the hosted catalog today: filesystem, GitHub, PostgreSQL, Notion, Context7, Slack, SQLite, Brave Search, Puppeteer, Memory, Sequential Thinking, Everything.

SOC 2 Type 1 is planned. Self-host via Docker is available for teams that require on-premise deployment.

Conclusion

The MCP ecosystem is at the same inflection point that npm was in 2012 — growing fast, with tooling that works well for individuals and not yet for enterprises.

The gap is not in the protocol. The protocol is solid. The gap is in infrastructure, governance, and auditability.

Running MCP servers on developer laptops is the path of least resistance. It works until it doesn't — until a developer leaves with credentials, until a server is misconfigured and accesses something it shouldn't, until a security team asks what tools the AI has been calling and nobody can answer.

The MCPNest Orchestrator is the infrastructure layer that closes that gap.

mcpnest.io

MCPNest — One Month. The Problem, The Solution, Every Feature Explained.

Ricardo Rodrigues — Tue, 05 May 2026 23:27:57 +0000

The Problem

The MCP ecosystem is expanding at an extraordinary pace. Anthropic, Microsoft, Google, AWS, and Cloudflare are all publishing official MCP servers. Hundreds of open source servers exist for every conceivable integration. Developers are connecting AI tools — Claude, Cursor, Windsurf — to internal databases, codebases, APIs, and filesystems.

The infrastructure for doing this exists. The governance layer does not.

Today, at most engineering teams:

Every developer runs MCP servers on their own machine
There is no central record of what servers are active
There is no audit trail of what tools were called, by whom, or when
Credentials — GitHub personal access tokens, database connection strings, API keys — are stored in JSON files on developer laptops
There is no approval process for which servers developers can use
There is no isolation — MCP servers run with the full permissions of the local user

This is the gap MCPNest fills.

The Platform

MCPNest is the governance and infrastructure platform for MCP servers. It operates across three layers: a marketplace for discovery, a gateway for control, and a hosted infrastructure layer for isolation and centralisation.

Layer 1 — Marketplace

What it is

A searchable catalogue of 7,500+ MCP servers indexed from the official Anthropic registry and GitHub. Every server has a quality score, compatibility matrix, publisher profile, and install configuration.

What problem it solves

Without a central catalogue, developers find MCP servers through GitHub searches, Reddit posts, and blog articles. There is no quality signal, no verification, no compatibility information. Teams end up with inconsistent tooling and no visibility into what is actually being used.

Features

7,500+ servers indexed with quality scores and compatibility filters
One-click install for Cursor and VS Code
Publisher profiles with verified badges
Server of the Week editorial picks
Collections and curated starter packs
Config Validator — validates syntax, endpoints, and arguments before installation
MCP Composer — build multi-server configurations and share via link
Trending servers with weekly install data

Layer 2 — Gateway

What it is

A single authenticated HTTPS endpoint per workspace. Every developer on the team points their AI client at the same Gateway URL. The Gateway authenticates the request, checks the tool allowlist, proxies to the correct upstream server, and logs the call.

What problem it solves

Without a gateway, every developer maintains their own local configuration. When a server changes, everyone updates manually. There is no central authentication, no audit, and no way to enforce which tools developers can use.

Features

Single endpoint per workspace
One URL replaces individual configurations across every developer machine. When the admin adds or removes a server, the change is immediate for the entire team.

Bearer token authentication (SHA-256)
Every request is authenticated. Tokens are stored as SHA-256 hashes with timing-safe comparison. No plain text secrets.

Per-member tokens
Each developer has their own Bearer token. This means every tool call is attributable to a specific individual, not just to the workspace. Tokens can be revoked instantly for any member without affecting the rest of the team.

Tool allowlists per member
Admins define which tools each developer can call at the protocol level. A developer with access to the GitHub MCP server can be restricted to specific tools — for example, read-only operations only. Workspace-wide enforcement toggle.

Full audit log per tool call
Every call is logged with: workspace ID, member ID, server, tool name, HTTP status, latency, timestamp, and error code where applicable. No inputs or outputs are stored — only metadata. GDPR safe by design. Logs are exportable.

Tool namespacing
Automatic conflict resolution when multiple servers expose tools with the same name. No manual configuration required.

Workspace RBAC
Three roles: Owner, Admin, Member. Only Admins can approve servers for the workspace. Separation of duties between team management and tool usage.

Layer 3 — Hosted Infrastructure

What it is

MCP servers running in isolated Docker containers on central infrastructure, managed by the MCPNest Orchestrator. Developers deploy servers from a catalogue via the workspace dashboard. The AI client connects to the Gateway, which proxies to the hosted container.

What problem it solves

Running MCP servers locally means no isolation, no central credential management, no shared infrastructure, and no visibility into what is actually running. When a developer's laptop is lost or stolen, every credential in every local config file is exposed. When a developer leaves the company, there is no clean offboarding process.

Features

12 verified servers available for one-click deploy
Filesystem, GitHub, PostgreSQL, Notion, Context7, Slack, SQLite, Brave Search, Puppeteer, Memory, Sequential Thinking, Everything. All pre-validated and running on the MCPNest Bridge image.

Container isolation
Every container runs with: cap_drop ALL (zero Linux capabilities), no-new-privileges flag, CPU and memory resource limits enforced, dedicated Docker network per workspace.

Credential management
Servers that require credentials — GitHub personal access tokens, database connection strings, Slack bot tokens, API keys — prompt for them via a modal before deploy. Credentials are encrypted and never logged. Developers never see or store them locally.

Real-time deploy console
A terminal modal streams container logs during startup. The system auto-detects RUNNING + HEALTHY state and closes automatically. No manual refresh required.

Per-instance log viewer
Every running instance has a Logs button that shows the last 50 lines of container output. Debugging without SSH access.

Terminate with cleanup
Stopping a server removes the container and cleans the database record. No orphaned containers.

MCP Bridge
A stdio-to-HTTP adapter that wraps any npx-based MCP server into an HTTP endpoint compatible with the Gateway. Enables hosting of any MCP server without modifying its source.

Security and Compliance

Infrastructure
All infrastructure is EU-based. Supabase (Frankfurt) for the database. Hetzner (Nuremberg) for the orchestrator and hosted containers. Vercel edge network for the application layer.

Token security
Bearer tokens are stored as SHA-256 hashes. Timing-safe comparison on every request. Per-member tokens enable individual audit trails and instant revocation.

Data handling
No inputs or outputs from tool calls are stored. Only metadata is logged (who, when, which tool, what status). GDPR safe by design.

Container security
cap_drop ALL removes all Linux capabilities from containers. no-new-privileges prevents privilege escalation. Resource limits prevent noisy neighbour and runaway processes. Dedicated Docker network per workspace.

Self-host
The full MCPNest stack is available for self-hosted deployment via Docker for teams that require on-premise infrastructure.

The Result

One month. 14 versions shipped. 7,500+ MCP servers indexed. Enterprise Gateway live. 12 hosted servers operational. Partnerships with Grafana, RailPush, and Context7 confirmed.

The MCP ecosystem needed a governance layer. MCPNest is it.

mcpnest.io

Hosting MCP Servers at Scale: The Orchestrator

Ricardo Rodrigues — Wed, 29 Apr 2026 20:39:35 +0000

How MCPNest deploys isolated Docker containers for MCP servers and routes tool calls intelligently across your workspace.

MCP servers have a deployment problem.

Most servers are stdio-based — they run as a subprocess via npx and communicate over stdin/stdout. That works fine on a developer's laptop. It does not work for a team.

You cannot share a stdio process across machines. You cannot health-check it remotely. You cannot restart it when it crashes without someone noticing. You cannot give five engineers access to the same instance running on one person's laptop.

The standard solution is to wrap stdio servers in an HTTP adapter and deploy them to a server. The problem: that is significant infrastructure work for every MCP server you want to use. Dockerfile, networking, health checks, restart policies, resource limits — multiply that by every server your team needs.

We built MCPNest Hosted Servers to handle all of it.

How hosted MCP servers work

When you click Deploy in your workspace Hosted tab, MCPNest:

Creates an instance record in the database (status: pending)
Sends a deploy request to the MCPNest Orchestrator service
Orchestrator pulls the verified image from our allowlist
Orchestrator starts the container with security hardening applied
Orchestrator polls health until the container responds
Updates the instance to status: running, health_status: healthy
The server automatically appears in your Gateway tools/list

Total time measured in production today: 6 seconds from click to RUNNING + HEALTHY.

The Bridge layer

Inside each hosted container runs MCPNest Bridge — a FastAPI server on port 8080 that translates between HTTP (external) and stdio JSON-RPC (internal).

Bridge handles:

MCP protocol handshake (initialize → notifications/initialized)
Managing the stdio subprocess lifecycle
Translating POST /tools/list → tools/list JSON-RPC request → response
Translating POST /tools/call → tools/call JSON-RPC request → response
Draining stderr in the background so it never blocks the main process
asyncio.Lock per request to prevent concurrent stdio corruption

The subprocess command is configurable per image via the mcp_allowed_images table. For node:20-alpine with @modelcontextprotocol/server-filesystem, the command is npx -y @modelcontextprotocol/server-filesystem /workspace.

Security model

Every container runs with these constraints — no exceptions, not configurable by the user:

Process isolation:

no-new-privileges: true — no privilege escalation
cap_drop: ALL — all Linux capabilities dropped
cap_add: [CHOWN, SETUID, SETGID] — only minimum needed

Network isolation:

Containers bind to 127.0.0.1 only — never exposed on a public interface
Traffic flows: Gateway → Orchestrator → container (all internal)

Filesystem:

/tmp mounted as tmpfs with noexec, nosuid, nodev
No host filesystem mounts

Resources:

CPU and memory caps enforced at container creation by plan profile
Small: 0.25 vCPU, 256 MB RAM
Medium: 0.5 vCPU, 512 MB RAM
Large: 1.0 vCPU, 1 GB RAM

Image allowlist:

Only MCPNest-verified images can be deployed
Images are validated against a regex pattern before pull
The DB allowlist is the primary gate; the regex is defence-in-depth

The Orchestrator

Above the containers sits the MCPNest Orchestrator — a FastAPI service that aggregates tools from all running instances in a workspace and routes tool calls to the correct container.

tools/list aggregation:

When your Gateway receives a tools/list request and orchestrator_enabled is true, it calls the Orchestrator. The Orchestrator:

Queries the database for all running instances in the workspace
Fans out POST /tools/list to each container in parallel
Collects results, detects naming conflicts
Applies namespacing: if two servers expose a tool called query, they become postgres_mcp__query and mysql_mcp__query
Caches the result for 30 seconds
Returns a unified tool list

tools/call routing:

When a tools/call arrives, the Orchestrator:

Finds the ToolInfo record for the requested tool name (from cache)
Looks up the live endpoint URL from the database
Strips the namespace prefix if present (postgres_mcp__query → query)
Forwards the call to the correct container
Logs the call to mcp_tool_calls (best-effort, non-blocking)
Returns the result

Fallback behaviour:

If the Orchestrator is unreachable, or if a workspace has no running hosted instances, the Gateway automatically falls back to direct fan-out to remote HTTP servers. No downtime. No manual intervention.

Current state

Three verified images are available today:

Server	Image	Tools
filesystem-mcp	node:20-alpine + @modelcontextprotocol/server-filesystem	read_file, write_file, list_directory
github-mcp	ghcr.io/modelcontextprotocol/servers:github	create_issue, list_prs, search_code
postgres-mcp	ghcr.io/modelcontextprotocol/servers:postgres	query, list_tables, describe_table

Plan limits: Team plan supports 3 running instances per workspace. Enterprise supports 20.

What's next

Auth headers per server (bring your own API keys — fixes degraded status on auth-required servers)
More verified images: Slack, Notion, Linear
Usage metering per instance for billing
Auto-deploy via workspace registry URL (mcpnest-registry-client npm package)

Ricardo Rodrigues — Platform Engineer @ BCP, Founder @ MCPNest
Porto, Portugal

MCPNest — The App Store for MCP Servers
mcpnest.io/workspace → Hosted tab

Enterprise MCP Governance: Gateway + Layer 2

Ricardo Rodrigues — Wed, 29 Apr 2026 20:38:30 +0000

One endpoint. Per-member tokens. Full audit trail. How MCPNest solves the team coordination problem for MCP.

When a team of engineers all use Claude with MCP servers, you have a coordination problem.

Each person runs their own npx command. Each person has their own claude_desktop_config.json. When a server URL changes, someone has to update every config. There is no audit trail. No access control. No way to know who called what tool, when, and with what arguments.

This is the current state of enterprise MCP usage in 2026. We built two layers to fix it.

Layer 1: The Gateway

MCPNest Gateway gives every workspace a single endpoint:

https://mcpnest.io/api/gw/{workspace-slug}

Behind that endpoint: all the MCP servers your team has approved. One Bearer token. All tools. Every call proxied and logged.

The Gateway speaks JSON-RPC 2.0 — the MCP standard. Claude, Cursor, and Windsurf connect to it exactly as they would to any MCP server. Your team updates one config file once. When you add or remove a server from your workspace, every connected client sees the change automatically on the next tools/list call.

Technical implementation:

Token format: mng_ prefix + 48 hex characters (192 bits of entropy)
Storage: SHA-256 hash only — the raw token is never stored in plaintext
Verification: timingSafeEqual() to prevent timing side-channel attacks
Rate limiting: 200 requests per minute per IP per workspace slug
SSE support: streaming responses for MCP servers that use Server-Sent Events
Tool prefix: configurable per server to avoid naming conflicts (github_create_issue vs gitlab_create_issue)

Layer 2: Per-Member Access Control

The workspace token is admin-level — full access to all tools. For team members, you create individual Bearer tokens with the same format but different scope.

Each member token can have an allowlist: server_slug : tool_name pairs that define exactly which tools the member can call.

How it works:

Owner creates a member token in the workspace Security tab
Owner defines allowlist rules: github-mcp:list_issues, grafana:get_dashboard
Owner enables enforcement
Member uses their token — Gateway checks allowlist on every tools/call
Blocked calls return error code -32003: Tool not allowed for this user
Every call is logged with user identity to the audit trail

The rule logic:

No rules defined: member has full access (open by default)
Rules defined + enforcement on: member can only call listed tools
Workspace admin token: always full access regardless of allowlist

What this looks like in practice

A DevOps team has three MCP servers in their workspace: GitHub, Grafana, and a custom internal deployment server.

Junior engineers get member tokens with allowlists restricted to read-only operations: github-mcp:list_issues, grafana:get_dashboard. They can query and report but not write.

Senior engineers get tokens with no allowlist restrictions. The deployment server is restricted to the team lead and the CI system.

All of this configured in the workspace UI. No code changes. No config files to distribute to each team member.

The audit log

Every action in a workspace is logged: server added, member invited, tool called, health check run. For tool calls, the log records which user (by member token identity), which server, which tool, and the response latency.

This is the audit trail your security team asks for. It exists out of the box.

Ricardo Rodrigues — Platform Engineer @ BCP, Founder @ MCPNest
Porto, Portugal

MCPNest — The App Store for MCP Servers
mcpnest.io/workspace

The MCP Discovery Problem

Ricardo Rodrigues — Wed, 29 Apr 2026 20:29:01 +0000

In November 2024, Anthropic released the Model Context Protocol —
a standard that lets AI agents call external tools. Within months,
hundreds of MCP servers appeared on GitHub. Stripe, Grafana,
Cloudflare, AWS — all publishing official servers.

The problem: there was nowhere to find them.

Developers were digging through GitHub search, Reddit threads,
and scattered READMEs to find servers that might already exist.
The official Anthropic registry had an API but no UI.
The most starred community lists had tens of thousands of
GitHub stars but weren't searchable or filterable.

This is the npm problem from 2012. A growing ecosystem
with no discovery layer.

What we built

MCPNest indexes MCP servers from the official Anthropic registry
and GitHub. 7,554 servers as of today, with quality scores,
install counts, compatibility flags per client, and one-click
install configs for Claude Desktop, Cursor, VS Code, and Windsurf.

Every server page renders the GitHub README, shows the install
config for each client, and tracks installs via a copy button
that increments a counter in Supabase.

Quality scoring

Not all MCP servers are equal. We score each server 0-100 based on:

Has a valid install config
Has a description
Is verified from the official registry
GitHub stars
Install count

The score maps to an A-F grade shown on each server card.

What this doesn't solve

Discovery is the easy part. Finding a server is step one.
The harder problems are: running it reliably, giving your team
access to it securely, and managing it at scale.

That's what we built next.

→ mcpnest.io