When I hire new developers (different Coding Agents) , I do not assume perfect behavior. I assume velocity, curiosity, and occasional mistakes. So I designed Agent Provost around one non-negotiable product boundary:
The product is the audit log format.
If that format drifts, we lose chain-of-custody, investigations get harder, and trust disappears. Everything else is implementation detail.
In this repo, we enforce that boundary in four layers:
- Runtime contract in proxy config
The JSON schema is explicitly defined in OpenResty and includes identity and correlation fields.
See default.conf log schema, provost_request_id, provost_user, and provost_machine.
Hop-level audit routing is pinned to the Fluent Bit socket at Hop 1 access_log and Hop 2 access_log. - Unit tests that assert schema presence
If a developer removes keys or reroutes logs, tests fail.
See schema key tests, socket routing tests, and error log tag tests.
There is also a parse-level assertion at JSON line parse check. - Security/privacy tests for log safety
We do not just log more. We log safely.
See escape=json injection guard test, redaction test, and multiline JSON validity test.
The redaction function itself is in default.conf redact_sensitive. - CI gate that blocks merge on schema drift
Even if someone skips local tests, PR CI still blocks drift.
See log-schema-validation job, escape=json failure rule, and required key loop.
Deployment path also depends on this gate at build job dependencies.
This is intentional engineering culture: make the unsafe change difficult, noisy, and reviewable.
New developers can refactor internals, but they cannot accidentally “improve” away our audit integrity without tripping tests and CI alarms.
Operationally, the same philosophy continues beyond unit tests:
- End-to-end verification uses identity headers and validates audit path in verify_proxy_routing.sh request headers and audit pass check.
- Fluent Bit is configured for durable buffering and S3 sink via service storage settings, JSON parser filter, and S3 output key format.
- The product narrative is documented in README audit ledger section.
If you are hiring, this is the takeaway: do not rely on process alone. Encode product invariants as executable contracts, then make every merge prove those contracts still hold.
If you want, I can also generate a tighter “founder voice” variant and a more “CTO/auditor voice” variant of this same post so you can choose based on audience.