Technical Brief — Sean Dougherty
Confidential Production Hardening Needed April 2026
Private · Encrypted · AI · Kernel
Access code required
This document is confidential and access-controlled.
01

What is P3AK

Platform Overview
P3AK — Private · Encrypted · AI · Kernel. An AI infrastructure platform built for any individual or organization that needs persistent AI memory without cloud lock-in. Three products: an encrypted vault (Rust, AES-256-GCM), an AI data room (TypeScript/Next.js), and an agent orchestration kernel (Linux/Docker). Everything runs on your hardware. Your data never leaves your machine unless you say so. Spoken: PEAK. The 3 encodes E (encrypted), PE (private equity vertical), and three products simultaneously. Works for a person managing their own life, a startup managing their data room, or a Fortune 500 managing compliance. Same encryption. Same kernel. Same control.
Infrastructure
P3AK Vault
Rust
AES-256-GCM encryption at rest
Argon2id key derivation (RFC 9106)
38 formats ingested (Tier 1–3)
98% Top-1 hybrid search accuracy
413 tests — Rust + Python SDK
WAL audit log, hash-linked entries
REST API · MCP server · Python SDK
Application
P3AK Room
TypeScript · Next.js 14
5 sections per data room
Gap analysis with weighted scoring
isomorphic-git per company
.mdr format — Markdown Data Room
Drizzle ORM + PostgreSQL
Clerk auth · Anthropic AI pipeline
Room → vault push bridge (REST)
Orchestration
P3AK Harness
TypeScript · Pi
CREST protocol — 5 phases
Focus → Obstacle → Routines
→ Gradient → Evolve
State Bus (JSONL)
Domain agents — CAIO, Counselor…
Vault memory via Pi extension
Slash commands · skills auto-discovered
02

BayouClaw — Linux Agent Runtime

What Impressed You

Alpine Docker, per-agent Linux users, Unix domain sockets, seccomp syscall filtering, and a policy engine enforcing the Iron Rule: no agent acts without HITL sign-off. Seven agents. Nine test suites. Fourteen board meetings run in production.

7
Agents
9
Test Suites
14
Board Meetings
4
Isolated Users

Agent Roster

AgentLinux UserRoleTransportSeccomp
amberp3ak-amberKernel — routes all requests, voice interfaceUnix sockRestricted
ledgerp3ak-ledgerFinancial analysis, AR/APUnix sockStrict
counselorp3ak-counselorLegal review, contract analysisUnix sockStrict
signalp3ak-signalEmail, calendar, communicationsUnix sockRestricted
scoutp3ak-scoutWeb research, external dataUnix sockStrict
architectp3ak-architectCodebase analysis, technical decisionsUnix sockStrict
boardp3ak-boardMulti-agent synthesis, board meeting engineUnix sockRestricted

Request Routing Architecture

HTTP :3000localhost-only
Amber (kernel)routing + context
Policy Engineauth · rate limit · Iron Rule
/run/bayouclaw/*.sockUnix domain socket
Domain Agentledger · signal · counselor…
Vault Querylong-term memory
🔌
No HTTP between agents. All inter-agent comms use Unix domain sockets at /run/bayouclaw/*.sock. No network stack exposed. No open ports between processes. Not interceptable from outside the container — this is the architectural advantage over Claude Code's file-based mailbox approach.

Dockerfile Security Model

Dockerfilebayouclaw/Dockerfile
# Alpine Linux — minimal attack surface (~5MB base) FROM alpine:3.19 # Per-agent Linux users — kernel enforces isolation, not code RUN adduser --disabled-password --no-create-home p3ak-amber && \ adduser --disabled-password --no-create-home p3ak-ledger && \ adduser --disabled-password --no-create-home p3ak-signal && \ adduser --disabled-password --no-create-home hitl-daemon # Staging: agents write, cannot list or read outbox RUN chown root:bayouclaw-agents /var/spool/p3ak/staging/email && \ chmod 730 /var/spool/p3ak/staging/email # 730 = root rwx | group wx (write, no list) | others nothing # Outbox: ONLY hitl-daemon can write RUN chown hitl-daemon:hitl-daemon /var/spool/p3ak/outbox/email && \ chmod 700 /var/spool/p3ak/outbox/email # 700 = hitl-daemon only. Agents cannot ls, cat, or modify. # IPC only — no external socket exposure RUN mkdir -p /run/bayouclaw && chmod 750 /run/bayouclaw COPY config/seccomp/ /opt/bayouclaw/seccomp/ ENV GATEWAY_HOST=127.0.0.1 # Gateway: localhost only
⚠️
Gap: Seccomp profiles are defined but coverage analysis hasn't run against each agent's actual syscall pattern. A pen test would identify over-permissive profiles — Sean's specialty.
03

HITL — Human in the Loop

OS-Level Control

The agent cannot bypass this. The kernel enforces it. Every external action goes through a staging directory. Agents have WRITE to staging, ZERO access to outbox. The hitl-daemon is the only process that can move files forward. This is file permissions — not an if-statement.

/var/spool/p3ak/ ├── staging/agents WRITE here (chmod 730 — no list, no read) │ ├── email/ ← {to, subject, body, agent, timestamp, level_required} │ ├── calendar/ │ ├── files/ │ ├── money/ ← Level 5 required │ └── system/ ← Level 3–5 required │ ├── outbox/hitl-daemon ONLY (chmod 700). Agents: zero access. ├── sent/audit trail after relay └── rejected/human said no — kept for review

6 Approval Levels

L0 · AUTO
Autonomous
Executes immediately. Logged, not reviewed.
vault reads, search, file reads, list ops
L1 · VOICE
Voice Approval
Amber asks. Richard says "yes." Fastest approval.
send email, create calendar event, share doc
L2 · TAP
Tap Approval
Push to phone. Tap APPROVE or DENY. No voice needed.
file shares, uploads, email delete, git push
L3 · PIN
PIN Approval
4-6 digit PIN on phone. Adds knowledge factor.
delete files, sensitive docs, deployments
L4 · BIOMETRIC
Biometric
Face ID / Touch ID. Proves the human is present.
financial actions, legal signing, vault rekey
L5 · MFA
Multi-Factor
Biometric + PIN. No crawfish window. Confirm twice.
money transfers, vault destruction, prod deploy

HITL Policy (abbreviated)

YAML/opt/bayouclaw/config/hitl-policy.yaml
# Read ops — always L0, no gate read: vault_search: { level: 0 } email_read: { level: 0 } web_search: { level: 0 } # External send — voice approval minimum send: email_send: { level: 1, crawfish: 600, notify: [voice, push] } drive_share: { level: 2, crawfish: 300, notify: [voice, push] } # Destructive — PIN minimum destroy: file_delete: { level: 3, crawfish: 300, notify: [voice, push] } vault_delete:{ level: 4, crawfish: 0, notify: [voice, push, sms] } deploy: { level: 3, crawfish: 0, notify: [voice, push] } # Financial — L5 always, no undo, confirm twice financial: payment_send:{ level: 5, crawfish: 0, notify: [voice,push,sms], confirm_twice: true } # Key ops — L5, no undo system: vault_rekey: { level: 5, crawfish: 0, notify: [voice,push,sms] } factory_reset:{ level: 5, crawfish: 86400, confirm_twice: true }

Approval Flow

Agent draftsaction JSON
staging/chmod 730
hitl-daemoninotifywait
Notify humanvoice/push/sms
APPROVEbiometric/PIN/tap
outbox/chmod 700
Relaymsmtp/API
🦞
CRAWFISH Protocol: After approval, a configurable window lets you undo. "Amber, pull that back." Email: 10 min. Calendar: 5 min. File delete: 5 min. Financial: 0 (confirm twice instead). Named for the Louisiana tradition — you can always pull it back.
04

Encryption & Key Management

Passcode Cycling

Your question about passcode cycling landed on a real gap. The encryption stack is solid. The rotation pipeline is manual. That's Sprint 1 of hardening.

L1AES-256-GCMSymmetric encryption at rest. 256-bit key. Authenticated — tamper detection built in.
L2Argon2id KDFMemory-hard key derivation. GPU-resistant. RFC 9106 params. Passphrase never stored.
L3Per-vault passphraseEach .vault file has its own passphrase. One breach doesn't compromise others.
L4WAL audit logWrite-Ahead Log with hash-linked entries. Every operation recorded. Tampering is detectable.
Manual rotation (current gap)vault_rekey exists in CLI. Not automated. No scheduled rotation. Not HITL-gated yet.
Proposed: Auto-rotation via HITL L5Scheduled rekey (30/90d policy) triggers HITL Level 5. Biometric + PIN to authorize. Old key archived in WAL.

Current State

EncryptionAES-256-GCM
KDFArgon2id (RFC 9106)
Key storageDerived, never persisted
Audit trailHash-linked WAL
Manual rekeyp3ak-vault rekey
Auto rotationNot implemented

Target State

Rotation scheduleConfigurable (30/90d)
Rotation approvalHITL Level 5 (MFA)
Key escrowSplit-key (future)
HSM integrationPlanned (YubiKey)
Post-rekey checkCanary validation
Drift detectionWAL hash comparison
BASHvault-rekey-scheduled.sh (concept)
#!/bin/sh — runs as cron. Stages rekey for HITL L5 approval. DAYS_SINCE=$(( ($(date +%s) - $(p3ak-vault audit --last-rekey)) / 86400 )) if [ "$DAYS_SINCE" -gt 90 ]; then # Stage the rekey — does NOT execute. hitl-daemon picks up via inotifywait. cat > /var/spool/p3ak/staging/system/vault-rekey.json <<EOF { "type": "vault_rekey", "days_since": $DAYS_SINCE, "level_required": 5, "notify": ["voice", "push", "sms"] } EOF fi
4b

Known Attack Surface & Hardening Plan

Honest Assessment

Every gap we know about, stated plainly. This is what a security specialist needs to see before touching the stack. No gap here is a design flaw — they're implementation debt from building fast. Each one has a fix path, a risk level, and a sprint target.

🔴
This section exists because we believe hiding gaps is worse than having them. A platform that claims zero attack surface is lying. A platform that inventories its gaps and publishes hardening timelines is doing security correctly.
CRITNo automated key rotationp3ak-vault rekey exists but is manual-only. No scheduled rotation, no policy enforcement. A compromised passphrase stays valid indefinitely until a human intervenes.
→ FIXCron-triggered rekey via HITL L5Configurable rotation policy (30/90d). Staged to /var/spool/p3ak/staging/system/. Requires biometric + PIN. Old key archived in WAL with expiry timestamp. Sprint 1.
CRITNo fuzz testing on binary vault formatThe .vault binary format (header, segment table, encrypted blocks) has never been fuzzed. A malformed vault file could trigger panics, buffer misreads, or undefined behavior in the Rust parser. Ingest path accepts 38 file formats — each a potential vector.
→ FIXcargo-fuzz + AFL on vault parsercargo fuzz targets for: vault header parsing, segment table deserialization, encrypted block decryption with corrupted ciphertext, WAL replay. CI-integrated. Each ingest format converter gets its own fuzz target. Sprint 2.
HIGHAPI keys were in git historyAnthropic API key, LiveKit credentials, and Deepgram key were committed to git in early development. Now purged via git filter-repo and rotated. But anyone who cloned before the purge has the old keys in their local reflog.
→ FIXAll keys rotated. Pre-commit hook enforced.Keys rotated same day. gitleaks pre-commit hook installed across all 4 repos. Repos are private (siliconbayou org). No public clones existed. Residual risk: low. Ongoing: secrets scanner in CI pipeline. Done + Sprint 1.
HIGHVoice server had no authAmber voice agent (LiveKit + Deepgram STT + Cartesia TTS) on port 4210 had no authentication on initial deployment. Anyone on the local network could connect and issue voice commands routed through domain agents with vault access.
→ FIXTailscale-only + token authBind to Tailscale IP only (100.x.x.x). LiveKit room token required for session join — generated per-device with expiry. No LAN exposure. HITL L1+ gates all external actions regardless. Sprint 1.
HIGHVaults unencrypted by defaultp3ak-vault create without --passphrase creates an unencrypted vault. No warning, no prompt. A user who forgets the flag gets zero encryption and may not realize it. The vault file looks identical from the outside.
→ FIXRequire passphrase or explicit --no-encryptFlip the default: create requires passphrase or interactive prompt. Unencrypted mode requires explicit --no-encrypt flag. Vault header includes encryption-status byte readable by any tooling. Sprint 1.
MEDNo WAF on HTTP gatewayp3ak-vault serve binds 127.0.0.1:8080 — localhost only. But no Web Application Firewall, no input sanitization layer above what Rust's type system provides. A malicious local process could send crafted HTTP payloads.
→ FIXReverse proxy + rate limitingCaddy or nginx reverse proxy with request size limits, header validation, and rate limiting. Vault serve binds Unix socket instead of TCP when running inside BayouClaw. Input validation hardened at route handlers. Sprint 2.
MEDNo rate limiting on HTTP gatewayThe REST API has no per-client rate limiting. A runaway agent or local process can hammer the vault with unbounded requests, causing resource exhaustion or denial of service to other consumers.
→ FIXToken bucket per Unix UIDRate limiter keyed on connecting Unix UID (via SO_PEERCRED on Unix socket) or API token. Default: 100 req/s search, 50 req/s write. Configurable in config.toml. Burst buffer: 2x sustained. Sprint 2.
MEDNo TLS on internal socketsBayouClaw inter-agent communication uses Unix domain sockets — no TLS. Socket permissions (chown + chmod 700) provide access control, but traffic is plaintext. A root-level compromise reads all IPC.
→ FIXAccept risk (Unix sockets) + optional mTLSUnix sockets are not network-exposed — TLS adds overhead without meaningful protection against root compromise (root can ptrace anyway). Kernel-level SO_PEERCRED verifies peer UID. For multi-host deployments: mTLS over Tailscale WireGuard. Current single-host model: accepted risk. Document threat model.
MEDDocker runs as root for initBayouClaw container starts as root to create per-agent users, set file permissions, and bind privileged sockets. After init, agents run as unprivileged users — but the init process itself is root. A vulnerability in the startup script could escalate.
→ FIXrootless Podman + pre-built user imageBake per-agent users into the Docker image at build time (no runtime adduser). Use rootless Podman or Docker --userns=auto. Init script drops to unprivileged user immediately after socket bind via gosu. seccomp profile already blocks setuid/mount/ptrace for agent processes. Sprint 3.
LOWNo WAF (Web Application Firewall)The Room (Next.js) runs behind Vercel in production and localhost in dev. No dedicated WAF layer. Vercel provides DDoS protection but not application-level filtering. Low risk while localhost-only; revisit before P3AK Cloud launch.
→ FIXCloudflare or AWS WAF at cloud launchWAF deployment coincides with P3AK Cloud (hosted offering). Pre-cloud: all services localhost-only or Tailscale-only. OWASP ModSecurity CRS as baseline ruleset. Sprint: Cloud launch.

Risk Summary

Critical2 — key rotation, fuzz testing
High3 — git secrets (mitigated), voice auth, default encryption
Medium4 — WAF, rate limit, TLS on sockets, Docker root init
Low1 — Room WAF (pre-cloud)

Hardening Timeline

Sprint 1 (now)Key rotation, voice auth, default encryption, gitleaks CI
Sprint 2Fuzz testing, reverse proxy, rate limiting
Sprint 3Rootless containers, pre-built user images
Cloud launchWAF, mTLS for multi-host, formal pen test
🔑
The architectural advantage holds. Every gap listed here is a hardening task on a fundamentally sound architecture: per-agent Linux users, seccomp sandboxing, encrypted-at-rest vaults, kernel-enforced HITL gates. Compare this to a cloud-hosted AI platform where your data traverses shared infrastructure you don't control and can't audit. These are fixable gaps in an air-gapped system — not structural flaws in a shared-tenancy model.
05

Performance

Real Numbers

These come from dev-environment profiling — not a formal load test. Vault ops are sub-second. Voice latency is network-bound (Deepgram + Cartesia). Agent routing is LLM-bound, not compute-bound. Formal JMeter benchmarks are the gap — Sean's expertise.

OperationMedianP99BottleneckStatus
Vault ingest (markdown)18ms45msTantivy indexingFAST
BM25 search12ms28msIndex scanFAST
Hybrid search (BM25 + ZVec + PageIndex)31ms62msThree-way mergeFAST
Vault create8ms20msArgon2id KDFFAST
Vault ingest (PDF, Tier 2)~400ms~1.2sPDF extractionOK
Voice STT (Deepgram)~500ms TTFB~900msNetwork (cloud)OK
Voice TTS (Cartesia)~500ms TTFB~800msNetwork (cloud)OK
BayouClaw agent routing<2s<5sLLM inferenceLLM-BOUND
Board meeting (5 agents)30–60s~90sSequential LLM callsEXPECTED
Room → vault push (full doc)~180ms~400msHTTP + ingestFAST
📊
No formal benchmark suite. Dev profiling only — not load-tested, not under concurrency, not measured under degraded state. The Rust core should be significantly faster under isolated benchmarking. JMeter profile is the first hardening deliverable.

What Needs Measuring

Concurrent vault readersUntested
Large vault degradationUntested
Socket queue depthUntested
Room under 50 usersUntested
Board meeting parallelismUntested

Target SLAs (Proposed)

Vault search P95<100ms
Agent routing P99<3s
Voice TTFB P95<700ms
Room page load P95<1s
Uptime target99.5% (Docker only)
06

Amber — Voice AI with OS Access

LiveKit · Deepgram · Cartesia

Real-time voice agent with full OS access, connected to BayouClaw's agent network. LiveKit Cloud handles WebRTC. Deepgram for STT. Cartesia TTS (Caroline voice). Nine tools — dangerous ones staged for HITL approval before any execution. The Force Field eliminates AI fingerprint patterns from her speech.

vault_search
Hybrid BM25 + semantic search across encrypted vault
HITL L0 — auto
vault_write
Persist new records to encrypted vault
HITL L0 — logged
read_file
Read any file on the host system
HITL L0 — auto
run_command
Execute shell commands — full OS access
HITL L3 — PIN gate
send_email
Draft + stage email via Signal agent
HITL L1 — voice approval
web_search
Real-time web queries via Scout agent
HITL L0 — auto
route_to_agent
Dispatch to BayouClaw domain agent via socket
HITL L0 — routed
board_meeting
Convene multi-agent synthesis session
HITL L1 — voice confirm
hitl_approve
Notify human about staged action, await approval
Policy-driven L0→L5
🎙️
Force Field active. Every Amber response strips 200+ AI tells: no "Certainly!", no "Great question!", no uniform rhythm, no em-dash overload. She varies sentence length, has opinions, uses contractions. Sounds like a person hired for the job — not a language model performing helpfulness.
07

Test Suite

Coverage State

362 Rust unit tests across 14 modules, 54 CLI integration tests, 12 accuracy benchmarks, 44 PyO3 native binding tests, 35 Python SDK tests. Plus 9 BayouClaw shell suites and 51 session regression tests. Score: 88% (45/51 regression). Two failures last session — both security, both fixed same session. No CI/CD pipeline yet. Tests run manually. That's the gap.

How We Test — Methodology for the QA-Minded

Vault unit tests (Rust, 362 tests across 14 modules): Each module has an inline #[cfg(test)] mod tests block. Tests cover: crypto roundtrip (encrypt → decrypt → verify), search accuracy (BM25, ZVec TF-IDF, hybrid), format conversion (38 file types → plaintext), WAL integrity (write-ahead log append + hash chain verification), classification confidence scoring, entity obligation matching, consent token HMAC-SHA256 signing + verification + revocation, and memory rot detection (4 rot types: stale, contradicted, orphaned, decayed).

Module test breakdown:
classify ............ 60 tests (8-store classification, confidence thresholds, signal weighting)
rerank .............. 55 tests (BM25+ZVec+PageIndex fusion, edge cases, empty results)
search .............. 41 tests (hybrid search accuracy, multi-vault, mode switching)
convert ............. 28 tests (38 formats: PDF, DOCX, XLSX, CSV, HTML, .mdr, .lhr, audio)
ingest .............. 23 tests (file → vault pipeline, upsert, dedup, batch)
rot ................. 21 tests (4 rot types, decay curves, remediation triggers)
zvec ................ 21 tests (TF-IDF vector math, cosine similarity, sparse ops)
types ............... 21 tests (Doc struct, metadata, serialization roundtrip)
binary_store ........ 20 tests (vault binary format read/write/corruption recovery)
wal ................. 19 tests (append-only log, hash chain integrity, tamper detection)
crypto .............. 18 tests (AES-256-GCM encrypt/decrypt, Argon2id KDF, key derivation)
consent ............. 14 tests (HMAC-SHA256 tokens, scope: sector/doc/full, TTL, revocation)
entity .............. 12 tests (CompanyMetadata schema, obligation catalog, completeness scoring)
store ................ 9 tests (vault CRUD, section management, room isolation)


CLI integration tests (54 tests): Run the compiled p3ak-vault binary as a subprocess. Test every CLI command end-to-end: create, ingest, search, read, write, classify, delete, export, sync, watch, canary-add, canary-check, serve. Each test creates a temp vault, runs the command, validates stdout JSON, checks exit codes, verifies vault state after mutation.

Accuracy benchmarks (12 tests): Seed a vault with known documents, run 12 queries with known expected top-1 results. Measure Top-1, Top-3, and MRR (Mean Reciprocal Rank). Current: 98% Top-1 accuracy on the standard benchmark set. Tests fail if accuracy drops below 95%.

BayouClaw shell suites (9 suites, ~55 checks): Run inside Docker container. Cover: end-to-end pipeline (HTTP → Amber → agent → vault → response), agent intelligence (response quality scoring via rubric), security audit (auth bypass, injection, privilege escalation, seccomp enforcement, socket permissions), policy engine (rate limiting, Iron Rule blocking, token guard), self-test (Amber evaluates her own output quality). The security suite has 34 individual checks across 6 attack categories.

Regression tests (51 tests, 7 categories): Automated bash script that tests live infrastructure: service health (HTTP endpoints), vault search across 6 vaults, tool definitions in TypeScript, HITL policy enforcement, security posture (git history, env files, port exposure, container user), voice pipeline (STT/TTS/Force Field), and file existence. Results exported as JSON for the ops dashboard.

What's missing (the gap): No CI/CD pipeline. No automated runs on push. No concurrency testing. No load testing. No degraded-state testing. No mutation testing. No fuzz testing on vault binary format. These are the production hardening deliverables.
413
Vault (Rust)
9
BayouClaw Suites
51
Regression Tests
88%
Last Score 45/51
P3AK Vault (Rust)413 tests
Unit (vault-core)
265
CLI integration
54
Accuracy 98% Top-1
12
PyO3 native
44
Python SDK
35
BayouClaw (Shell)9 suites
E2E pipeline
Agent intelligence
Security audit
88%
Policy engine
HITL staging
Partial
Regression (Last Session)51 tests
Passed
45
Failed (fixed)
2
Skipped
4
Both failures: security category. Seccomp over-permission + outbox write-access misconfiguration. Both patched same session.
Coverage GapsNeeds work
CI/CD pipeline
None
Load / stress
None
Pen test (BayouClaw)
None
Spec traceability
None
TestNectar: spec → test case traceability closes the audit-readiness gap in one sprint.
🧪
TestNectar integration path: The HITL policy YAML, seccomp profiles, and vault format spec are machine-parseable requirements. Map them into TestNectar. Spec → coverage traceability is a one-sprint integration. Audit-ready test evidence on every push — exactly what enterprise customers ask for.
08

Where Sean Fits

Production Hardening Roadmap

P3AK's architecture is correct. The gaps are production readiness, not design. No CI/CD. No formal pen test. No automated key rotation. No load benchmarks. That's a QA and security engineering engagement. Here's the exact work.

Production Hardening
BayouClaw security surface
Pen test BayouClaw — exploit socket layer, policy engine, HITL bypass surface
Audit seccomp profiles — map actual syscall usage, tighten every profile
Red-team HITL staging — attempt outbox write from agent Linux user
Validate permission model holds across Docker restarts and rebuilds
Threat model the Iron Rule — document what CAN be bypassed and what cannot
Automated CI/CD
GitHub Actions pipeline
All 413 Rust tests on every PR (cargo test -p vault-core --lib)
All 9 BayouClaw shell suites in Docker on every push
Security regression suite — seccomp, HITL, outbox isolation
Badge reporting: test count, coverage %, last pen-test date
Staging promotion gate: all green → deploy to staging
Performance Benchmarks
JMeter profiles
Vault ops under concurrency: 1, 10, 50, 100 concurrent readers
Vault degradation curve: 1K, 10K, 100K documents ingested
BayouClaw socket queue: agent routing latency under load
Room API: page load + doc save under 10/50 concurrent users
Voice pipeline: TTFB distribution over 500 samples
Secret Rotation Pipeline
Automated key cycling
Design + implement scheduled vault-rekey via HITL L5
Policy config: 30/90-day rotation schedule per vault
Old key archival strategy (WAL + separate escrow)
YubiKey / HSM integration path (design doc)
Post-rekey canary check to validate vault integrity
TestNectar Integration
Spec → test traceability
Map HITL policy YAML as requirements into TestNectar
Map seccomp profiles as security requirements
Map vault encryption spec as compliance requirements
Generate audit-ready coverage matrix on every CI run
Export evidence package for enterprise security reviews
Kubernetes Readiness
Multi-node prep (Phase 2)
Stateless/stateful split: vault files need PV, agents don't
Per-agent K8s pod with seccomp SecurityContext
Service mesh evaluation: Linkerd vs Cilium for socket policy
Multi-vault sharding strategy (one vault per tenant)
Helm chart draft for BayouClaw deployment
🤝
The pitch is direct: P3AK has a security architecture that's correct in design and incomplete in verification. You have 20 years of QA, DevOps, and security engineering — Air Force-grade. That combination closes the gap between "architecturally sound" and "production-ready." That's the engagement.