Deploying Claude Across a 140-Attorney Litigation Firm

Summary

Brennan & Hartwell LLP is a 140-attorney litigation firm running five practice groups under an ethical-wall regime, with HubSpot as its client and matter system of record. This document sets out the architecture for deploying Claude across it: an organizational account with single sign-on, one workspace per practice group so the conflict boundary is enforced by the platform rather than by instruction, a HubSpot MCP connection scoped to read contacts and matters and to write only named matter properties, and four skills built against the highest-volume repeated tasks.

It is written as a reference rather than a report of results. Each decision is stated with the reasoning behind it, the verification that proves it holds, and the way it fails when it is skipped.

Definitions

Organizational account. A Claude plan administered centrally, where an owner controls membership, workspaces, retention settings and connectors rather than each user self-serving. See Anthropic's enterprise administration documentation.

Workspace. A membership and content boundary inside the organization. Two workspaces do not share conversations, projects or knowledge sources, which is what makes one a usable enforcement point for an ethical wall.

Ethical wall. A screen a firm is professionally obliged to maintain between matters that conflict — for example, where one group acts for a party another group opposes. Breaching it is a professional-conduct problem, not only a data-security one.

MCP (Model Context Protocol). An open protocol for connecting a model to external tools and data through a server that declares what it exposes. See the protocol introduction and HubSpot's MCP server.

Skill. A packaged set of instructions and resources that loads when a task matches it, so a repeated workflow runs the same way each time. See the Agent Skills overview.

The problem: shadow usage under a conflict regime

A litigation firm with several practice groups has a constraint most companies do not: some of its own people must not see some of its own files. That obligation is usually enforced through document-management permissions. It may stop being enforced the moment an attorney pastes a deposition excerpt into a consumer AI account, because the paste leaves the system where the wall is configured.

The mechanism matters more than the risk statement. Davis (1989) tested what predicts whether people adopt a system and found that how useful they believe it to be dominates how easy they believe it is to operate — users forgive friction in a tool that visibly helps them, and do not forgive a tool that costs them time without returning any. An attorney under deadline reaches for the fastest tool. If the sanctioned tool requires opening a different application, re-authenticating and re-uploading a document, while the unsanctioned one is a browser tab already logged in, the unsanctioned one wins — and it keeps winning after the policy email. A rollout that does not close that speed gap tends to produce a compliance artifact rather than a change in behaviour. Speier and Venkatesh (2002) followed two sales-force automation deployments and found favourable reactions immediately after training giving way to widespread rejection within six months, without anyone escalating. Abandonment of a sanctioned tool is quiet, and the deploying organisation is usually the last to see it.

The design goal is therefore not to give everyone access. It is to make the compliant path the fastest path for the tasks people actually do, and to make the wall hold at the platform level rather than by instruction.

The architecture

Practice-group workspaces, the organizational account, the scoped HubSpot MCP connection, and four custom skills

Organizational account configuration

Five settings carry the security posture. Each is configured once, at the organization level, before anyone is invited.

Single sign-on. Claude authenticates against the firm's existing identity provider, so account lifecycle follows the HR event rather than a separate administrative task. The failure this prevents is specific: an associate leaves, their firm credentials are disabled, and a directly-provisioned AI account nobody remembers keeps working.
A workspace per practice group. Litigation, Corporate, Employment, IP and Real Estate each get their own, putting the ethical wall at the platform boundary instead of relying on attorneys to remember which matters they may discuss.
Retention configured and documented. Commercial usage is not used to train models; the retention posture is set deliberately and written down for the general counsel with a date rather than described from memory. Read the current terms at Anthropic's data-retention policy and the Trust Center, then re-verify at renewal. A policy documented once and never rechecked can become a stale assertion to a client.
Role-scoped defaults. Partners, associates, paralegals and operations staff get different default permissions and skill visibility, so the interface each role opens is the one relevant to them.
Usage analytics scoped to compliance. The compliance team sees adoption and activity without reading matter content. That distinction matters: oversight requiring someone to read the work product is not oversight a firm can offer its clients.

The HubSpot MCP connection and its scope

The firm runs HubSpot as its client and matter system of record. Connecting it through MCP lets an attorney ask for a matter status and get an answer from the record, rather than switching applications and reading it manually.

Scope is where this goes wrong. Saltzer and Schroeder (1975) set out the design principles for protecting information in computer systems, and two of them govern this decision. Least privilege holds that every program and user should operate with the narrowest set of privileges the task requires, so that damage from an error or a compromise is bounded by what was granted. Fail-safe defaults holds that access should be denied unless explicitly permitted, because a mistake then withholds access rather than granting it. A HubSpot private app issues a token carrying whatever scopes were ticked at creation, and the ticking is done once by whoever set it up. Granting crm.objects.contacts.write because a workflow needed to update one property grants write access to every contact property in the portal. The token does not narrow itself later.

The connection is scoped to read contacts, read matters, and write only the specific matter properties the workflow updates, with no access to billing objects. The verification is an attempted write that should fail: if a request against a billing object returns anything other than a 403, the scope is wider than intended.

Custom skills and their constraints

Generic chat tends not to change behaviour, because a blank prompt box asks the user to do the hard part. Four skills cover the highest-volume repeated tasks, and each is constrained against the specific way it could produce confident nonsense.

The constraints exist because of how people review automated output rather than because the model is unreliable. Parasuraman and Riley (1997) distinguished use, misuse, disuse and abuse of automation, and showed that misuse — over-reliance on an automated aid — follows from trust that is not calibrated to the aid's actual reliability. Skitka, Mosier, and Burdick (1999) measured the effect directly: people working with an automated aid made errors of omission, missing events the aid did not flag, and errors of commission, following the aid's recommendation against contrary evidence in front of them. A deposition digest whose assertions carry no page-and-line citation invites exactly that second error, which is why each one does.

Matter Intake Summarizer. Turns raw intake notes and email threads into a structured matter brief — parties, jurisdiction, key dates and conflict-check flags. Refuses to infer a jurisdiction that is not stated in the source.
Deposition Digest. Ingests transcript exports and produces issue-tagged summaries. Every assertion carries a page-and-line citation, so a reviewer can check it without re-reading the transcript.
Billing Narrative Cleaner. Rewrites terse time entries into client-ready narratives. Constrained to the work described in the entry — it cannot add tasks, and it cannot change the duration.
HubSpot Matter Sync. Reads and writes matter and contact data through the MCP connection so the CRM stays current without a second data-entry pass.

Deployment procedure

In execution order. Each step is verified before the next begins, because every one of them is harder to correct once people are inside the system.

Map practice groups to conflict boundaries and agree the workspace list with the general counsel.
Configure SSO against the identity provider and confirm a test account provisions and deprovisions.
Create one workspace per practice group and assign owners.
Set retention and training-exclusion settings at the organization level; export the configuration and date it.
Create the HubSpot private app with the narrowest scopes that support the workflow.
Connect the MCP server and confirm a read returns the expected matter.
Build each skill against sanitized matters, never live client material.
Pilot with one practice group for a week and collect the tasks people actually ran.
Adjust the skills against that list, then open access to the remaining groups.
Verify. From a Litigation workspace, request a document that exists only in Corporate; it must not be retrievable. Attempt a write to a billing object through the MCP connection; it must return a 403. Offboard the test account and confirm its session ends. Until all three behave, the deployment is not finished.

Rollout sequence

The rollout in five phases, and what each one is allowed to touch

Phase	Stage	What happens
PhaseWeek 1	StageDiscovery and governance	What happensPractice groups, data-sensitivity tiers and ethical-wall requirements mapped. Who may access what is defined before a single account is provisioned — the boundary is far cheaper to draw before people are inside it.
PhaseWeek 2	StageOrganizational account configuration	What happensOrganizational plan stood up, SSO wired to the firm's identity provider, a workspace configured per practice group, retention posture documented for the general counsel.
PhaseWeeks 3–4	StageMCP connection and skill development	What happensHubSpot MCP server connected and its credentials scoped. Four skills built against sanitized matters, so no live client material is used during development.
PhaseWeek 5	StageEnablement design	What happensPrompt library per workspace, in-product guardrail messaging, a one-page playbook per practice group. Hands-on cohorts rather than a single webinar.
PhaseWeek 6	StageFirm-wide rollout	What happensAccess opened with monitoring dashboards, an internal support channel and weekly office hours for the first month.

Five Ways This Goes Wrong

Five ways this deployment goes wrong, each traced to its mechanism

Symptom	Cause	Fix
SymptomAttorneys keep using personal AI accounts after launch.	CauseThe sanctioned tool is slower for their most common task than the unsanctioned one. Policy does not beat friction.	FixInstrument which tasks are running where before rollout, then build a skill for the highest-volume task so the sanctioned path is the fastest path.
SymptomA workspace can retrieve material from another practice group.	CauseIsolation was configured on the workspace, but a shared connector, project or knowledge source sits above it and is visible to both. This violates what Saltzer and Schroeder (1975) call complete mediation: every access to every object must be checked, and a path that bypasses the check makes the boundary advisory.	FixAudit every connector and shared project against the workspace boundary, not just the workspace list. Test by asking one workspace for a document that exists only in another.
SymptomThe MCP connection can write to objects nobody intended.	CauseThe private app token was granted a broad scope such as crm.objects.contacts.write when only specific matter properties needed updating.	FixScope the token to the narrowest set that supports the workflow, then verify by attempting a write the token should not have. A 403 is the passing result.
SymptomDrafted output contains a citation that does not exist.	CauseThe skill was written to produce a format rather than constrained to a source. A model asked for citations in a shape will produce that shape.	FixConstrain each skill to material in the provided document and require a locator for every claim. Review a sample weekly rather than trusting the constraint permanently.
SymptomAccess persists after someone leaves the firm.	CauseAccounts were provisioned directly instead of through the identity provider.	FixProvision through SSO so deprovisioning follows the HR event. Verify by offboarding a test account and confirming the session is gone.

Limits of this architecture

Workspace isolation separates content inside Claude. It does not stop someone re-uploading a document into the wrong workspace themselves, and no platform setting will. That remains a supervision problem.

A citation constraint reduces fabricated references; it does not remove the need to check them. This is the practical consequence of the automation-bias finding: a reviewer presented with a confident, well-formatted output tends to check it less carefully than one presented with a rough draft, and the citation is what makes checking cheap enough to actually happen (Skitka, Mosier, and Burdick 1999). Nothing here relieves an attorney of the obligation to verify what they file, and the enablement material says so in the product rather than only in training.

This page does not cover matter-level access control below the practice-group boundary, retention obligations under a litigation hold, jurisdiction-specific disclosure duties about AI use, or pricing. The first two are firm-specific; the third is a question for counsel rather than an implementation partner.

References

Vendor settings change; re-verify before relying on any of it in a compliance document.

Davis, Fred D. 1989. "Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology." MIS Quarterly 13 (3): 319–340. https://doi.org/10.2307/249008

Parasuraman, Raja, and Victor Riley. 1997. "Humans and Automation: Use, Misuse, Disuse, Abuse." Human Factors 39 (2): 230–253. https://doi.org/10.1518/001872097778543886

Saltzer, Jerome H., and Michael D. Schroeder. 1975. "The Protection of Information in Computer Systems." Proceedings of the IEEE 63 (9): 1278–1308. https://doi.org/10.1109/PROC.1975.9939

Skitka, Linda J., Kathleen L. Mosier, and Mark Burdick. 1999. "Does Automation Bias Decision-Making?" International Journal of Human-Computer Studies 51 (5): 991–1006. https://doi.org/10.1006/ijhc.1999.0252

Speier, Cheri, and Viswanath Venkatesh. 2002. "The Hidden Minefields in the Adoption of Sales Force Automation Technologies." Journal of Marketing 66 (3): 98–111. https://doi.org/10.1509/jmkg.66.3.98.18510