MCP Security Auditor Agent

Comprehensive security assessment agent for MCP server implementations, covering authentication flows, RBAC design, and compliance validation.

When to Use This Agent

Choose this agent when you need to:

• Audit an MCP server for OAuth 2.1 compliance and token management vulnerabilities
• Design role-based access control policies mapping user roles to tool annotations
• Validate that destructive tools enforce human-in-the-loop approval workflows
• Assess compliance posture against SOC 2, GDPR, or HIPAA for MCP deployments

Consider alternatives when:

• You are building a server and need architectural guidance (use MCP Server Strategist)
• Your concern is protocol conformance rather than security posture (use Specialist MCP Ally)

Quick Start

Configuration

Copy
name: mcp-security-auditor-agent
type: agent
category: mcp-dev-team

Example Invocation

Copy
claude agent:invoke mcp-security-auditor-agent "Audit the authentication and session management of my Streamable HTTP MCP server"

Example Output

MCP Security Audit Report
==========================
Server: inventory-mcp v1.4.2
Transport: Streamable HTTP

Authentication Assessment:
  [FAIL] OAuth 2.1 PKCE not implemented - using legacy implicit flow
  [FAIL] Access tokens have 24-hour expiry - recommended max 30 minutes
  [WARN] Refresh token rotation not enforced
  [PASS] Client credentials flow uses TLS 1.3

Session Management:
  [FAIL] Session IDs are sequential integers - use CSPRNG
  [WARN] No Origin header validation on /mcp endpoint
  [PASS] Session timeout configured at 15 minutes

Tool Safety:
  [FAIL] delete-inventory tool lacks 'destructive' annotation
  [WARN] No human approval gate for bulk operations
  [PASS] Read-only tools properly annotated

Risk Rating: HIGH (3 critical, 2 warnings)

Core Concepts

Security Domain Overview

Aspect	Details
Auth Standard	OAuth 2.1 with PKCE mandatory for public clients
Token Lifetime	Access: 15-30 min, Refresh: rotated on each use
Session Security	CSPRNG IDs, Origin validation, IP binding
Tool Safety	Annotations + RBAC + human approval for destructive ops
Data Protection	TLS 1.3 in transit, AES-256 at rest
Compliance	SOC 2 Type II, GDPR, HIPAA, PCI-DSS mapping

Security Layer Architecture

┌─────────────┐     ┌─────────────┐
│  OAuth 2.1   │────▶│  Token       │
│  Provider    │     │  Validator   │
└─────────────┘     └─────────────┘
        │                   │
        ▼                   ▼
┌─────────────┐     ┌─────────────┐
│  RBAC        │────▶│  Tool        │
│  Engine      │     │  Gatekeeper  │
└─────────────┘     └─────────────┘

Configuration

Parameter	Type	Default	Description
auditScope	enum	"full"	Scope: full, auth-only, rbac-only, compliance-only
complianceFrameworks	string[]	["soc2"]	Frameworks to validate: soc2, gdpr, hipaa, pci-dss
maxTokenLifetime	number	1800	Maximum acceptable access token lifetime in seconds
requireDestructiveAnnotations	boolean	true	Fail audit if destructive tools lack annotations
humanApprovalRequired	string[]	["delete","execute"]	Operations requiring human-in-the-loop approval

Best Practices

1. Enforce PKCE on All Public Client Flows Every OAuth authorization code flow involving a public client must use Proof Key for Code Exchange. Without PKCE, authorization codes can be intercepted and exchanged for tokens by malicious applications running on the same device.

2. Annotate Every Destructive Tool Explicitly Tools that modify, delete, or execute commands must carry the destructive annotation. This enables clients to enforce confirmation prompts and RBAC policies. Unannotated destructive tools bypass all client-side safety checks.

3. Implement Defense-in-Depth for Session Management Combine multiple session security controls: cryptographically random session IDs, Origin header validation, IP address binding, user-agent fingerprinting, and aggressive timeout policies. No single control is sufficient on its own.

4. Log All Authentication and Authorization Events Structured audit logs capturing login attempts, token issuance, RBAC decisions, and tool invocations are essential for incident response and compliance. Forward logs to a SIEM system with tamper-proof storage.

5. Rotate Refresh Tokens on Every Use Issue a new refresh token each time one is consumed. This limits the window of exploitation if a refresh token is leaked, because the attacker's stolen token becomes invalid after the legitimate client's next refresh cycle.

Common Issues

1. Confused deputy attack allows unauthorized tool access The server forwards the client's access token to a downstream API without verifying the token's intended audience. Validate the audience claim in every token and never blindly relay credentials to third-party services.

2. Origin header validation bypassed on non-browser clients CLI and SDK clients may not send the Origin header, causing the server to skip validation entirely. Implement a strict policy: require Origin for browser clients and authenticate non-browser clients through a separate client credentials flow.

3. Compliance audit fails due to missing encryption at rest Tool responses containing PII or sensitive data are cached in plaintext. Configure your caching layer to use AES-256 encryption for all stored data, and implement key rotation policies aligned with your compliance framework requirements.