| Threat | Mitigation |
|---|---|
| Tool-space interference (agent calls wrong tool) | Capability registry + policy gate before any execution |
| Confused deputy attack | Tokens are bound to principal_id — cannot be reused by another principal |
| Token forgery / tampering | HMAC-SHA256 signature; any bit flip → TokenInvalid |
| Token replay after expiry | Expiry checked on every verify() call |
| Context injection via raw tool output | Firewall always transforms RawResult → Frame; raw data never reaches LLM by default |
| PII / PCI leakage | Redaction + allowed_fields enforcement in the firewall |
| Privilege escalation via WRITE/DESTRUCTIVE | Policy engine enforces role requirements |
| Audit evasion | Every invoke() creates an immutable ActionTrace |
A CapabilityToken binds:
capability_id— which capability is authorizedprincipal_id— who the token was issued toconstraints— max_rows, allowed_fields, etc. (signed into the token)expires_at— validity window
Any change to these fields invalidates the HMAC signature.
Consider an agent that obtains a token for billing.list_invoices then passes it to a different agent. The second agent cannot use it because verify() checks that token.principal_id == expected_principal_id.
v0.1 is not production-hardened for real authentication.
- HMAC tokens are tamper-evident but not encrypted. Do not put sensitive data in token fields.
- The
AGENT_KERNEL_SECRETmust be kept secret. Rotate it if compromised. - The default
InMemoryDriverhas no persistence — suitable for testing only. - PII redaction is heuristic (regex-based). It is not a substitute for proper data governance.
- There is no rate limiting or quota enforcement in v0.1.