NixOS declarative config locks down MCP endpoints from first boot.
Post-quantum P2P encryption, network isolation, every connection audited.
"Show security status" — OpenClaw reports threats and blocked access.
MCP Security Hardening: Authz, Authn, and Trust Boundaries
Remote MCP servers expose AI agent tool-calling capabilities over the network. Without proper security hardening, they become attack vectors for unauthorized access, data exfiltration, and prompt injection. This guide covers the full security stack: OAuth 2.1 authentication, scoped authorization, trust boundary enforcement, tamper-proof audit logging, and defense against MCP-specific attacks like tool poisoning.
The MCP security landscape has shifted dramatically. A 2025 research report analyzing 5,000 MCP servers found that 53% use insecure hard-coded credentials. By early 2026, over 8,000 MCP servers were found exposed without proper authentication. Three CVEs in Anthropic's own Git MCP server (CVE-2025-68145, CVE-2025-68143, CVE-2025-68144) demonstrated that even first-party servers can contain critical vulnerabilities enabling remote code execution via prompt injection. The MCP authorization specification now mandates OAuth 2.1 with PKCE, and the ecosystem is converging on zero trust as the baseline security model.
Last updated: March 2026
TL;DR
- • 53% of MCP servers use hard-coded credentials -- OAuth 2.1 with PKCE is now mandatory for remote servers
- • Trust boundaries isolate each MCP server with dedicated users, network segmentation, and scoped secrets
- • Tool call input validation and output sanitization defend against prompt injection and tool poisoning attacks
- • Every tool call is recorded in a SHA-256 hash-chained audit ledger for compliance and forensics
- • osModa's mcpd daemon enforces OAuth, rate limiting, path traversal protection, and audit logging at the transport layer
Authentication: OAuth 2.1 with PKCE
The MCP authorization specification (released March 2025, updated June 2025) standardizes authentication using OAuth 2.1. Every remote MCP server must authenticate clients before allowing tool access. The specification makes several critical design decisions.
OAuth 2.1 with PKCE
All MCP clients must use the Authorization Code flow with PKCE (RFC 7636), regardless of client type. PKCE prevents authorization code interception attacks, which is essential because most MCP clients are public clients (CLI tools, desktop apps) that cannot securely store client secrets. osModa's mcpd daemon validates PKCE challenges on every authorization request.
Resource Server Classification
MCP servers are officially classified as OAuth Resource Servers. They implement OAuth 2.0 Protected Resource Metadata (RFC 9728), which allows each MCP server to advertise where its corresponding Authorization Server is located. Clients use this metadata for automatic authorization server discovery, eliminating manual configuration.
Resource Indicators
The June 2025 spec update added resource indicators to prevent a critical attack: malicious MCP servers obtaining access tokens meant for other services. Clients must include resource indicators in token requests, and authorization servers must bind tokens to specific resource servers. This prevents token replay across different MCP servers.
Token Validation
osModa's mcpd daemon validates OAuth tokens on every request at the transport layer, before the request reaches your MCP server code. This means your server does not need to implement token validation itself. Tokens are cached for performance (sub-millisecond validation) and revocation is checked periodically. Failed validations are logged in the audit ledger.
mcpd.toml -- authentication configuration
[server.my-tools.auth]
provider = "oauth2"
issuer = "https://auth.example.com"
audience = "mcp://my-tools"
required_scopes = ["tools:read"]
token_cache_ttl = "300s"
revocation_check_interval = "60s"
# Or use osModa's built-in auth server
[server.my-tools.auth]
provider = "osmoda"
allowed_users = ["user@example.com"]
tool_scopes = { "query_db" = "db:read", "write_file" = "fs:write" }Authorization: Scoped Tool Access
Authentication verifies identity. Authorization determines what that identity can do. For MCP servers, this means controlling which tools each client can invoke, what parameters they can pass, and what resources they can access through those tools.
osModa implements tool-level authorization using OAuth scopes. Each tool on an MCP server can be mapped to one or more OAuth scopes. When a client requests a tool call, mcpd checks whether the client's token includes the required scope for that specific tool. This prevents a client authorized for read operations from invoking write tools, even if they authenticate successfully.
Principle of Least Privilege
Every client should receive only the scopes necessary for its function. A monitoring dashboard needs read-only database access, not write permissions. A deployment tool needs CI/CD trigger access, not customer data access. osModa's scope configuration maps directly to individual tools, making least privilege enforcement granular and auditable. Scope violations are logged and can trigger alerts.
Dynamic Scope Evaluation
Beyond static scope checks, osModa supports dynamic authorization policies. A tool call can be evaluated against contextual rules: time-of-day restrictions, rate limits, parameter validation, and cross-tool dependency checks. For example, a "delete_record" tool can require that "read_record" was called first within the same session, preventing blind deletions.
Trust Boundaries: Isolating MCP Servers
Trust boundaries define what each MCP server can and cannot access. A server with database access should not be able to read the filesystem. A server exposing internal APIs should not be able to access customer data in a different system. Without trust boundary enforcement, a single compromised MCP server can access everything on the host.
Process Isolation
Each MCP server runs as a dedicated system user with minimal filesystem permissions. NixOS declarative security policies restrict file access, network access, and system calls per process. A database MCP server cannot read files outside its working directory. An API MCP server cannot open database connections.
Network Segmentation
MCP servers can be restricted to specific network namespaces. A server that queries an internal API only has network access to that API's endpoint. It cannot reach the public internet, other internal services, or other MCP servers on the same host. This limits the blast radius of a compromise.
Resource Limits
osModa enforces CPU, memory, and I/O limits per MCP server process. A runaway server cannot consume all host resources. Resource limits are declared in the mcpd.toml configuration and enforced by the kernel via cgroups. This prevents denial-of-service conditions from affecting other servers on the same host.
Secrets Isolation
Each MCP server receives only the secrets it needs via environment variable injection. Secrets are never stored on disk in plaintext. osModa's secrets manager daemon injects credentials at process startup and scrubs them from memory after the process exits. One server's database credentials are invisible to another server.
Secure Tool Calling: Input Validation and Output Sanitization
MCP tool calls are the primary attack surface. An AI model generates tool call parameters based on user input and conversation context. This creates an injection vector: if a user can influence the model to generate malicious parameters, the tool may execute unintended actions. The three CVEs in Anthropic's Git MCP server all exploited this vector.
Input Validation
osModa's mcpd daemon validates tool call parameters against the tool's declared JSON schema before forwarding the request to the MCP server. Parameters that don't match the schema are rejected at the transport layer. This prevents type confusion, missing field exploitation, and parameter overflow attacks. For file path parameters, mcpd applies path traversal protection by default, preventing "../../../etc/passwd" style attacks that exploited CVE-2025-68145.
Output Sanitization
Tool results returned to the AI model can themselves contain prompt injection payloads. A database query might return data containing instructions that attempt to manipulate the model's next action. osModa sanitizes tool output by stripping known prompt injection patterns, enforcing output size limits, and flagging suspicious content in the audit log for human review.
Rate Limiting
Prompt injection attacks often involve rapid-fire tool calls to exfiltrate data or escalate privileges before detection. osModa enforces per-client and per-tool rate limits. Exceeding the rate limit triggers an alert, logs the event, and temporarily blocks the client. Rate limits are configurable per tool, allowing high-frequency read operations while restricting write operations.
Audit Logging: Tamper-Proof Records of Every Tool Call
Every MCP tool call on osModa is recorded in a SHA-256 hash-chained audit ledger. Each entry is cryptographically linked to the previous entry, making it impossible to modify or delete records without breaking the chain. This provides a complete, tamper-evident history of every tool invocation, authentication event, and system action.
Example audit ledger entry for an MCP tool call
{
"seq": 48291,
"timestamp": "2026-03-01T14:23:17.442Z",
"prev_hash": "sha256:a1b2c3d4e5f6...",
"event_type": "mcp.tool_call",
"server": "database-tools",
"tool": "query_customers",
"client_id": "agent-prod-01",
"client_ip": "10.0.1.42",
"oauth_subject": "user@example.com",
"oauth_scopes": ["db:read"],
"parameters": { "query": "SELECT name FROM customers WHERE active = true" },
"result_size_bytes": 2847,
"duration_ms": 34,
"status": "success",
"hash": "sha256:f7e8d9c0b1a2..."
}The audit ledger captures tool call parameters, execution duration, result size, client identity, OAuth scopes, and status. This data serves dual purposes: compliance evidence for SOC 2, HIPAA, and 21 CFR Part 11 audits, and forensic data for debugging tool behavior and investigating security incidents. For the full audit system architecture, see Tamper-Evident Audit Log and Audit Ledger Forensics.
Defending Against Tool Poisoning and Supply Chain Attacks
Tool poisoning is an MCP-specific attack where a malicious server provides misleading tool descriptions to manipulate AI model behavior. When tools are imported from public registries without verification, the risk extends to supply chain attacks similar to those in the npm and PyPI ecosystems.
Server Provenance Verification
Before deploying any MCP server from a public registry, verify the publisher reputation, inspect the source code, and check for known vulnerabilities using tools like the Cloud Security Alliance's mcpserver-audit. osModa supports signed server manifests that pin tool descriptions to verified code hashes.
Behavioral Monitoring
osModa's audit ledger tracks both declared tool descriptions and actual execution behavior. If a tool described as "read file" starts making network requests or writing to unexpected locations, the behavioral deviation is flagged. This provides runtime defense even if a poisoned server passes initial code review.
MCP Security Hardening Checklist
Use this checklist to verify your MCP server deployment meets production security standards. osModa handles items marked with an asterisk (*) automatically through the mcpd daemon.
Frequently Asked Questions
What are the biggest security risks with MCP servers?
The primary risks are prompt injection attacks (where malicious input causes the AI to invoke tools in unintended ways), tool poisoning (where a compromised MCP server returns malicious tool descriptions), lack of authentication allowing unauthorized access, hard-coded credentials (found in 53% of MCP servers in a 2025 study), and missing audit trails that prevent incident forensics. CVE-2025-68145, CVE-2025-68143, and CVE-2025-68144 in Anthropic's own Git MCP server demonstrated that even first-party servers can have critical vulnerabilities.
How does OAuth 2.1 work for MCP servers?
The MCP authorization specification (March 2025, updated June 2025) standardizes authentication using OAuth 2.1 with mandatory PKCE. MCP servers are classified as OAuth Resource Servers per RFC 9728. Clients discover the authorization server via Protected Resource Metadata, obtain tokens through the Authorization Code flow with PKCE, and include bearer tokens in every request. Resource indicators prevent malicious servers from obtaining tokens meant for other services.
What are trust boundaries in MCP?
Trust boundaries define the security perimeter of each MCP server. A server that accesses your database should not be able to read your file system, and vice versa. osModa enforces trust boundaries at the OS level using NixOS declarative security policies, process-level isolation, and scoped OAuth tokens. Each MCP server runs with the minimum permissions required for its tool set, following the principle of least privilege.
How does osModa prevent prompt injection attacks on MCP?
osModa defends against prompt injection at multiple layers. Tool calls go through typed validation -- each tool has a declared schema and mcpd rejects calls that don't match. Rate limiting prevents rapid-fire tool invocation. The audit ledger records every tool call with full context, enabling post-incident analysis. Tool results are sanitized before being returned to the AI model. And osModa's process isolation prevents a compromised tool from affecting other servers.
What compliance standards does MCP audit logging support?
osModa's SHA-256 hash-chained audit ledger supports SOC 2 (trust services criteria for security, availability, and processing integrity), HIPAA (audit controls per 45 CFR 164.312), 21 CFR Part 11 (electronic records and signatures for FDA-regulated industries), and ISO 27001 (information security management). Every tool call, authentication event, and connection is logged immutably with timestamps, source IPs, client metadata, and tool parameters.
Should I run MCP servers in containers for security?
Containers provide process isolation but are not a complete security solution. osModa uses NixOS-level isolation which provides stronger guarantees than container boundaries. Each MCP server process runs with a dedicated system user, restricted filesystem access, network namespace isolation, and resource limits. This is more secure than Docker containers which share the host kernel and can be escaped via known exploits. The NixOS approach provides defense in depth without the operational complexity of managing container orchestration.
How do I audit MCP servers from public registries?
The MCP Registry (launched September 2025) catalogs available servers but does not verify their security. Before deploying any MCP server, audit its code for hard-coded credentials, excessive permissions, and input validation. The Cloud Security Alliance's mcpserver-audit tool automates security scanning. osModa's mcpd daemon adds a security layer regardless of the server's internal quality by enforcing authentication, input validation, and audit logging at the transport level.
What is tool poisoning and how do I prevent it?
Tool poisoning is when a malicious MCP server provides tool descriptions that mislead the AI model into performing unintended actions. For example, a tool described as 'read file' might actually execute arbitrary commands. Prevention requires verifying MCP server provenance, auditing tool descriptions, using signed server manifests, and monitoring actual tool behavior against declared descriptions. osModa's audit ledger tracks both the declared tool description and actual execution behavior, making poisoning detectable.