Security & enterprise-readiness follow-ups (tracking)

[sathish-mg]

Summary

Tracking issue for a holistic security / enterprise-readiness review of Areev, done conversationally and grounded directly against the code (not just the docs). Filed as individual issues so each can be picked up, scoped, and closed independently; this issue exists to keep them visible as a set.

Two framings drove the review:

1. Is the current security posture actually what the docs claim, and where does it fall short of an enterprise/procurement bar? (docs/security-model.md, docs/procurement.md, docs/deployment-profile.md were the starting points.)
2. Given ISO 27001 / SOC 2 certification is explicitly not planned right now (this is an open-source project and certification is expensive, and certifications attach to a hosted offering that doesn't exist yet — docs/procurement.md already states this correctly) — what can still be done to make that easier later, for free, today?

What's already solid (confirmed against code, not just docs)

Worth stating so this tracking issue isn't read as "everything is broken": docs/procurement.md's checklist holds up well under direct verification — RBAC-as-grains (mg:permits Facts), separation of duties (approver ≠ triggering principal, structurally enforced), a measured (not claimed) sub-5-minute kill switch, encryption at rest, retention floors + legal holds, DSAR (FORGET SUBJECT/REPORT SUBJECT sharing one selector), Rule E1 change-control on agent self-modification, and cargo-deny-based dependency hygiene are all real and tested. Native TLS (areev ui --tls-cert/--tls-key) and SSO v0 (--sso-header/--sso-secret-env) also turned out to be already-shipped, not aspirational — the docs just hadn't caught up (issue #76).

The follow-up issues

#	Issue	Why
#76	docs: security-model.md and CLAUDE.md understate shipped TLS + describe Postgres writer model incorrectly	Cheapest, highest-priority fix — a security doc that undersells what's shipped is its own procurement risk.
#77	security: decide the path for grain authenticity (COSE signing) before building on the dormant scaffolding	The one item that's a genuine unmitigated gap ("only sync with peers you trust" is currently load-bearing) rather than a documented trade-off — but the repo itself says not to naively build it (undesigned trust model, unfinalized OMS spec, new core dependency). Needs a deliberate decision, not a quick patch.
#78	security: extend native TLS (--tls-cert/--tls-key) to areev hub	ui has native TLS; hub — the surface specifically designed for other machines to write to — is still proxy-only.
#79	security: operationalize --sso-secret-env rotation (runbook + evaluate dual-secret grace window)	The SSO shared secret is documented as "impersonation-grade" but has no tested rotation procedure and no code support for a graceful rotation window.
#80	security: enable branch protection on main	main currently has zero branch protection — CODEOWNERS is advisory only. Free, high-leverage, and table-stakes for any future change-management audit.
#81	security: publish SBOMs and release-artifact provenance/signing	No SBOM and no build provenance/signing across the three release pipelines (crates.io, npm, PyPI) today. Native GitHub Attestations make this cheap.
#82	security: schedule an independent third-party penetration test	Bonus item, not part of the original four — docs/procurement.md currently answers "operator's scope," which is honest but won't satisfy a buyer asking to see a report.

Ordering above is by rough priority (cheap-and-immediate → real design work → operational hardening → free future-proofing → bonus), not by issue number.

Explicitly out of scope for now

• SOC 2 / ISO 27001 certification itself — not planned; too expensive for an open-source project at this stage, and certifications properly attach to a future hosted offering, not the self-hosted library. security: enable branch protection on main #80, security: publish SBOMs and release-artifact provenance/signing #81 and (partially) security: decide the path for grain authenticity (COSE signing) before building on the dormant scaffolding #77 are the "make it cheaper to get there later" investments instead.
• Native OIDC / SCIM — SSO v0 (trusted-header) is judged sufficient for now; native OIDC is a documented future follow-on in docs/deployment-profile.md, not actioned here.

Context

This review started from a question about RBAC/credential-passthrough design for agent tool calls (the credential broker in areev-run), widened into "what happens if the hosting box itself is compromised," then into a full holistic pass comparing Areev's posture against a competing framework (Hermes/NousResearch) and the existing internal enterprise-readiness docs. No production incident prompted this — it's a proactive audit.