punch

Punch Security Architecture

Punch implements 18 security layers — the most comprehensive security model of any agent framework.

Overview

Security in an agent system is fundamentally different from traditional application security. Agents can execute arbitrary tools, access external systems, and operate autonomously for extended periods. A single vulnerability can cascade through an entire fleet of agents.

Punch takes a defense-in-depth approach with 18 interlocking security layers, each designed to contain failures and prevent escalation.

The 18 Security Layers

Layer 1: Capability-Based Access Control

Every action an agent can perform requires an explicit CapabilityGrant. Agents operate on the principle of least privilege — they can only use moves (tools) that are explicitly granted in their manifest.

pub struct CapabilityGrant {
    pub capability: Capability,
    pub scope: GrantScope,      // Global, PerBout, TimeLimited
    pub granted_by: String,     // Who authorized this grant
    pub expires_at: Option<DateTime<Utc>>,
}

Key properties:

Layer 2: Per-Agent Sandboxing

Each fighter operates in an isolated capability space. Fighter A’s capabilities are completely invisible to Fighter B, even if they share the same Ring instance.

Layer 3: API Key Vault

Secrets are never stored in configuration files. Instead, configuration references environment variable names:

[default_model]
api_key_env = "ANTHROPIC_API_KEY"   # References $ANTHROPIC_API_KEY

Key properties:

Layer 4: Ed25519 Request Signing

All inter-component messages within Punch are cryptographically signed using Ed25519:

Layer 5: AES-256-GCM Encryption at Rest

The memory substrate (SQLite database) is encrypted using AES-256-GCM authenticated encryption:

Layer 6: Argon2id Key Derivation

The master encryption key is derived using Argon2id, a memory-hard key derivation function:

Layer 7: Rate Limiting and Quotas

The Scheduler enforces per-agent rate limits and resource quotas:

Layer 8: Input Sanitization

All user inputs are sanitized before reaching the LLM:

Layer 9: Output Filtering

Agent outputs are filtered before being returned to users:

Layer 10: Audit Logging

Every agent action is logged with full traceability:

Layer 11: TLS-Only External Communications

All outbound network connections use TLS via rustls:

Layer 12: CORS and Origin Validation

The Arena API validates request origins:

Layer 13: Token Rotation

Session tokens are automatically rotated on a configurable schedule:

Layer 14: Memory Decay

Old conversation data automatically decays, reducing the exposure window of sensitive information:

relevance(t) = initial_score * e^(-decay_rate * t)

Layer 15: Zeroize Secrets

All cryptographic material is zeroized from memory when dropped:

Layer 16: Resource Limits

Per-agent resource limits prevent denial-of-service and runaway costs:

Layer 17: Gorilla Containment Zones

Each gorilla runs in an isolated execution environment — a containment zone — with its own capability boundary:

Why this matters: Gorillas operate autonomously on schedules. A compromised gorilla running 24/7 is far more dangerous than a compromised interactive fighter. Containment zones ensure that even a fully compromised gorilla cannot affect the rest of the system.

Layer 18: Cross-Troop Privilege Firewall

Troops (coordinated agent squads) cannot escalate each other’s capabilities:

Why this matters: Without this firewall, an attacker could create a troop containing a low-privilege agent and a high-privilege agent, then use the troop coordination mechanism to launder requests through the high-privilege agent. The firewall prevents this by ensuring that troop membership never increases any individual agent’s capabilities.

Security Comparison

Security Feature Punch OpenFang CrewAI AutoGen LangGraph
Capability-based access Yes Yes No No No
Per-agent sandboxing Yes Yes No No No
Secret vault Yes Yes Partial No No
Request signing Yes Yes No No No
Encryption at rest Yes Yes No No No
Memory-hard KDF Yes Yes No No No
Rate limiting Yes Yes No No Partial
Input sanitization Yes Yes Partial Partial Partial
Output filtering Yes Yes No No No
Audit logging Yes Yes Partial Partial Partial
TLS enforcement Yes Yes Partial Partial Partial
CORS validation Yes Yes N/A N/A Partial
Token rotation Yes Yes No No No
Memory decay Yes Yes No No No
Zeroize secrets Yes Yes No No No
Resource limits Yes Yes No No No
Gorilla containment Yes No No No No
Troop privilege firewall Yes No No No No
Total layers 18 16 3 2 4

Threat Model

Punch’s security architecture is designed to protect against these threat categories:

External Threats

Internal Threats

Operational Threats

Reporting Security Issues

If you discover a security vulnerability in Punch, please report it responsibly:

  1. Do not open a public GitHub issue
  2. Email security@humancto.com with details
  3. Include steps to reproduce, impact assessment, and suggested fix if possible
  4. We will acknowledge within 48 hours and provide a fix timeline within 7 days
This site is open source. Improve this page.