A phased rollout should not postpone security. It should match capability, data access and monitoring to what the firm is prepared to govern.
Law firms tend to talk about enterprise AI rollouts as a yes or no decision. Either the tool is approved for everyone, or it stays blocked until every question has been answered.
Neither option works particularly well.
Waiting for a perfect control environment can stall a useful platform for months. Moving too quickly creates the opposite problem. The firm launches broadly, then learns that the product can reach more data, take more actions or produce less useful telemetry than anyone expected.
I think there is a better middle ground: crawl, walk, run.
Not as a project slogan. Most of us have seen enough of those. I mean three real control boundaries, where each phase defines who can use Claude, what it can do, what information it can reach and what evidence the security team will receive. Access expands only after the next set of controls is working.
Start with the boundary that matters most
Before getting into connectors, agents or prompt injection, ask a more basic question: Which Claude account are people using?
A firm can purchase Claude Enterprise and still have lawyers using personal Claude Pro accounts through a browser or desktop application. The enterprise agreement does not protect work performed outside the enterprise organization. That sounds obvious when written out, but it is easy to miss in practice.
This became more important when Anthropic's updated consumer Privacy Policy took effect on July 8, 2026. Anthropic says the policy applies to consumer services and does not govern content processed for Enterprise customers. The consumer policy also describes circumstances in which personal data may be shared with government authorities or law enforcement when Anthropic has a good faith belief that disclosure is reasonably necessary.
I wrote about the law firm confidentiality implications in The AI Confidentiality Risk in Your Firm's Claude Pro Account. The short version is that approving the vendor is not enough. The firm also needs to enforce the approved account and service tier.
Claude Enterprise does not make every confidentiality concern disappear. It puts the firm's use under a different commercial and administrative boundary. Governance still has to keep the work inside that boundary.
The first gate should be simple: Can the firm demonstrate that client work occurs only inside its approved Enterprise organization, or has it merely published a policy saying that it should?
Crawl: create a minimum viable secure pilot
The crawl phase needs to be useful. If the pilot is so restricted that nobody can perform real work, it will not teach the firm much. But it should still be narrow enough that a mistake has a limited consequence.
Start with named users, named use cases and named data exclusions. Avoid vague descriptions such as “general productivity.” What work is the group testing? What information may they use? What remains off limits?
A reasonable crawl phase will usually include:
- Enterprise identities enforced through the firm's identity provider, with SSO and MFA.
- A small, supervised pilot group using role based access instead of organization wide enablement.
- Firm managed endpoints, standard user privileges, encryption, endpoint protection and managed application settings.
- Web search, browser control, computer use, connectors, plugins and MCP servers disabled unless a specific pilot use case requires one of them.
- File access limited to approved working folders, with high-sensitivity repositories kept out of scope unless their use has been expressly authorized.
- An acceptable use rule that tells people what data is permitted, what is prohibited, when human review is required and where questions should go.
- Chat feedback disabled if the firm does not want a reported conversation retained and potentially used for model improvement.
The pilot is not safer merely because it is small. It is safer because the firm knows who is participating, what Claude can reach and which capabilities have been withheld. There is a difference.
Training matters here too, although not the generic “use AI responsibly” presentation everyone forgets by the following week. Users need to understand the boundaries of this specific pilot and what to do when Claude requests access or takes an action they did not expect.
Walk: add enforcement and visibility before expanding
Suppose the pilot goes well. People find useful workflows, demand grows and other practice groups want access. This is usually where the pressure to move faster shows up.
The next question should not be how quickly the firm can assign more licenses. It should be whether the firm can govern a larger population that will receive less direct supervision.
The walk phase should add:
- SCIM provisioning and deprovisioning so access follows the firm's identity lifecycle.
- Tenant Restrictions, or comparable network enforcement, to reduce the use of personal Claude accounts from managed networks.
- Group based roles that separate ordinary chat, Cowork, connectors, plugins and administrative functions.
- OpenTelemetry routing from Cowork into the firm's monitoring environment.
- Data loss prevention and endpoint controls appropriate to the information the group is allowed to use.
- A connector review that covers authorization scopes, read and write capabilities, downstream data handling and revocation.
- An incident process that identifies who can suspend access, preserve the evidence that is available, assess affected matters and involve legal or client stakeholders.
Here is the monitoring issue that can catch a team off guard. As of July 2026, Anthropic says Cowork activity is not captured in its audit logs, Compliance API or data exports. Team and Enterprise organizations can stream Cowork events through OpenTelemetry, but that is a separate implementation step.
In other words, buying Enterprise does not cause Cowork activity to appear in the firm's SIEM. Someone still has to configure the telemetry, route it, test it and decide which events matter. That last part takes some judgment. Collecting everything without a plan usually creates noise, not visibility.
If the firm is not ready to monitor Cowork, it can keep Cowork limited while expanding lower risk chat use. The product's capabilities do not all have to move at the same speed. I would argue that they should not.
Run: scale through a repeatable approval model
Run does not mean unrestricted. It means the firm has stopped treating every new AI request as a one time exception.
At this point there should be a repeatable way to introduce new users, data sources and agent capabilities without redesigning governance each time. That operating model will look different by firm, but it should cover a few basics:
- Capability profiles by role or practice group instead of one global configuration.
- A documented approval path for connectors, plugins, MCP servers, browser use, computer use and scheduled or remote tasks.
- Least privilege connector permissions, with additional review and human approval for write actions or actions that create an external consequence.
- Testing for prompt injection, unintended tool use, data leakage and failure modes in the firm's real workflows.
- Security analytics that combine identity, endpoint, network, data and Cowork telemetry.
- Measures for adoption, quality, exceptions, incidents and control effectiveness, not just licenses assigned or prompts submitted.
- A recurring review of Anthropic's product changes, privacy terms, model specific retention requirements and new administrative controls.
This last item is easy to underestimate. Claude is changing quickly. A control review performed six months ago may no longer describe what users can do today. New capabilities can alter the data flow without anyone changing the original deployment plan.
The real gotcha in crawl, walk, run
A phased plan can create false comfort when deferred controls begin to look like completed controls. They are not the same thing.
A faster launch may be reasonable. Sometimes it is the right decision. But the firm needs to write down what it is accepting, assign an owner and tie the missing control to a clear gate before expansion.
I find it more useful to organize those decisions around four questions that apply to almost any enterprise AI deployment: Who can get in? What can the system do? What information can it reach? What evidence will the firm receive? In other words: Identity, Capability, Data and Visibility.
| Control gate |
Pilot boundary |
Evidence before expansion |
| Identity |
Access is limited to a named Enterprise pilot group. Personal consumer accounts may still bypass firm controls if tenant enforcement is not in place. |
Identity lifecycle, tenant restrictions and detection of access outside the approved organization have been tested. |
| Capability |
Connectors, plugins, browser control, computer use and other higher consequence actions remain disabled unless the pilot requires them. |
Each new capability has an owner, defined permissions, a human approval model and a tested method for disabling it. |
| Data |
High-sensitivity repositories remain outside the pilot boundary, which means some intended workflows cannot yet be tested. |
Approved data classes, access paths, DLP controls and use case authorization have been defined and validated. |
| Visibility |
Investigation may depend on supervision and endpoint evidence until Cowork telemetry is routed into the firm's monitoring environment. |
OpenTelemetry has been validated end to end, useful alerts have been tested and response ownership is clear. |
The point is not to create another spreadsheet that nobody opens. It is to keep the deferred risk visible. It should appear in the risk register, the rollout plan and the decision to enter the next phase.
If it disappears into a future state diagram, people will eventually forget that the risk was accepted rather than resolved. I have seen that happen more than once.
A better question for the steering committee
Is Claude Enterprise secure?
That question is too broad to be very useful. Security depends on the account, enabled capabilities, accessible data, endpoint, identity controls, monitoring and what the firm does when the tool behaves in an unexpected way.
I would ask this instead:
What can this group of users do with Claude today, what information can it reach, what evidence will we receive and what must be true before we allow more?
Crawl, walk, run works when each phase is a control boundary, not a date on a project plan. Start with the commercial boundary. Constrain capability and data. Add visibility before scale. Then require evidence before each expansion.
That approach lets a firm learn quickly without pretending that speed and governance are opposites.
Sources and further reading
About the author
Steve Combs is Co-Founder and Managing Director of Cocha Technology. He focuses on AI governance, data security and the practical deployment of enterprise AI in law firms and other regulated organizations.