Self-Hosted AI Security
Secure the AI and agentic workloads on your estate.
An MCP security assessment maps and locks down the agents, MCP servers, and LLM pipelines already on your estate: access scoping, context boundaries, agentic audit logging, and the cryptographic foundation beneath them, mapped to NIST AI RMF. It is one capability of FEDLIN's infrastructure-security practice.
A verified member of Anthropic's Cyber Verification Program (CVP), cleared for dual-use security testing (red teaming) on frontier models.
Independent; not sponsored or endorsed by any AI lab. CVP membership is an independent verification of our security practices.
Engineered by Jeremiah Coakley, Principal Security Architect
Start where you are
Which describes you?
Cryptographic foundation
I need to know what cryptography my AI and my estate run on.
The AI runtime, its APIs, and its signing infrastructure all rest on cryptography a post-quantum mandate now puts under a clock. A PQC readiness assessment inventories it in your own boundary and hands you a CBOM and a migration roadmap. A public edge scan is the free first step; internal infrastructure gets the in-boundary assessment.
Security assessment
I need to harden or evidence my production AI, agents, or web applications.
Teams with deployed agentic systems, MCP servers, LLM pipelines, or web applications facing a customer review, an audit, or a NIST AI RMF or SOC 2 scope. We map the surface, harden it, and produce the evidence.
The confidence gap
The gap you can't see from inside
In a 2026 survey of more than 900 organizations, 88% had already had an AI-agent security incident, while 82% of executives believed their existing policies had them covered (Gravitee, State of AI Agent Security 2026). The controls that govern a web app or an API don't see what an agent does with the access you gave it.
Real, and it looks like your environment
EchoLeak · CVE-2025-32711
A zero-click prompt injection in a major hosted AI assistant exfiltrated internal data from a single crafted email (CVSS 9.3 vendor, 7.5 NVD).
Agent hijack via public issue
A malicious public GitHub issue hijacked an agent into leaking private-repo data through an auto-created public PR: an architecture-level flaw that no code review would catch.
ForcedLeak
An indirect prompt injection in a CRM AI agent.
None were exotic. Each looks like an environment you already run.
We run this ourselves
FEDLIN self-hosts its own models behind this exact governance layer, on a sovereign Kubernetes cluster we operate. The same discipline runs our public MCP server at mcp.fedlin.com, which exposes our scanners as agent-callable tools under least-privilege scope.
What brings you here?
Assess what you run
The Self-Hosted AI Security Assessment
Three modules, sold together, on their own, or embedded in a broader vulnerability or GRC engagement. We scope to your surface on a short call and give you a fixed number before anything starts.
What does the audit cover?Module 1 · Map
Every agent and MCP server, and what it can reach
We inventory the agentic surface and build the access map: which agent, which tool, which data. The gaps surface here, before an attacker or an assessor finds them. The same map scopes the work: how many servers and agents, how broad each tool's access, and how complex the identity model is.
Module 2 · Harden
Access scoped, boundaries enforced, every call recorded
We scope every tool to least privilege, set the context boundaries that stop a poisoned tool output from reaching a privileged action, and stand up the governance layer that enforces it: a guard on every model call, a version-controlled permission manifest, and audit logging.
Zero trust applied to agentic systems means no agent inherits access by default, and every call is authenticated before it is authorized. FEDLIN deploys SPIFFE/SPIRE workload identity so each agent in the pipeline carries a short-lived cryptographic identity the enforcement layer verifies on every call, rather than relying on a shared credential or trusted network position.
# agent action log: scoped, enforced, recorded for review billing-agent → db.query ALLOW read:invoices billing-agent → fs.read BLOCK /secrets/* (blocked-paths) support-agent → http.post BLOCK egress:external (no-egress) support-agent → ticket.update ALLOW write:tickets
Module 3 · Evidence and up-tier
The record an assessor asks for, mapped to the frameworks
Audit logging mapped to NIST 800-53 AU-2 / AU-3, and a crosswalk to the frameworks your review runs on. When a mandate raises the bar to FIPS or SCRM, the cryptographic foundation is the up-tier.
Deeper up-tier tracks: Cryptographic / PQC Readiness and GRC evidence engineering.
Reference Architecture
Agentic security reference architecture & RFP evaluation
Comparing MCP security vendors, or writing an RFP for agentic and MCP security work? These are the controls a defensible agentic system is built on: the reference architecture FEDLIN builds to, and the checklist to hold any proposal, or any commercial MCP security solution, against.
Choosing an MCP security vendor, or writing the RFP
A defensible bar to score any agentic proposal against, whether you are buying the capability or drafting the requirement. FEDLIN can build to this architecture, or hand you the checklist to hold someone else's response to it.
Best for
- → Drafting an RFP for agentic or MCP security work
- → Comparing MCP security and compliance services across vendors
- → Scoring a vendor response you cannot fully evaluate in-house
- → Setting a security bar before an agentic build kicks off
RFP / vendor evaluation checklist
- → A complete inventory of every MCP server and the tools each exposes, with the data each can reach.
- → Least-privilege access scoping per tool, so an agent can only invoke what its task requires.
- → Defined context and trust boundaries between untrusted input (tool output, retrieved data) and privileged actions.
- → Prompt-injection resistance tested at the tool-output boundary, where an injected instruction actually enters.
- → Audit logging of every agent action, structured for review (NIST 800-53 AU).
- → Controls mapped to NIST AI RMF (MEASURE / MANAGE) and NIST 800-53 (AC / AU / CM / SI), with evidence artifacts for a SOC 2 or AI RMF review.
Common questions
What is MCP server security architecture?
MCP (Model Context Protocol) servers are the interface layer between agentic AI systems and the tools, data sources, and external APIs they can access. Security architecture for MCP servers means formally mapping the access surface each server exposes, restricting tool access to least-privilege, defining context boundaries so agents can't reach data they shouldn't, and instrumenting audit logging so every action is traceable. Without this architecture, the attack surface of an agentic deployment is undefined.
What does an MCP security audit cover?
An MCP security audit maps the full access surface of every MCP server in your deployment, then tests it. It covers which tools each server exposes and whether that access is least-privilege, where a poisoned tool output or an over-scoped permission could let an agent reach data it should not, whether context boundaries hold between agents and tenants, and whether every agent action is logged in a way an auditor can follow. The deliverable is the mapped surface, the findings, the fixes applied, and the evidence that proves it, structured for a SOC 2, NIST 800-53, or NIST AI RMF scope.
What are the NIST controls for an MCP server?
MCP servers fall under the access control (AC) and audit and accountability (AU) families in NIST 800-53, and under the Measure and Manage functions of the NIST AI RMF. In practice that means least-privilege tool access (AC-6), defined boundaries governing what each agent can reach (AC-3, AC-4), and audit logging that records every agent action with enough context to reconstruct it (AU-2, AU-3, AU-12). FEDLIN maps each control your MCP deployment needs to the specific configuration that satisfies it, so the mapping itself becomes audit evidence.
How does a CISO implement audit trails for AI agents?
Audit trails for AI agents record every action an agent takes: the tool it called, the arguments it passed, the data it reached, and the decision that authorized it. The implementation puts a logging layer at the point where agents call tools, usually a reverse proxy in front of the MCP servers, so no action bypasses it. Each entry ties back to a versioned permission manifest, so a reviewer can see not only what an agent did but what it was allowed to do at the time. FEDLIN builds this into self-hosted deployments and produces the trail in a format that feeds a GRC evidence pipeline.
What is prompt injection in agentic systems?
Prompt injection is the dominant exploit class in agentic systems. It occurs when untrusted data (from a tool output, a database record, an external API response) enters the agent's context and instructs it to take actions the legitimate user didn't authorize. If an agent can read files, query a database, and make API calls, a malicious payload in any of those sources can hijack the agent's next action. The attack path exists whether or not the team has mapped it. NIST's CAISI (formerly the AI Safety Institute) has documented this class in red-team research.
Who is this engagement for?
One path is for teams that need to know what cryptography their AI and estate run on, the AI runtime, its APIs, and its signing infrastructure, ahead of a post-quantum mandate; it routes to a PQC readiness assessment. The other is for teams running self-hosted agentic systems or LLM pipelines in production where a customer review, an auditor, or a SOC 2 / NIST 800-53 / NIST AI RMF scope is asking about access controls and audit logging.
How does this feed into a compliance program?
The artifacts produced (server inventory, access scope decisions, context boundary definitions, audit logging configuration) are structured to feed directly into a GRC evidence pipeline. Controls are documented. Boundaries are versioned. Access decisions are auditable. For SOC 2, NIST 800-53 authorization, or NIST AI RMF compliance, this engagement produces the documentation that supports those programs.
Scope this engagement
If the AI you already run needs to clear a client review, an audit, or a mandate, that's the conversation.
Further reading on governing AI systems
Often scoped together
Related engineering, delivered on its own or folded in
GRC Engineering
Harden the infrastructure the agentic pipeline runs on (IAM, network isolation, runtime controls) and produce the NIST AI RMF compliance evidence that feeds attestation.
Penetration Testing
Adversarial testing of the agentic pipeline and API surfaces: findings with reproduction steps.
Post-Quantum Readiness
The in-boundary crypto-inventory container this governance layer lets you run agentically: a model inside your own boundary, sovereign and zero-egress.
From the Blog
From the field notes
SPIFFE/SPIRE on OpenShift: Building the Workload Identity Plane Your Zero-Trust Model Is Missing
After locking down human and device access, pod-to-pod communication was still trust-the-network. SPIFFE/SPIRE closes that gap. Short-lived cryptographic identities, attested per-workload, chained under your existing Root CA.
LLM Guard on Kubernetes — Governing the Content Layer on OpenShift
The cluster governs what AI processes can reach. LLM Guard governs what passes through them — and deploying it changed how I think about agentic architecture.
AI Governance at the Infrastructure Layer on OpenShift
I recently cut over from K3s to OKD. Here's the decision that made every previous decision make sense.
Not sure where to start? Tell us where you are.
Evaluating your security posture before a funding round, compliance deadline, or enterprise deal?