Per-project ACL for AI agents and receipts

Many AI governance tools have per-agent or per-user ACLs. That's too coarse — an engineer needs full access to their agent but might be working on multiple projects with different sensitivity. The atomic unit of access control should be the project, not the agent. GenZAgents lets you tag receipts with a project and ACL the project independently of the agent.

org-public: any org member can see + use in org_context_lookup. This is the default for most projects. members-only: explicitly listed members can see; org_context_lookup returns a stub ("someone in the org has done similar work — request access"). private: only the project owner sees; org_context_lookup ignores entirely.

Most projects (engineering work, customer-facing analyses, internal strategy) sit fine in org-public. Sensitive projects (executive comp analyses, M&A due diligence, security investigations) sit in members-only or private. The choice happens once at project creation; the receipts inherit the ACL.

Even compliance-audit access respects ACLs. If your SOC 2 auditor needs to review AI activity, the evidence pack includes only receipts the auditor is ACL'd to see (typically org-public + members-only with auditor as a member). private projects show as redacted entries in the pack — the auditor sees "5 receipts redacted under private ACL" so the count is honest but the content isn't exposed.

When an engineer transitions between projects, the transfer flow respects the new project's ACL: receipts from a private project don't bleed into an org-public successor project. This matters when a security investigation's receipts shouldn't be inheritable by the engineer's next assignment.

Brand-new projects default to org-public to make de-dup work out of the box. Org admins can change the default to org-private if their threat model requires explicit opt-in to org-wide visibility. The dashboard surfaces the default policy clearly so engineers don't accidentally over-share.