Agentic Zero-Trust Security
Cryptographic security architecture for autonomous AI agent systems. This skill covers the intersection of traditional security engineering and the unique challenges of agents that plan, persist, delegate, and execute across trust boundaries.
Core principle: Never trust, always verify — applied to every agent-to-agent message, every skill loaded, every tool invoked, and every result returned.
Decision Points
1. Threat Level → Verification Strategy
Threat Level Assessment:
├── PUBLIC (internet agents, unknown skills)
│ ├── Actions: Full mTLS + JWS + capability tokens + WASM sandbox
│ ├── Audit: Every action logged with Merkle proof
│ └── TTL: Max 5min capability lifetime
├── INTERNAL (trusted agent cluster)
│ ├── Actions: mTLS + JWS + capabilities (longer TTL)
│ ├── Audit: Aggregate logging with daily root publish
│ └── TTL: Max 1hr capability lifetime
└── DEV/TEST (localhost, development)
├── Actions: Optional mTLS + basic capabilities
├── Audit: Local file logs (no Merkle tree)
└── TTL: Max 24hr capability lifetime
2. Agent Request → Capability Check → Grant/Deny Logic
Incoming Agent Request Processing:
├── 1. Verify mTLS certificate chain
│ ├── Valid CA signature? → Continue
│ └── Invalid/expired? → REJECT immediately
├── 2. Parse JWS message envelope
│ ├── Signature valid + not expired? → Continue
│ ├── Replay detected (jti cache)? → REJECT
│ └── Signature invalid? → REJECT + log security event
├── 3. Check required capabilities
│ ├── Agent holds exact capability? → GRANT
│ ├── Agent holds broader capability? → ATTENUATE + GRANT
│ ├── Capability expired? → REJECT + force refresh
│ └── No matching capability? → REJECT + suggest minimal grant
└── 4. Execute with sandbox constraints
├── WASM skills: CPU/memory limits enforced
├── File operations: Path validation against capabilities
└── Network calls: Destination validation against capabilities
3. Delegation Chain → Trust Depth Decision
Capability Delegation Request:
├── Parent capability delegatable=true?
│ ├── Yes → Check remaining depth
│ │ ├── Depth > 0 → Allow with depth-1
│ │ └── Depth = 0 → REJECT (max delegation reached)
│ └── No → REJECT (not delegatable)
├── Requested actions ⊆ parent actions?
│ ├── Yes → Allow subset
│ └── No → REJECT (cannot escalate privileges)
└── Trust boundary crossed?
├── Same orchestrator domain → Allow
└── Different domain → Require explicit cross-domain capability
Failure Modes
1. Ambient Authority Leakage
Detection: grep -r "process.env" agent_code/ shows environment variable access without capability check
Symptom: Agent accesses resources it shouldn't have permissions for
Fix: Replace with explicit capability tokens scoped to exact resources needed
2. Message Replay Attack
Detection: Multiple audit log entries with identical jti (message ID) or timestamps within replay window
Symptom: Agent receives and processes the same command multiple times
Fix: Implement jti deduplication cache with TTL matching message expiry
3. Capability Escalation Through Delegation
Detection: Child capability has more actions than parent, or delegation depth exceeded configured maximum
Symptom: Sub-agents gain more privileges than their parent delegator intended
Fix: Enforce attenuation invariant: child capabilities ⊆ parent capabilities at delegation time
4. Sandbox Escape Through Resource Exhaustion
Detection: Agent CPU usage >95% for >30 seconds, or memory usage approaching sandbox limits
Symptom: Agent attempts infinite loops or excessive memory allocation to break out of constraints
Fix: Hard-kill agent process at resource limits, implement fuel-based execution metering
5. Trust-on-First-Use (TOFU) Certificate Acceptance
Detection: Agent accepts certificate without CA verification on first connection
Symptom: Man-in-the-middle attacks succeed by presenting any certificate
Fix: Pre-provision all agent certificates, maintain explicit trust store, reject unknown CAs
Worked Examples
Example 1: Multi-Agent Message Signing Pipeline
Scenario: Research agent needs to pass analysis to code generation agent, then to review agent.
Setup Phase:
// Orchestrator mints capabilities
const researchCap = mint.mint('fs:/tmp/research/**', ['read','write'], 'agent-research-001');
const codegenCap = mint.mint('fs:/workspace/src/**', ['read','write'], 'agent-codegen-001');
const reviewCap = mint.mint('fs:/workspace/**', ['read'], 'agent-review-001');
Message Flow:
-
Research → Codegen: Research agent creates JWS-signed message:
Header: {alg: 'EdDSA', kid: 'agent-research-001/v1'}
Payload: {
iss: 'agent-research-001',
sub: 'agent-codegen-001',
dag_id: 'proj-alpha-v1',
action: 'task',
body: {analysis: "API needs OAuth2 flow", output_path: "/tmp/research/api_analysis.json"}
}
-
Codegen Verification: Codegen agent receives message:
- Verifies JWS signature against research agent's public key
- Checks message TTL (not expired)
- Validates jti not in replay cache
- Confirms dag_id matches current execution context
- Expert catch: Verifies research agent had capability for output_path
-
Codegen → Review: Codegen creates signed result:
{
"iss": "agent-codegen-001",
"sub": "agent-review-001",
"action": "result",
"body": {"generated_files": ["/workspace/src/auth.ts"], "confidence": 0.87}
}
Novice miss: Would skip jti replay protection, allowing duplicate processing.
Expert insight: Audit trail shows complete message chain with cryptographic proof of custody.
Example 2: Capability Token Issuance with Attenuation
Scenario: Main agent needs to delegate file analysis to specialized sub-agent, but restrict access to sensitive directories.
Initial Grant:
// Orchestrator grants broad filesystem access
const mainCap = mint.mint('fs:/project/**', ['read','write','execute'], 'agent-main', {
delegatable: true,
maxDepth: 2,
ttlSeconds: 3600
});
Attenuation Decision Tree:
Main agent evaluating delegation request:
├── Sub-agent requests: fs:/project/src/** [read]
│ ├── /project/src/** ⊂ /project/** ? YES
│ ├── [read] ⊂ [read,write,execute] ? YES
│ ├── Delegation depth 2 > 0 ? YES
│ └── GRANT: Create attenuated capability
├── Sub-agent requests: fs:/project/secrets/** [read]
│ ├── Path contains "secrets" → Security policy violation
│ └── REJECT: Sensitive path exclusion
└── Sub-agent requests: fs:/etc/passwd [read]
├── /etc/passwd ⊂ /project/** ? NO
└── REJECT: Outside authorized scope
Attenuated Capability Generated:
const subCap = mint.attenuate(mainCap, 'agent-analyzer-001', ['read']);
// Results in: fs:/project/src/** [read] delegatable=true maxDepth=1 ttl=3600s
Novice miss: Would grant full parent capability without restriction.
Expert insight: Attenuation enforces "never escalate privileges" at the cryptographic level.
Example 3: Sandbox Policy Violation Detection with Trade-off Analysis
Scenario: Code generation agent attempts to access network during execution, violating sandbox policy.
Sandbox Configuration:
const codegenSandbox = {
fileRead: ['/workspace/src/**', '/workspace/package.json'],
fileWrite: ['/workspace/src/**'],
netConnect: false, // NO network access
maxExecutionMs: 300000,
maxMemoryMb: 512
};
Violation Detection Flow:
-
Agent Action: Codegen attempts fetch('https://api.github.com/repos/...')
-
Sandbox Intercept: WASM runtime catches syscall for network socket
-
Policy Check: netConnect: false → VIOLATION DETECTED
-
Trade-off Analysis:
Security vs Functionality Trade-offs:
├── STRICT (current): Block network, terminate agent
│ ├── Pro: Zero network attack surface
│ ├── Con: Cannot fetch external dependencies/docs
│ └── Decision: ENFORCE (security-first environment)
├── MODERATE: Allow specific whitelisted domains
│ ├── Pro: Functional for known-good APIs
│ ├── Con: DNS poisoning, subdomain takeover risks
│ └── Decision: Consider for dev environments only
└── PERMISSIVE: Log but allow
├── Pro: Full functionality preserved
├── Con: Agent can exfiltrate data, download malware
└── Decision: REJECT (violates zero-trust model)
-
Response: Terminate agent, log security event:
{
"event": "sandbox_violation",
"agent_id": "agent-codegen-001",
"violation_type": "unauthorized_network_access",
"attempted_url": "api.github.com",
"policy_matched": "netConnect: false",
"action_taken": "terminate_agent"
}
Novice miss: Would allow the network access "just this once" or not detect the violation.
Expert insight: Sandbox violations indicate potential compromise or model drift—always enforce strictly.
Quality Gates
NOT-FOR Boundaries
This skill should NOT be used for:
- Application-level vulnerability scanning → Use
security-auditor instead
- Network firewall/WAF configuration → Use
infrastructure-engineer instead
- SOC2/HIPAA compliance documentation → Use organizational compliance processes
- Prompt injection defense → Use
prompt-engineer skill instead
- Rate limiting or DDoS protection → Use API gateway configuration
- Container orchestration security → Use
devops-automator skill instead
Delegation boundaries:
- For code-level security issues →
security-auditor
- For infrastructure hardening →
infrastructure-engineer
- For secure coding practices →
software-engineer
- For incident response →
security-incident-response