Ethical Walls (Information Barriers)

Ethical walls -- also called information barriers or Chinese walls -- are mandatory access restrictions that prevent users from accessing projects where a conflict of interest exists. Contract Lucidity's ethical wall system is designed for law firms and regulated enterprises that must comply with professional responsibility rules, including ABA Model Rule 1.10 (imputation of conflicts of interest).

Why Ethical Walls Exist

Law firms routinely handle matters for clients with adverse interests. When a lawyer moves between firms, or when a firm takes on a new client whose interests conflict with an existing client, the firm must erect an information barrier to ensure that conflicted personnel cannot access the other side's materials.

Common scenarios that require ethical walls:

• Lateral hire conflicts: A lawyer joins your firm from opposing counsel and must be screened from the matter they previously worked on
• Opposing counsel: Two teams at the same firm represent parties on opposite sides of a transaction or litigation
• M&A deal teams: Separate buy-side and sell-side advisory teams within the same organization must not share information
• Regulatory investigations: Personnel involved in an internal investigation must be isolated from the business unit under review

Failure to enforce these barriers can result in disqualification motions, malpractice claims, and disciplinary action.

How Ethical Walls Work

Ethical walls are evaluated before all other permission checks. When a wall exists between a user (or group) and a project, access is denied unconditionally -- regardless of any allow permissions, group memberships, or role assignments.

Permission Resolution Hierarchy

Contract Lucidity resolves permissions in a strict 6-step order. The first matching rule wins:

Step	Check	Result
1	Ethical wall deny	If the user is on a wall that covers this project, deny. No override possible (except by the seed admin).
2	User deny	If the user has an explicit deny permission on this project, deny.
3	Group deny	If any of the user's groups has a deny permission on this project, deny.
4	User allow	If the user has a direct allow grant, allow at the granted level.
5	Group allow (highest)	If any of the user's groups has an allow grant, allow at the highest level across all groups.
6	Default deny	If none of the above matched, deny.

This is a hybrid model inspired by iManage Security Policy Manager: deny permissions always override allow permissions, and among allow grants, the most permissive level wins.

Ethical walls override everything

An ethical wall deny cannot be overridden by any allow permission, admin role, or group membership. Only the seed admin account (the break-glass recovery account) bypasses ethical walls. Regular admin users are subject to walls like everyone else.

Permission Levels

Each allow grant specifies one of three permission levels:

Level	Can View	Can Upload / Edit	Can Manage Access
viewer	Yes	No	No
editor	Yes	Yes	No
admin	Yes	Yes	Yes

Deny permissions do not have a level -- a deny is absolute and blocks all access to the project.

Allow vs Deny Permissions

Allow Permissions

Allow permissions grant access at a specific level (viewer, editor, or admin). They can be assigned to individual users or groups.

When a user has multiple allow grants for the same project (e.g., a direct grant at viewer and a group grant at editor), the most permissive level wins. The user gets editor access.

Deny Permissions

Deny permissions block all access to a project, regardless of any allow grants. A single deny -- whether from an ethical wall, a direct user deny, or a group deny -- overrides all allow permissions.

Deny always wins. If a user has an allow grant at admin level and a deny through any path, the result is deny.

Managing Ethical Walls in the UI

Navigate to Settings > Security > Ethical Walls to create and manage walls.

Creating a Wall

1. Click Add Ethical Wall
2. Enter a name (e.g., "Acme v. Beta Corp Conflict")
3. Enter a description explaining the reason for the wall (this becomes part of the audit record)
4. Select the projects that the wall covers
5. Select the users and/or groups that are screened (blocked) from those projects
6. Save

Once created, the wall takes effect immediately. Any affected users who currently have the project open will be blocked on their next API request.

Editing a Wall

You can add or remove projects, users, and groups from an existing wall at any time. Changes take effect immediately.

Deactivating vs Deleting a Wall

• Deactivate: Temporarily suspends the wall. The configuration is preserved and can be reactivated later. Use this when a conflict is resolved but you want to retain the audit trail.
• Delete: Permanently removes the wall and its configuration. The audit log retains a record that the wall existed and when it was deleted.

Managing Ethical Walls from a Project Page

In addition to the centralized Settings page, admins can view and manage ethical walls directly from any project's detail page. This is useful when you are already working in a project and need to check which walls apply or quickly add a new one.

Accessing the Ethical Walls Tab

1. Navigate to the project you want to inspect.
2. Click Manage Access to open the access modal.
3. The modal contains three tabs: Users, Groups, and Ethical Walls. Select the Ethical Walls tab.

The tab label includes a count of the walls currently covering the project (e.g., "Ethical Walls (2)"), so you can see at a glance whether any barriers are in place.

Viewing Walls on a Project

The Ethical Walls tab lists every wall that includes the current project. Each wall row displays:

• The wall name and description.
• A status badge:
  • Enforced (red) -- the wall is active and currently blocking the screened users/groups.
  • Inactive (gray) -- the wall has been deactivated and is not enforcing any restrictions.

Adding a Wall to the Project

1. Use the dropdown at the top of the tab to select an existing ethical wall.
2. Click Add. The wall is applied immediately and the screened users/groups on that wall lose access to this project.

Only walls that do not already cover this project appear in the dropdown.

Removing a Wall from the Project

Click the X button next to a wall to remove this project from that wall's scope. The change takes effect immediately -- previously screened users regain access (assuming no other wall or deny permission blocks them).

warning

Removing a project from a wall does not delete the wall itself. The wall continues to apply to any other projects in its scope. If you need to delete or deactivate the wall entirely, use Settings > Security > Ethical Walls.

Admin Role and Ethical Walls

Unlike the basic project access system where admin-role users bypass access checks, admin-role users do NOT bypass ethical walls. This is by design -- an admin who has a conflict of interest must be screened just like any other user.

The only account that bypasses ethical walls is the seed admin (the break-glass account created on first boot via environment variables). The seed admin is intended solely for system recovery and should not be used for day-to-day operations.

Ethical Walls and SCIM-Provisioned Users/Groups

Ethical walls work with SCIM-provisioned users and groups the same way they work with manually created ones:

• SCIM-provisioned users can be added to an ethical wall just like local users. When the IdP pushes a new user via SCIM, the user is subject to any walls that reference their account or their groups.
• SCIM-provisioned groups can be added to a wall. Any user the IdP adds to that group will automatically be screened from the wall's projects.
• Removing a user from a SCIM group (via IdP sync) removes them from the wall's scope if the group was the only reason they were on the wall. They regain access if they have allow grants through other paths.

warning

When using SCIM-provisioned groups with ethical walls, coordinate with your IdP administrators. Adding a user to a SCIM group in the IdP will automatically screen them from any projects covered by walls that reference that group.

Conflict Resolution Examples

Example 1: Lateral Hire

A new attorney joins your firm from opposing counsel on the "Project Alpha" matter.

1. Create an ethical wall named "J. Smith - Project Alpha Conflict"
2. Add the attorney as a screened user
3. Add "Project Alpha" as a covered project

Result: The attorney cannot see or access Project Alpha, even if they are added to a group that has editor access to it.

Example 2: Opposing Counsel Teams

Your firm represents both the buyer and seller in an M&A transaction, with separate teams for each side.

1. Create an ethical wall named "Acme Acquisition - Buy Side Screen"
2. Add the buy-side team group as screened
3. Add the sell-side project as a covered project
4. Create a second wall: "Acme Acquisition - Sell Side Screen"
5. Add the sell-side team group as screened
6. Add the buy-side project as a covered project

Result: Neither team can access the other's project, even though both teams may have the same admin-role users.

Example 3: Mixed Permissions

A user has the following grants for "Project Beta":

• Direct allow grant: editor
• Group "Legal Team" allow grant: admin
• Group "Restricted" deny grant on "Project Beta"

Resolution (following the 6-step hierarchy):

1. No ethical wall -- continue
2. No user deny -- continue
3. Group deny found ("Restricted" group) -- DENY

The user cannot access Project Beta, despite having direct editor and group admin allow grants. The deny from the "Restricted" group overrides all allows.

Audit Trail

All ethical wall actions are logged with timestamps and the admin who performed them:

Event	Logged Details
Wall created	Wall name, description, covered projects, screened users/groups, creating admin
Wall modified	What changed (projects/users/groups added or removed), modifying admin
Wall deactivated	Deactivation timestamp, deactivating admin
Wall reactivated	Reactivation timestamp, reactivating admin
Wall deleted	Deletion timestamp, deleting admin
Access denied by wall	User ID, project ID, wall ID, timestamp

The "access denied by wall" events are logged whenever a user's request is blocked by an ethical wall. These logs are available through the admin API and can be exported for compliance reporting.

tip

Regularly review the ethical wall audit log as part of your firm's conflict-checking procedures. The log provides evidence of wall enforcement for regulatory compliance and court filings.

API Reference

All ethical wall endpoints require admin authentication.

Wall Management

Method	Endpoint	Description
GET	/api/admin/ethical-walls	List all ethical walls
POST	/api/admin/ethical-walls	Create a new ethical wall
GET	/api/admin/ethical-walls/active	List only active (non-deactivated) walls
GET	/api/admin/ethical-walls/:id	Get a specific wall with its projects, users, and groups
PATCH	/api/admin/ethical-walls/:id	Update a wall (name, description, active status)
DELETE	/api/admin/ethical-walls/:id	Permanently delete a wall

Wall Membership

Method	Endpoint	Description
POST	/api/admin/ethical-walls/:id/projects	Add a project to a wall
DELETE	/api/admin/ethical-walls/:id/projects/:project_id	Remove a project from a wall
POST	/api/admin/ethical-walls/:id/users	Add a user to a wall (screen them)
DELETE	/api/admin/ethical-walls/:id/users/:user_id	Remove a user from a wall
POST	/api/admin/ethical-walls/:id/groups	Add a group to a wall (screen all members)
DELETE	/api/admin/ethical-walls/:id/groups/:group_id	Remove a group from a wall

Project-Scoped Queries

Method	Endpoint	Description
GET	/api/admin/projects/:project_id/walls	List all ethical walls that cover a specific project (returns wall ID, name, description, and active status for each)

Permission Checking

Method	Endpoint	Description
GET	/api/admin/users/:user_id/effective-permissions	Get a user's effective permissions across all projects, including wall blocks
GET	/api/admin/users/:user_id/effective-permissions/:project_id	Get a user's effective permission for a specific project
GET	/api/admin/ethical-walls/check/:user_id/:project_id	Check if a specific user is blocked by a wall on a specific project

Audit Log

Method	Endpoint	Description
GET	/api/admin/ethical-walls/audit-log	List all ethical wall audit events (paginated)
GET	/api/admin/ethical-walls/:id/audit-log	List audit events for a specific wall