This document describes the security assumptions, threats, and mitigations for the Kernels system.
The system defines the following trust boundaries:
┌─────────────────────────────────────────────────────────────────┐
│ TRUSTED ZONE │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ Operator │ │ Kernel Code │ │ Tools │ │
│ │ (Policy) │ │ (This Repo) │ │ (Registered) │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
Trust Boundary
│
┌─────────────────────────────────────────────────────────────────┐
│ UNTRUSTED ZONE │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ Agents │ │ Requests │ │ External │ │
│ │ │ │ │ │ Systems │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
└─────────────────────────────────────────────────────────────────┘
The security model assumes:
| Assumption | Rationale |
|---|---|
| Operator is trusted | Operator defines policy; malicious policy is out of scope |
| Kernel code is trusted | Supply chain security is a separate concern |
| Registered tools are trusted | Tool registration is an operator action |
| Execution environment is trusted | OS/hardware security is out of scope |
| Hash algorithm is secure | SHA-256 is cryptographically secure |
Threat: An agent submits a malformed request to bypass validation.
Mitigation:
- Request validation checks all required fields
- Type checking enforces correct data types
- Size limits prevent resource exhaustion
- Fail-closed semantics deny malformed requests
Residual Risk: None if validation is correctly implemented.
Threat: An agent attempts to invoke tools outside its allowed set.
Mitigation:
- Jurisdiction policy explicitly lists allowed actors and tools
- Wildcard (
*) must be explicitly configured - Policy evaluation occurs before execution
- Denied requests are audited
Residual Risk: Misconfigured policy could allow unintended access.
Threat: An agent crafts an ambiguous request that could be interpreted in multiple ways.
Mitigation:
- Ambiguity heuristics detect common patterns
- Empty or whitespace-only intents are rejected
- Overly long intents are rejected
- Missing tool names in tool_call are rejected
- Fail-closed: ambiguous requests are denied
Residual Risk: Novel ambiguity patterns may not be detected.
Threat: An attacker attempts to modify the audit ledger to hide activity.
Mitigation:
- Append-only ledger prevents modification
- Hash chain detects tampering
- Replay verification validates integrity
- Evidence bundles include root hash
Residual Risk: In-memory ledger could be modified by compromised kernel code.
Threat: An attacker attempts to force the kernel into an invalid state.
Mitigation:
- State machine enforces allowed transitions
- Invalid transitions raise StateError
- Terminal state (HALTED) has no outgoing transitions
- State assertions verify expected state
Residual Risk: None if state machine is correctly implemented.
Threat: An agent abuses a tool to perform unintended operations.
Mitigation:
- Tools must be explicitly registered
- No dynamic import or eval
- Tool parameters are validated
- Tool execution is synchronous (no background execution)
Residual Risk: Malicious tool implementation (trusted zone compromise).
Threat: An agent submits many requests to exhaust resources.
Mitigation:
- Parameter size limits
- Intent length limits
- Synchronous processing (no unbounded queues)
Residual Risk: Rate limiting is not implemented; external rate limiting recommended.
Threat: Sensitive information in requests is exposed through audit export.
Mitigation:
- Parameters are hashed, not stored in full
- Evidence is hashed, not stored in full
- Audit export is an explicit operator action
Residual Risk: Intent field contains request description; may include sensitive data.
The following threats are explicitly out of scope:
| Threat | Reason |
|---|---|
| Compromised operator | Operator is in trusted zone |
| Supply chain attacks | Code integrity is a separate concern |
| Side-channel attacks | Requires hardware/OS level mitigations |
| Network attacks | Transport security is a separate concern |
| Physical attacks | Physical security is out of scope |
| Malicious tools | Tools are in trusted zone |
-
Minimize allowed actors and tools. Use explicit allowlists rather than wildcards.
-
Review audit logs regularly. Detect anomalous patterns early.
-
Implement external rate limiting. Protect against denial of service.
-
Secure the execution environment. Use appropriate OS and network security.
-
Verify tool implementations. Ensure registered tools behave as expected.
-
Validate evidence bundles. Always replay and verify before trusting audit data.
-
Store evidence bundles securely. Protect exported evidence from tampering.
-
Implement transport security. Use TLS for network communication.
-
Log kernel operations externally. Maintain independent audit trail.
-
Do not modify core invariants. Changes require security review.
-
Test edge cases thoroughly. Ensure fail-closed behavior is maintained.
-
Review all tool implementations. Tools execute with kernel trust.
-
Keep dependencies minimal. Standard library only reduces attack surface.