Securing ContextForge¶

This guide provides essential security configurations and best practices for deploying ContextForge in production environments.

⚠️ Critical Security Notice¶

ContextForge is currently in beta (v1.0.0-RC-3) and requires careful security configuration for production use:

• The Admin UI is development-only and must be disabled in production
• Expect breaking changes between versions until 1.0 release
• Do not use it with insecure MCP servers.

🚨 Production Security Checklist¶

1. Disable Development Features¶

# Required for production - disable all admin interfaces
MCPGATEWAY_UI_ENABLED=false
MCPGATEWAY_ADMIN_API_ENABLED=false

# Optional: turn off auxiliary systems you do not need
MCPGATEWAY_BULK_IMPORT_ENABLED=false
MCPGATEWAY_A2A_ENABLED=false

Use RBAC policies to revoke access to prompts, resources, or tools you do not intend to expose—these surfaces are always mounted but can be hidden from end users by removing the corresponding permissions.

2. Enable Authentication & Security¶

# Configure strong authentication
AUTH_REQUIRED=true

# Basic auth is DISABLED by default (recommended for security)
# API_ALLOW_BASIC_AUTH=false    # Default - use JWT tokens instead
# DOCS_ALLOW_BASIC_AUTH=false   # Default - use JWT tokens instead

# If you MUST use Basic auth (legacy compatibility only):
# API_ALLOW_BASIC_AUTH=true
# BASIC_AUTH_USER=custom-username       # Change from default
# BASIC_AUTH_PASSWORD=strong-password-here  # Use secrets manager

# Platform admin user (auto-created during bootstrap)
PLATFORM_ADMIN_EMAIL=admin@yourcompany.com  # Change from default
PLATFORM_ADMIN_PASSWORD=secure-admin-password  # Use secrets manager

# JWT Configuration - Choose based on deployment architecture
JWT_ALGORITHM=RS256                        # Recommended for production (asymmetric)
JWT_PUBLIC_KEY_PATH=jwt/public.pem         # Path to public key file
JWT_PRIVATE_KEY_PATH=jwt/private.pem       # Path to private key file (secure location)
JWT_AUDIENCE_VERIFICATION=true             # Enable audience validation
JWT_ISSUER_VERIFICATION=true               # Enable issuer validation
JWT_ISSUER=your-company-name               # Set to your organization identifier

# Set environment for security defaults
ENVIRONMENT=production

# Configure domain for CORS
APP_DOMAIN=yourdomain.com

# Ensure secure cookies (automatic in production)
SECURE_COOKIES=true
COOKIE_SAMESITE=strict

# Configure CORS (auto-configured based on APP_DOMAIN in production)
CORS_ALLOW_CREDENTIALS=true

Platform Admin Security Notes¶

The platform admin user (PLATFORM_ADMIN_EMAIL) is automatically created during database bootstrap with full administrative privileges. This user:

• Has access to all RBAC-protected endpoints
• Can manage users, teams, and system configuration
• Is recognized by both database-persisted and virtual authentication flows
• Should use a strong, unique email and password in production

JWT Security Configuration¶

ContextForge supports both symmetric (HMAC) and asymmetric (RSA/ECDSA) JWT algorithms. Asymmetric algorithms are strongly recommended for production due to enhanced security properties.

Production JWT Security (Recommended)¶

# Use asymmetric algorithm for production
JWT_ALGORITHM=RS256                        # or RS384, RS512, ES256, ES384, ES512
JWT_PUBLIC_KEY_PATH=/secure/path/jwt/public.pem
JWT_PRIVATE_KEY_PATH=/secure/path/jwt/private.pem
JWT_AUDIENCE=your-api-identifier
JWT_ISSUER=your-organization
JWT_AUDIENCE_VERIFICATION=true
JWT_ISSUER_VERIFICATION=true
REQUIRE_TOKEN_EXPIRATION=true              # Reject tokens without exp claim
REQUIRE_JTI=true                           # Require JWT ID for token tracking/revocation

Development JWT Security¶

# HMAC acceptable for development/testing only
JWT_ALGORITHM=HS256
JWT_SECRET_KEY=your-strong-secret-key-here  # Minimum 32 characters
JWT_AUDIENCE=mcpgateway-api
JWT_ISSUER=mcpgateway
JWT_AUDIENCE_VERIFICATION=true
JWT_ISSUER_VERIFICATION=true
REQUIRE_TOKEN_EXPIRATION=true              # Reject tokens without exp claim
REQUIRE_JTI=true                           # Require JWT ID for token tracking/revocation

JWT Key Management Best Practices¶

RSA Key Generation:

# Option 1: Use Makefile (Recommended for development/local)
make certs-jwt                   # Generates ./certs/jwt/{private,public}.pem with secure permissions

# Option 2: Manual generation (Production with custom paths)
mkdir -p /secure/certs/jwt
openssl genrsa -out /secure/certs/jwt/private.pem 4096
openssl rsa -in /secure/certs/jwt/private.pem -pubout -out /secure/certs/jwt/public.pem
chmod 600 /secure/certs/jwt/private.pem  # Private key: owner read/write only
chmod 644 /secure/certs/jwt/public.pem   # Public key: world readable
chown mcpgateway:mcpgateway /secure/certs/jwt/*.pem

ECDSA Key Generation (Alternative):

# Option 1: Use Makefile (Recommended for development/local)
make certs-jwt-ecdsa             # Generates ./certs/jwt/{ec_private,ec_public}.pem with secure permissions

# Option 2: Manual generation (Production with custom paths)
mkdir -p /secure/certs/jwt
openssl ecparam -genkey -name prime256v1 -noout -out /secure/certs/jwt/ec_private.pem
openssl ec -in /secure/certs/jwt/ec_private.pem -pubout -out /secure/certs/jwt/ec_public.pem
chmod 600 /secure/certs/jwt/ec_private.pem
chmod 644 /secure/certs/jwt/ec_public.pem

Combined Generation (SSL + JWT):

make certs-all                   # Generates both TLS certificates and JWT RSA keys

Security Requirements:

• Never commit private keys to version control
• Store private keys in secure, encrypted storage
• Use strong file permissions (600) on private keys
• Implement key rotation procedures (recommend 90-day rotation)
• Monitor key access in system audit logs
• Use Hardware Security Modules (HSMs) for high-security environments
• Separate key storage from application deployment

Container Security for JWT Keys:

# Mount keys as read-only secrets (Kubernetes example)
apiVersion: v1
kind: Secret
metadata:
  name: jwt-keys
type: Opaque
data:
  private.pem: <base64-encoded-private-key>
  public.pem: <base64-encoded-public-key>

# In pod spec:
volumes:

  - name: jwt-keys
    secret:
      secretName: jwt-keys
      defaultMode: 0600

Environment Isolation¶

When deploying ContextForge across multiple environments (DEV, UAT, PROD), you must configure unique JWT settings per environment to prevent tokens from one environment being accepted in another.

Required per-environment configuration:

Example production configuration:

# Each environment MUST use different values
JWT_SECRET_KEY="$(openssl rand -base64 32)"  # Or use separate keypairs
JWT_ISSUER=mcpgateway-prod
JWT_AUDIENCE=mcpgateway-api-prod
JWT_ISSUER_VERIFICATION=true
JWT_AUDIENCE_VERIFICATION=true
ENVIRONMENT=production

Optional: Environment claim validation

For additional defense-in-depth, you can embed and validate an environment claim in tokens:

EMBED_ENVIRONMENT_IN_TOKENS=true   # Adds "env" claim to gateway-issued tokens
VALIDATE_TOKEN_ENVIRONMENT=true    # Rejects tokens with mismatched "env" claim

This rejects tokens created for a different environment even if signing keys are accidentally shared. Tokens without an env claim are allowed for backward compatibility with existing tokens and external IdP tokens.

3. Token Scoping Security¶

The gateway supports fine-grained token scoping to restrict token access to specific servers, permissions, IP ranges, and time windows. This provides defense-in-depth security for API access.

Team-Based Token Scoping¶

Tokens can be scoped to specific teams using the teams JWT claim:

Security Default: Non-admin tokens without explicit team scope default to public-only access (principle of least privilege).

Server-Scoped Tokens¶

Server-scoped tokens are restricted to specific MCP servers and cannot access admin endpoints:

# Generate server-scoped token (DEV/TEST ONLY)
python3 -m mcpgateway.utils.create_jwt_token \
  --username user@example.com \
  --scopes '{"server_id": "my-specific-server"}' \
  --secret my-test-key-but-now-longer-than-32-bytes

Security Features:

• Server-scoped tokens cannot access /admin endpoints (security hardening)
• Only truly public endpoints (/health, /ready) bypass server restrictions
• Documentation endpoints (/docs, /redoc, /openapi.json) are exempt from server scoping but still require auth by default
• RBAC permission checks still apply to all endpoints

Permission-Scoped Tokens¶

Tokens can be restricted to specific permission sets:

# Generate permission-scoped token (DEV/TEST ONLY)
python3 -m mcpgateway.utils.create_jwt_token \
  --username user@example.com \
  --scopes '{"permissions": ["tools.read", "resources.read"]}' \
  --secret my-test-key-but-now-longer-than-32-bytes

Canonical Permissions Used:

• tools.create, tools.read, tools.update, tools.delete, tools.execute
• resources.create, resources.read, resources.update, resources.delete
• admin.system_config, admin.user_management, admin.security_audit

4. Token Lifecycle Management¶

ContextForge provides token lifecycle controls including revocation and validation requirements.

Token Revocation¶

Tokens with a jti (JWT ID) claim are tracked and can be revoked before expiration:

• Revoked tokens are normally rejected immediately on all endpoints
• Token revocation is checked against the token_revocations database table
• Administrators can revoke tokens via the Admin UI or API
• Auth dependencies (require_auth, require_admin_auth) and MCP transport auth all enforce revocation and active-user checks on the normal path.
• Availability trade-off: when revocation/user lookups fail due to a database outage, these checks currently fail open to preserve availability.

# Enable token tracking (required for revocation)
REQUIRE_JTI=true

Token Validation Settings¶

These settings are enabled by default for security. For backward compatibility with existing tokens that lack these claims, you can disable them (not recommended for production).

5. Admin Route Authentication¶

The Admin UI (/admin/*) enforces additional authentication checks beyond standard API authentication:

Authentication Requirements¶

• Valid JWT token with admin privileges, OR
• Proxy authentication when TRUST_PROXY_AUTH=true (for deployments behind OAuth2 Proxy, Authelia, etc.)

Validation Checks¶

Admin routes perform the following validations:

1. Token revocation: Tokens are checked against the revocation list
2. Account status: Disabled accounts (is_active=false) are blocked
3. Admin privilege: User must have is_admin=true in their profile

Proxy Authentication¶

For deployments using an authentication proxy:

# Enable proxy header authentication
TRUST_PROXY_AUTH=true
PROXY_USER_HEADER=X-Forwarded-User    # Header containing authenticated username

# Important: Only enable when ContextForge is behind a trusted proxy
# that properly sets and validates this header

6. Session Management¶

The reverse proxy session management (/reverse-proxy/sessions) implements access controls:

Session Access Rules¶

Session Security Features¶

• Server-side ID generation: Session IDs are generated server-side using UUIDs
• Ownership tracking: Sessions are associated with the creating user
• No client-supplied IDs: Client-provided session ID headers are ignored

7. User Registration¶

Control whether users can self-register accounts:

# Disable public registration (recommended for production)
PUBLIC_REGISTRATION_ENABLED=false

When disabled, only administrators can create user accounts via the Admin UI or API.

8. Network Security¶

• Configure TLS/HTTPS with valid certificates
• Implement firewall rules and network policies
• Use internal-only endpoints where possible
• Configure appropriate CORS policies (auto-configured by ENVIRONMENT setting)
• Set up rate limiting per endpoint/client
• Verify security headers are present (automatically added by SecurityHeadersMiddleware)
• Configure iframe embedding policy (X_FRAME_OPTIONS=DENY by default, change to SAMEORIGIN if needed)
• Verify Subresource Integrity (SRI) hashes for CDN resources (automatically verified in CI)

Subresource Integrity (SRI)¶

MCP Gateway implements Subresource Integrity for all external CDN resources to cryptographically verify that fetched resources have not been tampered with. This protects against:

• CDN Compromise: Malicious code injection if a CDN is compromised
• MITM Attacks: Content modification during transit
• DNS Hijacking: Redirection to malicious CDN servers
• Version Drift: Unexpected changes to CDN content

Protected Resources (14 total):

• HTMX (2.0.3) - Dynamic interactions (bundled via npm/Vite)
• Alpine.js (3.14.1) - Reactive framework
• Chart.js (4.4.1) - Data visualization
• Marked (11.1.1) - Markdown parser
• DOMPurify (3.0.6) - XSS sanitizer
• CodeMirror (5.65.18) - Code editor (7 files)
• Font Awesome (6.4.0) - Icon library

Verification:

# Verify all SRI hashes match current CDN content
make sri-verify

# Regenerate hashes (after updating CDN library versions)
make sri-generate

Updating CDN Libraries:

When updating a CDN library version:

1. Update the URL in scripts/cdn_resources.py
2. Run make sri-generate to calculate new hash
3. Update the URL in templates (admin.html, login.html, etc.)
4. Run make sri-verify to confirm hash matches
5. Commit both mcpgateway/sri_hashes.json and template changes

The CI pipeline automatically verifies SRI hashes on every build to detect unexpected changes.

Security Checklist:

• All CDN resources have SRI integrity attributes
• All CDN URLs use exact version numbers (no @latest)
• CI verifies hashes match CDN content
• Hashes use SHA-384 algorithm (W3C recommended)
• Review SRI hashes after any CDN library updates

9. Content Security Framework¶

ContextForge implements a comprehensive 6-layer content security framework to protect against malicious content in user-submitted resources and prompts:

Layer 1: Size Validation¶

Configure content size limits to prevent DoS via oversized resource or prompt submissions:

# Defaults shown — adjust to your workload requirements
CONTENT_MAX_RESOURCE_SIZE=102400  # 100KB for resources (range: 1KB–10MB)
CONTENT_MAX_PROMPT_SIZE=10240     # 10KB for prompt templates (range: 512B–1MB)

• Review default size limits for your use case
• Monitor 413 responses in logs for legitimate content being blocked

Layer 2: PII Detection¶

Automatically detect and block Personally Identifiable Information (PII) in resource and prompt content:

# Enable PII detection (enabled by default)
CONTENT_PII_DETECTION_ENABLED=true

# Configure PII validation mode
CONTENT_PII_VALIDATION_MODE=strict  # Options: strict, moderate, lenient

# PII detection patterns (default patterns cover common PII types)
# CONTENT_PII_PATTERNS='["email", "ssn", "credit_card", "phone", "ip_address"]'

PII Detection Features:

• Email addresses: RFC 5322 compliant pattern
• Social Security Numbers: US SSN format (XXX-XX-XXXX)
• Credit card numbers: Luhn algorithm validation for major card types
• Phone numbers: International formats (E.164)
• IP addresses: IPv4 and IPv6 formats
• Custom patterns: Extensible via configuration

Validation Modes:

Layer 3: Malicious Pattern Detection¶

Detect and block common attack patterns including XSS, template injection, command injection, and SQL injection with context-aware validation:

# Enable pattern detection (enabled by default)
CONTENT_PATTERN_DETECTION_ENABLED=true

# Configure validation mode
CONTENT_PATTERN_VALIDATION_MODE=strict  # Options: strict, moderate, lenient

# Enable pattern caching for performance (recommended)
CONTENT_PATTERN_CACHE_ENABLED=true
CONTENT_PATTERN_MAX_CACHE_SIZE=1000

# Custom blocked patterns (JSON array of regex patterns)
# CONTENT_BLOCKED_PATTERNS='["custom_pattern_1", "custom_pattern_2"]'

Context-Aware Validation:

The system intelligently distinguishes between legitimate and malicious use of template syntax:

Example - Legitimate Prompt Template:

# ✅ This is ALLOWED in prompts
template = "Hello {{ user.name }}, welcome to {{ company }}!"

Example - Potential SSTI Attack in Resource:

# ❌ This is BLOCKED in resources
content = "Data: {{ config.secret_key }}"  # Potential server-side template injection

Default Attack Patterns (12 patterns):

1. XSS Attacks (3 patterns) - Always blocked:
2. Script tag injection: <script[^>]*>.*?</script>
3. Event handler injection: on\w+\s*=

4. JavaScript protocol: javascript:

5. Template Injection (3 patterns) - Context-aware:

6. Jinja2/Django: \{\{.*?\}\}|\{%.*?%\}
7. Mustache/Handlebars: \{\{.*?\}\}

8. Expression evaluation: \$\{.*?\}

9. Command Injection (3 patterns) - Always blocked:

10. Shell metacharacters: [;&|$()]`
11. Command chaining: &&|\|\||;

12. Backtick execution: `.*?`

13. SQL Injection (3 patterns) - Always blocked:

14. SQL keywords: (union|select|insert|update|delete|drop|create|alter)\s
15. Comment injection: --|\#|/\*|\*/
16. String concatenation: '\s*(or|and)\s*'

Validation Modes:

Note: Both strict and moderate modes use context-aware validation. The distinction is maintained for future enhancements.

Performance Optimization:

• Pattern Caching: Compiled regex patterns are cached for 10x performance improvement
• Cache Size: Default 1000 patterns, configurable via CONTENT_PATTERN_MAX_CACHE_SIZE
• Lazy Compilation: Patterns compiled on first use
• Thread-Safe: Cache uses threading locks for concurrent access

Security Checklist:

• Enable pattern detection in production (CONTENT_PATTERN_DETECTION_ENABLED=true)
• Use strict mode for production workloads
• Enable pattern caching for performance
• Monitor pattern violation logs for false positives
• Review custom patterns for your specific use case
• Test legitimate content doesn't trigger false positives
• Configure appropriate validation mode per environment

Layer 4: Content Sanitization¶

HTML and markdown content is sanitized using DOMPurify (client-side) and bleach (server-side):

• Removes dangerous HTML tags and attributes
• Preserves safe formatting elements
• Prevents XSS via DOM manipulation

Layer 5: Output Encoding¶

All content is properly encoded for the output context:

• HTML entity encoding for web display
• JSON escaping for API responses
• SQL parameterization for database queries

Layer 6: Content Security Policy (CSP)¶

Strict CSP headers prevent inline script execution:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' cdn.jsdelivr.net unpkg.com; style-src 'self' 'unsafe-inline' cdn.jsdelivr.net

Defense in Depth:

The 6-layer approach ensures that even if one layer is bypassed, other layers provide protection. For example:

1. Size limits prevent DoS before content is processed
2. PII detection blocks sensitive data leakage
3. Pattern detection catches attack attempts
4. Sanitization removes dangerous elements
5. Output encoding prevents injection
6. CSP blocks execution even if content is injected

Monitoring and Logging:

All content security violations are logged with:

• Violation type (size, PII, pattern, etc.)
• Sanitized user identifier (email masked)
• Timestamp and correlation ID
• Attack classification (XSS, SQLi, etc.)
• Validation mode and action taken

Example Log Entry:

{
  "timestamp": "2026-03-27T12:00:00Z",
  "level": "WARNING",
  "message": "Content pattern violation detected",
  "user": "user@*****.com",
  "violation_type": "xss_script_tag",
  "validation_mode": "strict",
  "action": "blocked",
  "correlation_id": "abc123"
}

Integration Points:

Content security is enforced at the service layer:

• resource_service.py: register_resource(), update_resource(), register_resources_bulk()
• prompt_service.py: register_prompt(), update_prompt(), register_prompts_bulk()

All 6 methods validate content before database persistence.

10. Container Security¶

# Run containers with security constraints
docker run \
  --read-only \
  --user 1001:1001 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  mcpgateway:latest

• Use minimal base images (UBI Micro)
• Run as non-root user
• Enable read-only filesystem
• Set resource limits (CPU, memory)
• Scan images for vulnerabilities

11. Secrets Management¶

• Never store secrets in environment variables directly
• Use a secrets management system (Vault, AWS Secrets Manager, etc.)
• Rotate credentials regularly
• Restrict container access to secrets
• Never commit .env files to version control

12. MCP Server Validation¶

Before connecting any MCP server:

• Verify server authenticity and source code
• Review server permissions and data access
• Test in isolated environment first
• Monitor server behavior for anomalies
• Implement rate limiting for untrusted servers

13. Database Security¶

• Use TLS for database connections
• Configure strong passwords
• Restrict database access by IP/network
• Enable audit logging
• Regular backups with encryption

14. Monitoring & Logging¶

• Set up structured logging without sensitive data
• Configure log rotation and secure storage
• Implement monitoring and alerting
• Set up anomaly detection
• Create incident response procedures

15. Integration Security¶

ContextForge should be integrated with:

• API Gateway for auth and rate limiting
• Web Application Firewall (WAF)
• Identity and Access Management (IAM)
• SIEM for security monitoring
• Load balancer with TLS termination

16. Well-Known URI Security¶

Configure well-known URIs appropriately for your deployment:

# For private APIs (default) - blocks all crawlers
WELL_KNOWN_ENABLED=true
WELL_KNOWN_ROBOTS_TXT="User-agent: *\nDisallow: /"

# For public APIs - allow health checks, block sensitive endpoints
# WELL_KNOWN_ROBOTS_TXT="User-agent: *\nAllow: /health\nAllow: /docs\nDisallow: /admin\nDisallow: /tools"

# Security contact information (RFC 9116)
WELL_KNOWN_SECURITY_TXT="Contact: mailto:security@example.com\nExpires: 2025-12-31T23:59:59Z\nPreferred-Languages: en"

Security considerations:

• Configure security.txt with current contact information
• Review robots.txt to prevent unauthorized crawler access
• Monitor well-known endpoint access in logs
• Update security.txt Expires field before expiration
• Consider custom well-known files only if necessary

17. Downstream Application Security¶

Applications consuming ContextForge data must:

• Validate all inputs from the gateway
• Implement context-appropriate sanitization
• Use Content Security Policy (CSP) headers
• Escape data for output context (HTML, JS, SQL)
• Implement their own authentication/authorization

🔐 Environment Variables Reference¶

Security-Critical Settings¶

# Core Security
MCPGATEWAY_UI_ENABLED=false              # Must be false in production
MCPGATEWAY_ADMIN_API_ENABLED=false       # Must be false in production
AUTH_REQUIRED=true                       # Enforce auth for every request
API_ALLOW_BASIC_AUTH=false               # Keep disabled (use JWT instead)
DOCS_ALLOW_BASIC_AUTH=false              # Keep disabled (use JWT instead)

# Feature Flags (disable unused features)
MCPGATEWAY_BULK_IMPORT_ENABLED=false
MCPGATEWAY_A2A_ENABLED=false
PUBLIC_REGISTRATION_ENABLED=false        # Disable user self-registration
ALLOW_TEAM_CREATION=false               # Disable self-service team creation
ALLOW_TEAM_JOIN_REQUESTS=false          # Disable self-service team joining
ALLOW_TEAM_INVITATIONS=false            # Disable team invitations

# Token Security
REQUIRE_TOKEN_EXPIRATION=true            # Reject tokens without exp claim
REQUIRE_JTI=true                         # Require JWT ID for revocation support

# Network Security
CORS_ENABLED=true
ALLOWED_ORIGINS=https://your-domain.com
SECURITY_HEADERS_ENABLED=true

# Logging (no sensitive data)
LOG_LEVEL=INFO               # Avoid DEBUG in production
LOG_TO_FILE=false            # Disable file logging unless required
LOG_ROTATION_ENABLED=false   # Enable only when log files are needed

Rate limiting: ContextForge does not ship a built-in global rate limiter. Enforce request throttling at an upstream ingress (NGINX, Envoy, API gateway) before traffic reaches the service.

🚀 Deployment Architecture¶

Recommended Production Architecture¶

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│                 │     │                 │     │                 │
│   WAF/CDN       │────▶│  Load Balancer │────▶│   API Gateway   │
│                 │     │   (TLS Term)    │     │  (Auth/Rate)    │
└─────────────────┘     └─────────────────┘     └────────┬────────┘
                                                          │
                                                          ▼
                                                 ┌─────────────────┐
                                                 │                 │
                                                 │  ContextForge    │
                                                 │  (Internal)     │
                                                 └────────┬────────┘
                                                          │
                              ┌───────────────────────────┼───────────────────────────┐
                              │                           │                           │
                              ▼                           ▼                           ▼
                     ┌─────────────────┐        ┌─────────────────┐        ┌─────────────────┐
                     │                 │        │                 │        │                 │
                     │  Trusted MCP    │        │    Database     │        │     Redis       │
                     │    Servers      │        │   (TLS/Auth)    │        │   (TLS/Auth)    │
                     └─────────────────┘        └─────────────────┘        └─────────────────┘

🔍 Security Validation¶

Pre-Production Checklist¶

1. Run Security Scans

   make security-all        # Run all security tools
   make security-report     # Generate security report
   make security-scan      # Show current local container review guidance
   

2. Validate Configuration

3. Review all environment variables

4. Confirm admin features disabled
5. Verify authentication enabled
6. Check TLS configuration
7. Confirm REQUIRE_JTI=true for token tracking
8. Confirm REQUIRE_TOKEN_EXPIRATION=true
9. Confirm PUBLIC_REGISTRATION_ENABLED=false

10. Confirm team governance flags are set appropriately

11. Test Security Controls

12. Attempt unauthorized access

13. Verify rate limiting works
14. Test input validation

15. Check error handling

16. Review Dependencies

    make pip-audit          # Check Python dependencies
    make sbom              # Generate software bill of materials
    

📚 Additional Resources¶

• Security Policy - Full security documentation
• Deployment Options - Various deployment methods
• Environment Variables - Complete configuration reference

⚡ Quick Start Security Commands¶

# Development (with security checks)
make security-all && make test && make run

# Production build
make docker-prod

# Security audit
make security-report

Remember: Security is a shared responsibility. ContextForge provides some security controls, but you must properly configure and integrate it within a comprehensive security architecture.