Deploy AI agents you can actually govern
You shipped AI agents to move faster. The exposure shows up later: when you test them against a more capable model, when an auditor asks, or when you see how one crafted email can turn an agent against its own tools.
FEDLIN finds where your agents can act beyond their task, what OWASP calls excessive agency, and where a poisoned MCP tool or an over-scoped permission opens a path to data they should never reach. Then FEDLIN locks it down and gives you the evidence to prove it: MCP access scoping, a prompt-injection and secret-leak guard on every model call, defined context boundaries, and agentic audit logging, mapped to the frameworks assessors ask about (NIST AI RMF, NIST 800-53). Delivered inside your own boundary, so a self-hosted model or a hosted assistant runs against sensitive work safely.
This is security testing of your AI systems, your agents and MCP servers, not AI-powered testing of everything else.
Cleared for dual-use security testing (red teaming) on frontier models.
Independent; not affiliated with, sponsored, or endorsed by any AI lab.
Engineered by Jeremiah Coakley, Principal Security Architect
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 Microsoft 365 Copilot exfiltrated internal data from a single crafted email (CVSS 9.3 Microsoft, 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, not a code bug.
ForcedLeak
An indirect prompt injection in a CRM AI agent.
None were exotic. Each looks like an environment you already run.
What's driving this?
Choose your engagement
Embedded layer
The usual path: your AI-native surface assessed within a broader vulnerability or GRC engagement, where it typically falls in scope.
Standalone assessment
The AI-native architecture scoped and hardened on its own, when that surface is the priority.
The exposure
MCP servers open more access than their defaults suggest
Default MCP server configurations are permissive. A tool that can read files, write to a database, or call an external API is an attack surface. Most agentic deployments haven't formally mapped what each server can actually reach, and without that map, there's no principled way to scope access, detect anomalies, or satisfy an assessor asking about the AI system's control surface.
Prompt injection through tool outputs is the dominant exploit class in agentic systems, documented by NIST's CAISI (formerly the AI Safety Institute) in red-team research. Without defined context boundaries, an untrusted input can instruct a trusted agent to invoke a privileged tool. When an agent can act beyond its task this way, OWASP calls it excessive agency (LLM06); the injection that triggers it is LLM01. The attack path exists whether or not anyone has mapped it.
The governance layer
Governing local AI workloads, Kubernetes-native
Running AI yourself (a self-hosted model, an MCP server, an agent with tool access) means the guardrails a SaaS vendor would provide are now yours to build. The core control is a governance layer that sits in front of every model call: it scans inputs for prompt injection, redacts secrets before they reach the model or leave in a response, and bounds what any agent is permitted to touch. Without it, a poisoned tool output or an over-scoped agent has a clear path to a privileged action.
FEDLIN builds this layer into your infrastructure as an engineered pattern, so the control holds independently of the workloads it protects, and keeps holding during a recovery or failover scenario.
Reverse-proxy guard on every call
A single enforcement point in front of your model: local (Ollama-class) or hosted API. Prompt-injection detection hard-blocks poisoned inputs; a secrets scanner redacts credential patterns before they reach the model and blocks them from leaving in a response. Fully blocking: a failed scan fails the request loudly.
A permission manifest, version-controlled
What an agent may do is defined in a version-controlled manifest: an action allowlist, blocked namespaces, and blocked path patterns (secrets, keys, credential files) validated at runtime before any action executes. Authority changes require a commit and a review, not a silent config tweak.
Every action audited
Agent actions, tool invocations, and data-access events captured and structured for review, mapped to NIST 800-53 AU-2 / AU-3: what the system did, what it reached, what changed. The record an assessor asks for, produced as a byproduct of the runtime, captured as each action happens.
Deliverables
What Gets Implemented
Each deliverable is scoped to your agentic system's actual architecture: the servers you're running, the tools they expose, and the data they can reach.
For teams running agents in production
A live agentic system, secured to what it can actually reach: every MCP server and tool mapped, access scoped to least privilege, and the context boundaries that stop a poisoned tool output from reaching a privileged action.
Best for
- → A live agentic system that has never been formally scoped
- → MCP servers still running on permissive defaults
- → An assessor asking about your AI system's control surface
What you get
MCP Server Inventory & Attack Surface Map
Every MCP server, every tool it exposes, every data source reachable from that tool, documented as a structured attack surface map. This is the prerequisite for everything else. You can't scope access to what you haven't inventoried.
Access Scoping & Least-Privilege Configuration
Tool access restricted to what each agent role actually needs. Service account scoping, IAM policy review, and per-server permission baseline, implemented at the infrastructure layer and documented for ongoing maintenance.
Context Boundary Definition
A documented boundary between what the agentic system can access and what it cannot, enforced in configuration. Sensitive data paths, credential stores, and PII sources excluded from agent context and verified against the MCP server inventory.
Prompt Injection Surface Assessment
Identification of every path where untrusted data enters agent context and could influence tool invocation. Attack path documentation for each surface. Mitigations implemented where the architecture permits: input validation, output sanitization, tool invocation guardrails.
Agentic Audit Logging
Agent actions, tool invocations, data access events, and context changes captured and structured for review. Mapped to NIST 800-53 AU-2 (Event Logging), AU-3 (Content of Audit Records), and NIST AI RMF Measure: what the system did, what it accessed, what changed.
COSAiS SP 800-53 Overlay Mapping
Controls mapped to the NIST SP 800-53 Control Overlays for Securing AI Systems (COSAiS), a draft NIST overlay for securing AI systems. For organizations operating under NIST 800-53 baselines or pursuing authorization packages, this mapping positions the agentic system within the existing control framework.
Mapped against the OWASP Top 10 for LLM Applications (LLM01 Prompt Injection, LLM06 Excessive Agency) and the OWASP Top 10 for Agentic Applications, published December 2025, alongside the NIST AI RMF, NIST 800-53, and ISO/IEC 42001 controls above.
Where this pays off
The layer that lets you run sensitive workloads on your own AI
Once the governance layer is in place, it's what makes it safe to point a self-hosted model at work you couldn't hand to a public API. FEDLIN's Post-Quantum Readiness assessment is the clearest example: it ships as an in-boundary container that inventories a system's cryptography, and its optional analysis step can be driven by a model running inside your own environment: sovereign, zero-egress. That only works when guarding, scoping, and audit controls are already in front of the model: the AI never sees a secret value, the agent can only touch what its manifest allows, and every step is logged.
The pattern generalizes to any assessment or automation you'd rather not send to a hosted assistant, so a team that wants to run the PQC container, or its own agents, on AI it controls stands the governance up once and reuses it for everything that follows.
For teams running self-hosted AI
Sensitive work on a model you control, not a public API. The governance layer guards every call, holds an agent to a version-controlled permission manifest, and logs each action, so the model never sees a secret and can only touch what it is allowed to.
Best for
- → Ollama-class or in-boundary models handling regulated data
- → Workloads that cannot leave your environment
- → Running the PQC container or your own agents on sovereign AI
What you get
- →A reverse-proxy guard on every model call: prompt-injection detection and secrets redaction, fully blocking
- →A version-controlled permission manifest: action allowlist, blocked namespaces and path patterns, validated at runtime
- →Every agent action, tool call, and data-access event logged and mapped to NIST 800-53 AU-2 / AU-3
- →The control engineered into your infrastructure so it holds through failover and recovery
Third-party model APIs
For teams running agents on third-party APIs
Your agents call OpenAI, Anthropic, or a hosted gateway, so the model itself is someone else's infrastructure. The security work moves to the boundary you still own: what data reaches the API, what a tool can do with the response, and what the provider is contractually allowed to do with your prompts.
Best for
- → Agents built on a hosted model or an AI gateway
- → Regulated data that cannot leave in a prompt or a log
- → A subprocessor or DPA question you have to answer for the model provider
What you get
- →Egress control on every call: secrets and regulated fields redacted before a prompt leaves your boundary
- →Least-privilege scoping on what a tool can do with a model response, tested at the tool-output boundary
- →Prompt-injection resistance where retrieved data or tool output re-enters the agent
- →Provider and subprocessor exposure documented: what data reaches the API, under what terms, mapped for a SOC 2 or vendor review
GRC Integration
How This Feeds Your GRC Engineering
The security architecture documentation produced in this engagement (server inventory, access scope decisions, context boundary definitions, audit logging configuration) is structured to feed directly into a GRC evidence pipeline. Every control is documented. Every boundary is versioned. Every access decision is auditable. If your organization is building toward SOC 2, NIST 800-53 authorization, or NIST AI RMF compliance, this engagement produces the artifacts that support those programs.
Reference Architecture
Agentic Security Reference Architecture & RFP Evaluation
Writing an RFP for agentic or MCP security, or evaluating a vendor's response? These are the controls a defensible agentic system is built on: the reference architecture FEDLIN builds to, and the checklist to hold any proposal against.
For teams evaluating a vendor or writing an 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
- → 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.
Frequently Asked 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 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?
Teams running self-hosted agentic systems in production (Claude Code, custom MCP server configurations, LLM pipelines with tool-call access) where the security architecture hasn't kept pace with what's been built, and a customer's security review, an auditor, or a SOC 2 / NIST 800-53 / NIST AI RMF scope is now asking about access controls and audit logging. Also for the vCISOs, fractional advisors, and MSPs who bring FEDLIN in as the specialist layer for that work.
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 your client is running self-hosted agentic systems and the security architecture hasn't kept pace, or if you need compliance-ready artifacts before an AI RMF review: that's the conversation.
Further reading on governing AI systems
Often scoped together
Add related services to your scope
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?