Security Policy

Security Policy

Table of Contents

Overview

Caxton is a multi-agent orchestration platform that prioritizes security through WebAssembly isolation, FIPA protocol validation, and comprehensive observability. This document outlines our security practices, vulnerability reporting procedures, and security guarantees.

Security Architecture

WebAssembly Isolation

Caxton uses WebAssembly (WASM) as a fundamental security boundary:

  • Memory Isolation: Each agent runs in a separate WASM instance with isolated linear memory
  • Resource Limits: Configurable memory and CPU time limits prevent resource exhaustion
  • System Call Restrictions: WASM sandbox prevents direct system access
  • Capability-Based Security: Agents can only access explicitly granted capabilities
// Example: Strict isolation configuration for production
IsolationConfig::strict() {
    memory_limit_bytes: Some(16 * 1024 * 1024), // 16MB
    cpu_time_limit_ms: Some(1000),              // 1 second
    network_access: false,
    filesystem_access: false,
}

FIPA Message Security

All inter-agent communication uses validated FIPA messages:

  • Message Validation: All messages are parsed and validated before processing
  • Conversation Tracking: Deterministic conversation IDs prevent replay attacks
  • Content Sanitization: Message content is sanitized based on content type
  • Size Limits: Messages have configurable size limits to prevent DoS attacks

Observability-First Security

  • Structured Logging: All security events are logged with structured data
  • Distributed Tracing: Security-relevant operations are traced end-to-end
  • Metrics Collection: Security metrics are collected and monitored
  • Audit Trail: Complete audit trail of all agent interactions

Security Guarantees

Agent Isolation

  1. Memory Safety: Agents cannot access each other’s memory or host system memory
  2. Resource Limits: Agents cannot consume more resources than allocated
  3. System Boundaries: Agents cannot make unauthorized system calls
  4. Network Isolation: Agents cannot make unauthorized network connections

Message Security

  1. Validation: All messages are validated against FIPA protocol standards
  2. Integrity: Message integrity is maintained through the entire processing pipeline
  3. Authentication: Message senders are authenticated through agent lifecycle management
  4. Non-repudiation: All messages are logged with sender identification

Platform Security

  1. Least Privilege: Components run with minimal required privileges
  2. Defense in Depth: Multiple security layers prevent single points of failure
  3. Fail-Safe Defaults: Secure defaults are used throughout the system
  4. Security Monitoring: Continuous monitoring detects security anomalies

Threat Model

In Scope

  • Malicious WASM modules
  • Resource exhaustion attacks
  • Message injection/tampering
  • Privilege escalation attempts
  • Information disclosure
  • Denial of service attacks

Out of Scope

  • Physical security of host systems
  • Network infrastructure security
  • Operating system vulnerabilities
  • Third-party service vulnerabilities

Security Controls

Development Security

  • Secure Coding: Rust memory safety prevents common vulnerability classes
  • Dependency Management: All dependencies are audited for known vulnerabilities using cargo-deny
  • Static Analysis: Code is analyzed with Clippy and additional security lints
  • Testing: Comprehensive security testing including fuzzing and property-based tests

Cargo-Deny Integration

Cargo-deny provides comprehensive dependency security validation:

# Install cargo-deny for security auditing
cargo install cargo-deny

# Run complete security audit
cargo deny check

# Check specific categories
cargo deny check advisories    # Vulnerability scanning
cargo deny check licenses      # License compliance
cargo deny check bans          # Dependency policies
cargo deny check sources       # Supply chain security

Security Policy Configuration: Our deny.toml configuration enforces:

  • Zero tolerance for vulnerabilities in runtime dependencies (enhanced beyond cargo audit)
  • Approved license whitelist for enterprise compliance
  • Supply chain validation restricting to crates.io registry
  • Dependency hygiene warnings for multiple versions and maintenance status

Migration from cargo audit: We’ve evolved from basic cargo audit vulnerability checking to comprehensive cargo deny policy enforcement for enterprise-grade security validation.

See deny.toml for complete configuration details.

Build Security

  • Reproducible Builds: Container images are built reproducibly with SBOMs
  • Supply Chain Security: All dependencies are verified and pinned
  • Container Hardening: Containers run as non-root with minimal attack surface
  • Image Scanning: Container images are scanned for vulnerabilities

Runtime Security

  • Resource Monitoring: Runtime resource usage is monitored and limited
  • Network Policies: Strict network policies limit communication
  • Security Contexts: Containers run with restrictive security contexts
  • Audit Logging: All security-relevant events are logged and monitored

Vulnerability Management

Supported Versions

We provide security updates for the following versions:

Version Supported
0.1.x :white_check_mark:
< 0.1 :x:

Reporting Security Vulnerabilities

Please do not report security vulnerabilities through public GitHub issues.

Instead, please report them by emailing john+caxton-security-report@johnwilger.com or through GitHub’s private vulnerability reporting feature (preferred).

For automated vulnerability reporting, see our security.txt file which follows RFC 9116 standards.

Security.txt Implementation

Our security.txt provides machine-readable security contact information:

  • Primary Contact: john+caxton-security-report@johnwilger.com for vulnerability reports
  • Policy Location: Comprehensive disclosure guidelines at https://jwilger.github.io/caxton/security/policy
  • Acknowledgments: Public recognition for responsible disclosure at https://jwilger.github.io/caxton/security/acknowledgments
  • Expiration: Annual renewal required (expires 2025-12-31)
  • Language: English for fastest response times

Best Practices Implemented:

  • Located at both /.well-known/security.txt and /security.txt for discoverability
  • Signed with PGP key for authenticity (planned)
  • Regular expiration updates to ensure current contact information
  • Clear scope definition in linked policy document

When reporting a vulnerability, please include:

  • Description of the vulnerability
  • Steps to reproduce (if applicable)
  • Potential impact assessment
  • Suggested remediation (if any)

Response Timeline

  • Acknowledgment: Within 24 hours
  • Initial Assessment: Within 72 hours
  • Detailed Response: Within 1 week
  • Fix Timeline: Varies by severity (see below)

Severity Classification

Critical (Fix within 24 hours)

  • Remote code execution
  • Authentication bypass
  • Data exfiltration
  • Complete system compromise

High (Fix within 1 week)

  • Privilege escalation
  • Denial of service
  • Information disclosure
  • Security control bypass

Medium (Fix within 1 month)

  • Less severe information disclosure
  • Limited privilege escalation
  • Security feature weakness

Low (Fix in next release)

  • Security hardening opportunities
  • Defense-in-depth improvements
  • Minor information leaks

Security Update Process

  1. Validation: Vulnerability is validated and assessed
  2. Fix Development: Security fix is developed and tested
  3. Security Review: Fix undergoes security review
  4. Release Preparation: Release notes and advisories are prepared
  5. Coordinated Disclosure: Fix is released with security advisory
  6. Post-Release: Monitoring for successful deployment

Security Testing

Automated Testing

Our CI/CD pipeline includes:

  • Security Audit: cargo deny check provides comprehensive dependency validation
  • Vulnerability Database: Automated checks against RustSec Advisory Database
  • License Compliance: Automated license compatibility verification
  • Supply Chain Security: Registry and source validation
  • Static Analysis: Security-focused static analysis tools
  • Container Scanning: Vulnerability scanning of container images
  • Fuzzing: Automated fuzzing of critical security components

CI Security Workflow

Every pull request triggers security validation:

# Automated security checks in GitHub Actions
- name: Security Audit
  run: cargo deny check

- name: Dependency Vulnerability Scan
  run: cargo deny check advisories

- name: License Compliance Check
  run: cargo deny check licenses

See .github/workflows/ for complete CI configuration.

Manual Testing

Regular manual security testing includes:

  • Penetration Testing: External security assessments
  • Code Review: Security-focused code reviews
  • Threat Modeling: Regular threat model updates
  • Incident Response: Tabletop exercises and response testing

Bug Bounty Program

We are planning to launch a bug bounty program. Details will be announced on our security page.

RFC 9116 Security.txt Best Practices

Implementation Details

Our security.txt implementation follows RFC 9116 specifications for machine-readable security policies:

Required Fields

  • Contact: Primary security email (john+caxton-security-report@johnwilger.com) with 24-hour response commitment
  • Expires: Annual renewal with clear expiration date to ensure current information

Optional Fields (Enhanced Disclosure)

  • Acknowledgments: Public recognition page for responsible disclosure participants
  • Policy: Comprehensive vulnerability disclosure policy with scope and safe harbor provisions
  • Preferred-Languages: English prioritized for fastest response times
  • Canonical: Authoritative location preventing stale security contact information

Security.txt Validation

Validate our security.txt implementation:

# Check RFC 9116 compliance
curl -s https://jwilger.github.io/caxton/.well-known/security.txt | \
  security-txt-validator

# Verify expiration date
grep "Expires:" .well-known/security.txt

# Test contact accessibility
echo "security-test@example.com" | \
  mail -s "Security Test" john+caxton-security-report@johnwilger.com

Deployment Considerations

  • Dual Location: Available at both /.well-known/security.txt and /security.txt
  • HTTPS Required: Only served over encrypted connections
  • Regular Updates: Automated expiration monitoring with renewal alerts
  • Backup Contacts: Secondary contacts for incident response team
  • PGP Signing: Planned cryptographic signature for authenticity verification

Integration with Vulnerability Management

Security.txt coordinates with our broader vulnerability management:

  1. Automated Reporting: Enables security scanners to report findings directly
  2. Researcher Onboarding: Provides clear entry point for security researchers
  3. Process Documentation: Links to detailed disclosure policies and procedures
  4. Recognition Program: Acknowledges responsible disclosure through public acknowledgments

Security Configuration

Production Deployment

For production deployments, ensure:

# Kubernetes security context
securityContext:
  runAsNonRoot: true
  runAsUser: 65534
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

// Caxton security configuration
CaxtonConfig {
    wasm_isolation: IsolationConfig::strict(),
    fipa_validation: true,
    security_audit_logs: true,
    resource_limits: ResourceLimits::production(),
    observability: ObservabilityConfig::security_focused(),
}

Environment Variables

Security-related environment variables:

  • CAXTON_WASM_ISOLATION=strict: Enable strict WASM isolation (see WebAssembly Isolation)
  • CAXTON_FIPA_VALIDATION=enabled: Enable FIPA message validation (see FIPA Message Security)
  • CAXTON_SECURITY_AUDIT=enabled: Enable security audit logging (see Observability-First Security)
  • CAXTON_LOG_LEVEL=info: Set appropriate logging level for security monitoring

Integrated Security Workflow

Caxton’s security architecture integrates multiple layers:

  1. Development Phase: Cargo-deny validates dependencies before deployment
  2. Build Phase: CI security checks prevent vulnerable code from merging
  3. Runtime Phase: WebAssembly isolation and FIPA validation protect against runtime threats
  4. Monitoring Phase: Observability provides continuous security visibility
  5. Response Phase: RFC 9116 security.txt enables coordinated vulnerability disclosure

This defense-in-depth approach ensures security at every stage of the software lifecycle.”

Compliance

Standards Compliance

Caxton strives to comply with:

  • NIST Cybersecurity Framework: Risk-based security approach
  • OWASP Top 10: Protection against common web application vulnerabilities
  • CWE/SANS: Common weakness enumeration practices
  • ISO 27001: Information security management best practices

Security Certifications

We are working toward:

  • SOC 2 Type II certification
  • Common Criteria evaluation
  • FIPS 140-2 compliance for cryptographic components

Security Resources

Security Documentation

Core Security Architecture

Security Configuration Files

Developer Security Resources

External Security Standards

Run security checks

Security Development Workflows

Daily Development Security Checks

Integrate security validation into your development workflow:

# Install security tooling (one-time setup)
cargo install cargo-deny cargo-geiger
cargo install --locked cargo-fuzz

# Pre-commit security validation
cargo deny check              # Complete security audit (replaces cargo audit)
cargo clippy -- -D warnings  # Security-focused linting
cargo geiger                  # Unsafe code detection

# Vulnerability-specific checks
cargo deny check advisories   # Check for known CVEs (evolved from cargo audit)
cargo deny check licenses     # Verify license compliance
cargo deny check sources      # Validate supply chain

Security Testing Procedures

# Property-based security testing
cargo test --lib security_    # Run security-focused tests

# Fuzzing critical components
cargo fuzz list              # List fuzz targets
cargo fuzz run wasm_validator # Fuzz WASM validation
cargo fuzz run message_parser # Fuzz FIPA message parsing

# Integration security testing
cargo test --test security_   # Run security integration tests

Security Review Checklist

Before merging security-sensitive changes:

  1. Dependency Review: Run cargo deny check and review any new dependencies
  2. Vulnerability Scan: Verify no new advisories with cargo deny check advisories
  3. License Validation: Confirm license compatibility with cargo deny check licenses
  4. Unsafe Code Review: Check cargo geiger output for new unsafe blocks
  5. Test Coverage: Ensure security tests cover new functionality
  6. Documentation: Update security documentation for new features

Security Contacts

  • Security Team: john+caxton-security-report@johnwilger.com
  • Incident Response: john+caxton-security-report@johnwilger.com
  • General Inquiries: john+caxton-security-report@johnwilger.com

Changelog

Security Updates

All security updates are documented in our CHANGELOG.md with the [SECURITY] tag.

Recent security improvements:

  • v0.1.0: Initial security architecture implementation
  • v0.1.0: WebAssembly isolation boundaries
  • v0.1.0: FIPA message validation framework
  • v0.1.0: Comprehensive security testing suite

For the latest security information, please visit our security page or subscribe to our security announcements.

Edit this page on GitHub →