Chinese Wall isolation in practice.

/ 01The problem

A law firm has two practice groups, each acting for direct competitors. Both teams open the same Fieldbook-hosted CDD platform. By default, both should see no data belonging to the other group, even at the metadata level. Default access between wall groups is deny, not read-only.

Wall groups are configured at the tenant level. RLS policies are generated automatically from the wall configuration; the policies fail-closed, so a configuration mistake errs toward stricter isolation.

/ 02Wall groups

pub struct ChineseWallConfig {
    pub enabled: bool,
    pub wall_groups: Vec<WallGroup>,
    pub authorisers: Vec<String>,      // GC / HoRC emails
}

pub struct WallGroup {
    pub group_id: String,
    pub firm_name: String,
    pub firm_domain: String,            // e.g. mueller-recht.de
    pub members: Vec<String>,            // member emails
}

Membership is per-email and validated against the IdP at session start. Members of multiple groups carry the union of accesses but trigger an audit event each time they cross a wall.

/ 03Cross-wall tokens

When access across walls is genuinely needed, an authoriser (typically the General Counsel or Head of Regulatory Compliance) issues a cross-wall token.

pub struct CrossWallToken {
    pub token_id: String,
    pub requester: String,
    pub authoriser: String,
    pub wall_groups_accessed: Vec<String>,
    pub granted_at: String,
    pub expires_at: String,
    pub revoked: bool,
    pub signature: String,             // HMAC-SHA256
}

The token is validated on every request that would otherwise be denied. Expiry is hard — no grace period. Revocation is immediate and recorded.

/ 04RLS policy generation

From a ChineseWallConfig the engine generates one or more RowPolicy entries per protected table. The generated policies are visible (and editable, with audit) in the RLS editor — see Row-Level Security policy editor.

pub fn generate_wall_policies(
    config: &ChineseWallConfig,
    table_ids: &[String],
) -> Vec<RowPolicy>

The generated policies are fail-closed: predicate evaluation errors exclude the row rather than include it. There is no implicit "if in doubt, show" behaviour anywhere in the wall stack.

/ 05Worked example: M&A team isolation

Two practice groups — "Project Helios" for Acme PLC, "Project Aurora" for Beta Holdings — work on competing acquisitions of the same target.

1. Configure walls

   Define two WallGroup entries, one per project. Members are the partners, associates, and trainees on each side.

2. Tag content

   Each CDD passport, document, and finding carries a wall_group_id field at ingest. The RLS generator uses this to scope visibility.

3. Auto-generate policies

   Run fieldbook walls apply. Policies are added to every protected table; existing rows tagged retroactively.

4. Cross-wall exception

   If a senior partner needs portfolio-level visibility across both, the firm’s GC issues a 24-hour CrossWallToken covering both groups. The access is timestamped, audited, and visible to both teams’ compliance officers.

/ 06Audit trail

Every wall event lands in the audit log with full context:

• RlsFilterApplied — a query was scoped by wall policies; row count returned vs. denied
• RlsAccessDenied — a specific access was blocked; resource and policy logged
• CrossWallTokenIssued — token created with authoriser identity
• CrossWallTokenUsed — token redeemed; per-request usage logged
• CrossWallTokenRevoked — token revoked; subsequent uses fail

The audit log is hash-chained (see audit.json). Wall events cannot be silently removed without breaking the chain.