How we built an MCP Guardrail to enforce tech policy in real-time

In 2026, most mid-sized and large organizations are aggressively adopting AI coding assistants such as Cursor, Claude Desktop and Windsurf. Developers are now generating a significant portion of code using LLMs.

However, this acceleration brings serious risks. According to the GitGuardian State of Secrets Sprawl 2026 report, in 2025 alone 28.65 million new hardcoded secrets were detected on public GitHub, a 34% year-over-year increase. Secrets related to AI services grew by 81%. Commits assisted by tools like Claude Code show nearly double the credential leak rate (3.2% vs 1.5% for manually written code).

Additionally, Veracode’s 2025 research reveals that 45% of AI-generated code contains OWASP Top 10 vulnerabilities. In some languages (e.g. Java), this figure reaches as high as 70%.

The core challenge for CTOs and architects is clear: we provide developers with extremely powerful generative tools, but we fail to supply them with the company’s current context. Language models have no knowledge of internal Tech Radars, approved library lists, security policies, Architecture Decision Records (ADRs), or forbidden patterns. As a result, LLMs often suggest solutions that are outdated, misaligned with company architecture, or dangerous.

Organizations now face a difficult dilemma: either limit AI adoption (which is unrealistic in a competitive market) or lose control over their technology stack, security, and compliance.

Architect’s Guardrail solves this problem. It is a lightweight, local MCP Server (Model Context Protocol) that acts like “an architect sitting on the developer’s shoulder.”

When a developer asks the AI to generate code, the server delivers the company’s current policy to the LLM in real time, approved technologies, required patterns, security rules, and restrictions. This enables the AI to either generate policy-compliant code or clearly explain why a specific technology or approach is not allowed and suggest an alternative.

True AI Governance in 2026 is not about blocking language models.

It is about delivering up-to-date company knowledge exactly at the moment decisions are made.

The project is fully open-source:

GitHub: https://github.com/annadanilec/architect-guardrail

The Problem: Why Traditional Approaches Fail

Traditional DevSecOps controls, such as pre-commit hooks, SAST (Static Application Security Testing), SCA (Software Composition Analysis), and dependency scanning, act too late in the AI-assisted code generation process.

These tools analyze code only after it has been created, usually at the commit, pull request, or CI/CD build stage. In the world of agentic AI, where a model can generate dozens or hundreds of lines of code in seconds, a post-factum reaction is insufficient. The problem occurs the moment the developer accepts the LLM’s suggestion.

The root cause is the lack of organizational context in language models. LLMs do not know:

• The company’s internal Tech Radar

• Approved / unapproved libraries and their versions

• Architecture Decision Records (ADR)

• Security policies (e.g., how to handle secrets, authentication, logging)

• Forbidden architectural patterns (e.g., direct database calls in backend services)

As a result, models rely on public training data, which is often outdated or misaligned with internal standards.

Key risks:

• Credential and secret leaks

• Use of unapproved, risky libraries

• Inconsistency with company architecture

• Lack of auditability of AI decisions

Aspect	Classic DevSecOps	Agentic AI 2026	Consequence
Problem detection moment	After commit / PR	At code generation time	Too late
Company policy awareness	None (only technical rules)	No organizational context	High risk
Feedback speed	Minutes–hours	Seconds (without guardrails)	Errors multiply quickly
AI decision auditability	Limited	Very low without dedicated tooling	Compliance difficulties

In the era of classic DevSecOps, control was reactive and code-focused. In the era of Agentic AI, control must be proactive and contextual, delivering company policy exactly when the model is making a decision.

Traditional tools simply cannot keep up with the speed and nature of generative AI.

Solution: Architect’s Guardrail (MCP Server)

Architect’s Guardrail is a lightweight, local server compliant with the MCP (Model Context Protocol). It serves as a context layer between the developer and the language model (Claude, Cursor, Windsurf, etc.).

What is MCP and why is it ideal for a guardrail?

MCP is an open protocol introduced by Anthropic in 2025. It allows language models to securely and structurally retrieve context from external sources (tools, resources, and prompts) in real time.

Unlike classic tool calling (e.g., LangChain or OpenAI function calling), MCP was designed for local IDE integration and secure context delivery. It supports two modes:

• stdio (most common for local use)

• HTTP (for enterprise deployments)

Why MCP is perfect for a guardrail:

• Works before code generation, delivers context while the model is still thinking.

• Natively supported by Claude Desktop, Cursor, and other modern AI tools.

• Supports both tools and resources (e.g., the entire company policy as context).

• Lightweight, runs locally, and does not require sending code outside the organization.

• Provides full auditability, every request to the server can be logged.

Architecture

The architecture is deliberately simple so it can be implemented in just a few hours:

• MCP Server – core (Python + FastMCP or TypeScript)

• Policy sources: policy.json, Tech Radar (JSON or external integration), approved libraries, security rules, ADRs, forbidden patterns

• Integration: Claude Desktop / Cursor / VS Code

• Optional: Git repository with policy (auto-refresh on startup)

A basic version can fit in a single ~150–200 line server.py file.

How Architect’s Guardrail Works Step by Step

1. The developer writes a prompt

In Cursor or Claude Desktop, the developer enters:

“Create a secure payment processing endpoint in FastAPI with Stripe integration.”

2. The IDE sends a request to the MCP Server

Before generating a response, the AI tool sends the current context:

• the prompt,
• the current file,
• and the workspace context

to the local MCP Server using either the stdio or HTTP protocol.

3. The MCP Server provides policy context

The server reads the current organizational policy and returns structured context, for example:

{
  "approved_frameworks": ["fastapi", "django", "nestjs"],
  "preferred_http_client": "httpx",
  "forbidden": ["requests", "urllib3"],
  "secrets_handling": "Must use Vault / AWS Secrets Manager. No hardcoded keys.",
  "payment_requirements": [
    "rate limiting",
    "idempotency key",
    "PCI-compliant logging"
  ]
}

4. The LLM receives full organizational context

The model receives not only the user request, but also the company’s current engineering standards and security policies.

As a result, it:

• generates policy-compliant code,
• uses httpx,
• implements proper secret handling,
• adds rate limiting,
• and follows required architectural patterns.

If the model attempts to use something forbidden, it explains why it is not allowed and proposes an approved alternative.

Example AI response with Guardrail enabled

“According to company policy, I cannot use the requests library. Instead, I will use httpx with retry logic, as required by our Tech Radar (ADR-187). Stripe secrets will be retrieved from Vault…”

Architecture Flow

Thanks to this approach, the guardrail operates proactively rather than reactively.

The policy is always up to date because the server can continuously read the latest version directly from Git or a centralized repository.

Implementation: Building Architect’s Guardrail in ~2 Hours

Open-source repository:
https://github.com/annadanilec/architect-guardrail

The basic version can be built in 1.5–2 hours if you have intermediate Python knowledge.

Project Structure

architect-guardrail/
├── src/
│   ├── server.py
│   ├── config.py
│   ├── policy/
│   └── tools/
├── policy/
│   ├── policy.json
│   ├── tech-radar.json
│   └── adrs/
├── mcp.json
├── pyproject.toml
└── README.md

Dependency Installation (pyproject.toml)

[project]
name = "architect-guardrail"
dependencies = [
    "mcp>=0.1.0",
    "pydantic>=2.0",
    "pyyaml",
    "httpx",
    "python-dotenv"
]

Policy Configuration and Loading (config.py)

from pydantic import BaseModel
import json
from pathlib import Path

class Policy(BaseModel):
    approved_libraries: dict[str, list[str]]
    forbidden_libraries: list[str]
    secrets_handling: str
    preferred_patterns: dict
    adrs: dict

def load_policy() -> Policy:
    path = Path("policy/policy.json")
    with open(path) as f:
        data = json.load(f)
    return Policy(**data)

Main MCP Server (server.py)

from mcp.server.fastmcp import FastMCP
from .config import load_policy
from .tools.policy_tools import get_approved_libraries, validate_against_policy

mcp = FastMCP("Architect-Guardrail")

# Resources – automatically available to the LLM
@mcp.resource("policy://tech-radar")
def get_tech_radar() -> str:
    policy = load_policy()
    return policy.model_dump_json(indent=2)

@mcp.resource("policy://security-rules")
def get_security_rules() -> str:
    policy = load_policy()
    return f"""Security rules:
    - Secrets: {policy.secrets_handling}
    - Authentication: OAuth2 + JWT + short-lived tokens
    - Logging: structured logging + PII masking"""

# Tools
@mcp.tool()
def get_approved_libraries(language: str = "python", category: str = None) -> str:
    """Returns a list of approved libraries for a given language and category."""
    policy = load_policy()
    libs = policy.approved_libraries.get(language, [])
    if category:
        # category filtering
        return f"Approved {language} libraries in {category}: {libs}"
    return f"Approved {language} libraries: {libs}"

@mcp.tool()
def validate_against_policy(code_snippet: str, intent: str) -> dict:
    """Validates code against the current company policy."""
    policy = load_policy()
    issues = []

    if "requests" in code_snippet and "httpx" not in code_snippet:
        issues.append({
            "severity": "high",
            "message": "Use httpx instead of requests (according to ADR-142)",
            "suggestion": "from httpx import AsyncClient + retry logic"
        })

    if any(secret in code_snippet for secret in ["api_key", "password", "secret"]):
        issues.append({
            "severity": "critical",
            "message": "Hardcoded secrets are forbidden",
            "suggestion": "Use Vault / AWS Secrets Manager"
        })

    return {"valid": len(issues) == 0, "issues": issues, "intent": intent}

Server Security

• Runs exclusively locally (transport="stdio")
• No public port exposure by default
• Optional lightweight token authentication for HTTP mode (enterprise deployment)

Example Use Cases

Example 1: AI Attempts to Use requests

Developer Prompt

“Write a function to call an external API.”

AI Response with Guardrail Enabled

“According to our policy (Tech Radar + ADR-142), we do not use the requests library. Instead, we use httpx with automatic retry and circuit breaker support. Here is the updated implementation…”

Example 2: Hardcoded secret

AI Response

“I cannot generate code containing a hardcoded API key. According to the security policy (policy://security-rules), all secrets must be retrieved from Vault. Here is a version using hvac / boto3 Secrets Manager…”

Example 3: Deprecated Framework

AI Response

“The proposed usage of Flask 2.x is not compliant with our Tech Radar. The currently approved framework is FastAPI 0.115+. See the migration path in ADR-203.”

Advanced Capabilities

• Tech Radar Integration – automatically fetch policies from databases, Notion, internal APIs, or Git repositories every X minutes
• Policy Versioning – policy/v1.2.json + Git history
• Audit trail – log prompts, returned context, AI decisions, and policy validations
• Human in the loop – use tools such as request_approval() for critical changes like introducing a new library
• Multi-policy support – different policies for backend, frontend, mobile, data science, and platform engineering teams
• CI/CD integration – validate pull requests using MCP logs, policy validation results, and AI interaction history

Practical Limitation: Context Availability vs Policy Enforcement

Current MCP integrations in tools such as Cursor significantly improve organizational context delivery, but an important distinction must be understood:

MCP makes policies available to the model, but does not automatically guarantee that the model will always consult them before generating code.

In practice, this means that simply attaching an MCP Server is not yet equivalent to deterministic policy enforcement. During testing of Architect’s Guardrail in Cursor, policy compliance was significantly more reliable when the AI was explicitly instructed to always consult MCP resources before generating production code.

This reveals one of the key challenges of enterprise AI governance in 2026:

Context availability is not the same as policy enforcement.

To improve reliability, several additional layers can be introduced.

Recommended Enforcement Layers

Persistent Workspace Rules (.cursorrules) – A lightweight but effective approach is adding project-level instructions such as:

Always consult Architect's Guardrail MCP resources before generating code.

Never use external libraries before validating them against company policy.

Always validate:
- secrets handling
- authentication
- logging
- architectural patterns

This significantly increases the probability that Cursor consistently consults MCP resources during generation.

Mandatory Policy Pre-Check – A stronger approach is introducing a middleware layer that automatically injects policy context before generation:

User Prompt
    ↓
Policy Validation Layer
    ↓
MCP Policy Retrieval
    ↓
LLM Generation

This transforms governance from probabilistic to deterministic.

Output Validation – Even after generation, code can be validated against organizational policy:

Generated Code
      ↓
Policy Validator
      ↓
Approve / Reject / Rewrite

This creates a true enterprise-grade governance pipeline.

Architect’s Guardrail should therefore be viewed not as a complete enforcement system by itself, but as foundational governance infrastructure for AI-assisted development environments.

MCP provides the missing organizational context layer. Deterministic enforcement still requires orchestration, workflow design, and validation mechanisms on top of it.

Business Results and Impact

Implementing Architect’s Guardrail delivers measurable benefits for both the organization and individual teams.

Benefits for CTOs, Architects, and Security Teams:

Real-time policy enforcement
Significant risk reduction
Full auditability of AI decisions
Reduced manual review workload
Easier maintenance of Tech Radar consistency

Benefits for Developers:

Faster development
Less friction
Educational effect (AI explains decisions)
Higher confidence that code will pass review

Key Metrics to Track:
| Metric | Before | After | Expected Improvement |

|---|---|---|---|

| Compliance rate | 60–70% | 90–96% | +30–40% |

| Risky AI suggestions per week | 20–35 | 3–6 | -80–85% |

| Hardcoded secrets in PRs | 6–12 | 0–2 | -85–90% |

| Time from prompt to approved code | 40–55 min | 25–35 min | -30–40% |

Comparison with Other Approaches

There are several ways to enforce policies in AI environments. Below is a comparison of the most common approaches alongside the MCP-based Architect’s Guardrail solution.

Approach	Strengths	Weaknesses	Real-time Effectiveness
Prompt Engineering	Very easy to start	Brittle, context limits, hard to maintain	Low
LangChain / LangGraph	Flexible for complex agents	Heavy, high overhead, poor IDE integration	Medium
Central Proxy (Guardrails AI, NeMo)	Strong central control	Latency, single point of failure, complex	High
Local MCP Guardrail	Native IDE integration, low latency, local	Requires local installation	Very High

Architect’s Guardrail stands out due to its simplicity, locality, and excellent developer experience.

Development Roadmap & Recommendations

Stage 1: Basic Guardrail (2–4 hours)

Stage 2: Full Tech Radar + ADR integration (1–2 days)

Stage 3: Multi-team / multi-policy support (3–5 days)

Stage 4: Agent-driven policy updates (advanced)

Recommendations:

Start with Stage 1 in a pilot team.
Treat policy as code, store it in Git.
Combine rollout with team training on effective AI usage.
Aim for organization-wide standardization.

Conclusion

The best way to achieve AI Governance in 2026 is not by blocking models, but by giving them the right company context at the right moment.

Architect’s Guardrail proves that you can reconcile two seemingly contradictory goals: dramatically accelerating development with AI while maintaining strong control over quality, security, and architectural consistency.

MCP is emerging as a highly effective and elegant standard. It is lightweight, local, natively integrated with the best developer tools, and built with security in mind.

Recommendation: If your organization is already using Claude, Cursor, or similar tools, build your own Guardrail. The basic version takes just one evening.

In the coming months, MCP has a strong chance of becoming the de facto standard for enterprise AI governance, just as GitHub Actions became the standard for CI/CD and OpenTelemetry for observability.

It’s time to stop treating AI as an uncontrolled guest in the team.

It’s time to treat it as a highly talented team member that requires clear, precise guidance.

And it all starts with context.

Open-source project:
https://github.com/annadanilec/architect-guardrail
If you are experimenting with AI governance, MCP, or architecture-aware coding assistants, feel free to contribute or fork the project.