Know what every AI agent and MCP server can reach.
MCP Security Audit
We inventory every AI agent and MCP server you run, scope what each one can reach, record every tool call, and hand you the evidence an assessor or customer review asks for.
Engineered by Jeremiah Coakley, Principal Security Architect
The confidence gap
The exposure you can't see from inside
In a January 2026 Cloud Security Alliance survey of 418 IT and security professionals, 82% of organizations had AI agents running that they did not know about and 65% had an AI-agent incident in the past year, while 68% believed they had strong visibility (Cloud Security Alliance, 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.
Assess what you run
The MCP & Private AI Security Audit
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 limit what a poisoned tool output can reach, 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 controls mapped to the frameworks your review runs on. Mapping shows where a control applies; it is not a certification or a claim of full coverage. 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.
The method
How to audit an MCP server
An MCP audit answers one question for every server and agent you run: what can it reach, and would you know if it reached something it shouldn't? Five steps get you there.
- 1
Inventory every server and agent
Include the ones teams connected on their own. In a 2026 Cloud Security Alliance survey, 82% of organizations had AI agents running that IT did not know about.
- 2
Map what each tool can reach
For every tool a server exposes: the data sources, the credentials it holds, the commands it can run, and the hosts it can call out to.
- 3
Test where untrusted content enters
Tool descriptions, tool outputs, retrieved documents, and inbound email or tickets can all carry instructions. Check whether any of them can trigger a tool call the user never asked for.
- 4
Scope access and require authentication
Cut each server down to the tools and data its role needs, scope its credentials the same way, and require authentication on every server reachable over the network.
- 5
Record every tool call
Log who called which tool, with what arguments, what data came back, and when, in one place your reviewers can query.
A scanner run against one server covers part of step 3 for that server, and its flags still need a person to confirm them. Our audit covers all five steps across every server and agent you run, puts the access scoping and logging in place, and ends with the record an assessor asks for.
Start where you are
Which describes you?
Cryptographic foundation
I need to know where my encryption lives, AI included.
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 an audit, a customer review, or a NIST AI RMF, NIST 800-53, or SOC 2 scope. We map the surface, harden it, and produce the evidence.
Who this is for
You shipped an AI feature. Now it's in the audit.
Government contractors and critical-infrastructure operators who need AI to run inside their own boundary, where an 800-53 assessment or a CIP audit now scopes the model, the agents, and the data they touch. Software companies shipping fraud detection, underwriting, or agentic workflows on regulated data hit the same wall when a customer review or SOC 2 engagement scopes the AI feature itself. A compliance-automation platform can only flag the gap. FEDLIN builds the controls the assessor is asking about.
What we build
Software that keeps the data under your control.
Three kinds of build, one discipline: encryption where the data moves, least-privilege access to what it touches, and a record of every action. We build it inside your own boundary and hand you the evidence.
Web apps
Applications that keep regulated data where it belongs
- →Encryption engineered in where the data moves and where it rests, with keys you own and rotate.
- →Access scoped to each role, and every sensitive action recorded.
- →Built to the control baseline your review runs on (NIST AI RMF, NIST 800-53, then SOC 2 or PCI DSS where they apply), with the configuration itself as the evidence.
MCP servers
Agent tools scoped to exactly what they need
- →Each tool exposes only the actions and data its task requires.
- →Callers authenticated and rate-limited, with untrusted input kept away from privileged actions.
- →Every tool call logged in a form an assessor can follow.
Private AI
Models that run inside a boundary you control
- →A single-tenant workspace in your own AWS, Azure, or Google Cloud account, on the model endpoint you already have there.
- →A guard on every model call screens sensitive data before a prompt leaves the workspace.
- →Every user authenticated and every session logged, ready for a customer review.
Runs Claude Code
Your team works in Claude Code and similar agents the way it already does. The workspace decides what those agents can reach and records what they did.
Private AI Workspace
PilotThrough partnersA governed AI workspace, built inside your own cloud.
The workspace is delivered through FEDLIN partners: the MSPs, vCISOs, and integrators who already support your environment. We build a single-tenant workspace in your AWS, Azure, or Google Cloud account and connect it to the model endpoint you already have there: Amazon Bedrock, Microsoft Foundry, or Vertex AI. Your team works in Claude Code the way it does today, including engineers writing control software, device drivers, and telemetry parsers whose code has to stay inside the company. Prompts go to a model served from your own cloud, through a guard we operate, and every session is logged to a named person. The pilot is open to a limited number of partner clients.
What you get
- →Built inside your own cloud account, under your billing and your keys. We work through a time-limited, logged admin role.
- →A guard on every model call that screens for sensitive data and logs each prompt and response.
- →Named users in three roles (operator, contributor, viewer), each signing in with a hardware security key.
- →Session, command, and file audit logs delivered to storage you own.
- →Per-user spend budgets and alerts on model usage.
- →Ongoing patching, monitoring, and log review, with a quarterly evidence export mapped to NIST CSF 2.0 and the NIST AI RMF.
Add-on: governed git
A git server inside your tenant where every push passes secret, dependency, and code scans before it merges.
Set on the scoping call
- →Which cloud and which model endpoint, and which regions serve them
- →How your team connects to the workspace
- →Who holds each role
- →How the guard is tuned to the data you handle
Through a partner
Your partner brings it in, and supports it with the rest of your program.
If you're an MSP, vCISO, or integrator, the Partners page explains how to offer it to your clients. If you're a team that wants one, tell us who supports your environment and we'll scope it with them.
Hosting and model usage are billed by your cloud directly to your account, with per-user budgets and alerts built in.
Partner with us →Questions first? Book a scoping call →You own the cloud account, so the controls are built to reduce mistakes, misconfiguration, and malware and to leave a complete audit trail.
What brings you here?
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 an AI RMF, 800-53, or SOC 2 review.
Common questions
What should MCP audit logs record?
Every tool call: which user or agent made it, the tool and the arguments passed, the data that came back, the time, and the decision that allowed it. Logs should land in one place outside the agent's reach so they can't be edited by the system they record, and they should be kept long enough to cover your audit period. That record lets you trace a prompt-injection attempt from the content that carried it to every tool call it caused, and it maps to NIST 800-53 AU-2 and AU-3.
How should MCP servers authenticate?
A server that runs locally over standard input inherits the credentials of the user who launched it, so its scope is whatever that account can reach. A server reachable over the network should require authorization on every request; the MCP specification uses OAuth 2.1 for this. In both cases the credentials the server holds should be scoped to its tools, stored outside plain-text config files, and rotated.
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 NIST 800-53, NIST AI RMF, or SOC 2 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 an auditor, a customer review, or a NIST 800-53 / NIST AI RMF / SOC 2 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 NIST 800-53 authorization, NIST AI RMF, or SOC 2 compliance, this engagement produces the documentation that supports those programs.
How is the Private AI Workspace priced?
The Private AI Workspace is delivered through FEDLIN partners (MSPs, vCISOs, and integrators), so pricing is set with the partner who brings it to you. It depends on your cloud, the number of seats, and the roles involved. Hosting and model usage are billed by your cloud provider directly to your account, and the workspace includes per-user budgets and alerts so that spend stays visible. In-tenant git with pre-receive scanning is available as an add-on. It is a pilot for a limited number of partner clients.
Which clouds and models does the Private AI Workspace run on?
We build it in the cloud account you already have: AWS with Amazon Bedrock, Microsoft Azure with Microsoft Foundry, or Google Cloud with Vertex AI. Claude Code connects to each of those model endpoints directly, so your prompts go to a model served from your own cloud account and are billed to it. The scoping call confirms which models are available in your region.
How much control does the workspace enforce?
The workspace is built to reduce mistakes, misconfiguration, and malware, and to leave a complete audit trail of who did what and which prompts were sent. You remain the owner of the cloud account, so the controls give your administrators a governed baseline to operate within, and who holds administrative rights in your account stays a trust decision you make.
What is data sovereignty engineering?
Data sovereignty engineering is building and securing the software your regulated data runs through so the data stays in systems you control. For FEDLIN that covers three kinds of build: web applications, MCP servers that give AI agents scoped access to tools, and private AI that runs inside your own boundary. Each is engineered with encryption, least-privilege access, and audit logging in place, and each comes with the evidence a customer review or assessor asks for.
Scope this engagement
If the software or AI your regulated data runs through 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?