• Overview
• Security Architecture
  • Hybrid Trust Model
  • MCP Tool Sandboxing
  • Configuration Security
  • Embedded Database Security
  • REST API Security
• Security Guarantees
• Threat Model
• Security Controls
  • Development Security
  • Build Security
  • Runtime Security
• Vulnerability Management
  • Reporting Security Vulnerabilities
  • Response Timeline
  • Severity Classification
• Security Testing
• RFC 9116 Security.txt Best Practices
• Compliance
• Security Resources
• Security Contacts

Caxton is a configuration-driven multi-agent platform that prioritizes security through a hybrid trust model: trusted configuration agents run in the host runtime for performance, while untrusted MCP tools are isolated in WebAssembly sandboxes. This document outlines our security practices, vulnerability reporting procedures, and security guarantees for our single-binary, zero-dependency deployment architecture.

Caxton employs a hybrid security architecture:

• Configuration Agents: TOML-based agents run in the host runtime for performance, representing the primary trusted boundary
• MCP Tool Isolation: Model Context Protocol tools execute in WebAssembly sandboxes with strict resource and capability limits
• Single Binary Deployment: Zero external dependencies reduce attack surface and eliminate supply chain risks from runtime dependencies
• Embedded Database: Local SQLite storage eliminates network database security concerns

MCP tools represent the untrusted boundary in our security model:

• Tools run in isolated WebAssembly environments with no direct system access
• Resource consumption is limited through configurable memory and CPU constraints
• All system interactions are mediated through capability-based APIs
• Network access is restricted and must be explicitly granted per tool

TOML configuration files are validated against strict schemas with hot-reload safety checks. Built-in agent templates undergo cryptographic verification to prevent tampering.

The REST management API requires authentication and implements role-based authorization with rate limiting. The embedded SQLite database uses prepared statements and restrictive file permissions.

1. Memory Safety: MCP tools cannot access host system memory or other tool instances
2. Resource Limits: Tools cannot consume more resources than allocated through WebAssembly constraints
3. System Boundaries: Tools cannot make unauthorized system calls outside capability grants
4. Network Isolation: Tools have no direct network access unless explicitly granted

1. Schema Validation: All TOML configurations are validated against strict schemas
2. Hot-Reload Safety: Configuration changes undergo security validation before application
3. Template Integrity: Built-in agent templates are cryptographically verified
4. File System Security: Configuration files use restrictive permissions

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: Comprehensive logging and monitoring detect security anomalies

• Vulnerabilities in Caxton's source code and design
• Insecure default configurations or behaviors
• Dependency vulnerabilities in our build artifacts
• Supply chain security of our development and release process
• Design flaws that could enable privilege escalation or data exposure
• Security issues in our architectural decisions and implementation

• Operational security of systems running Caxton
• Network infrastructure security where Caxton is deployed
• Physical security of host systems
• Operating system configuration and hardening
• Third-party LLM service security and access controls
• User authentication and authorization policies
• Data protection and encryption at rest
• Compliance with specific regulatory frameworks

Note: As per our licensing terms, we assume no responsibility for security issues arising from deployment, configuration, or operational use of Caxton. Users are responsible for implementing appropriate security controls for their specific use cases and environments.

• Secure Coding: Rust memory safety prevents common vulnerability classes
• Dependency Management: All dependencies are audited for vulnerabilities using cargo-deny
• Static Analysis: Code undergoes security-focused static analysis
• Security Testing: Comprehensive security testing including fuzzing and property-based tests

• Supply Chain Security: All dependencies are verified and audited before inclusion
• Reproducible Builds: Build process ensures consistent, verifiable artifacts
• Vulnerability Scanning: Automated scanning for known vulnerabilities in dependencies
• License Compliance: All dependencies comply with approved license requirements

• Memory Safety: Rust language guarantees prevent entire classes of vulnerabilities
• Input Validation: All external inputs undergo strict validation
• Secure Defaults: Default configurations prioritize security over convenience
• Capability-Based Architecture: Components operate with minimal necessary privileges

We provide security updates for the following versions:

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

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.

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)

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

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

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

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

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

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

Our CI/CD pipeline includes automated security validation on every pull request:

• Dependency Auditing: Comprehensive dependency vulnerability scanning
• License Compliance: Automated license compatibility verification
• Supply Chain Security: Validation of dependency sources and integrity
• Static Analysis: Security-focused code analysis
• Fuzzing: Automated fuzzing of critical parsing and validation components

Regular manual security assessments include:

• Security-Focused Code Reviews: All changes undergo security review
• Threat Model Updates: Regular review and updates of our threat model
• Security Architecture Review: Periodic evaluation of security design decisions

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

• 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

• 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

Our security.txt implementation follows RFC 9116 best practices:

• Dual Location: Available at both /.well-known/security.txt and /security.txt
• HTTPS Only: Served exclusively over encrypted connections
• Regular Updates: Annual expiration with automated renewal monitoring
• PGP Signing: Cryptographic signature verification (planned)
• Contact Verification: Regular validation of contact information accessibility

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

Caxton development follows established security frameworks:

• OWASP Secure Coding Practices: Applied throughout development process
• CWE/SANS Top 25: Proactive prevention of common weaknesses
• NIST Secure Software Development Framework: Integrated security practices

• Architecture Decision Records: Security-related architectural decisions
• deny.toml: Cargo-deny security policy configuration
• .well-known/security.txt: RFC 9116 security contact information

• RFC 9116 Security.txt: Security contact standard
• RustSec Advisory Database: Vulnerability tracking
• OWASP Application Security: Web application security guidance

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

For the latest security information, please visit our security page.