Brass scales of justice beside a laptop on a desk

Deny by default: what CIOs can learn from a law firm's zero trust operating model

Most IT estates still run on a simple rule: software is allowed unless something flags it as bad. That rule is under more strain than ever. Staff download tools to get a job done, vendors need admin rights for an afternoon, and now AI agents can open applications, run scripts and reach files on a user's behalf.

A case study from ThreatLocker, the zero trust security company and a partner of our CIO and CISO summits, shows what the opposite approach looks like when a CIO runs it day to day. It follows RumbergerKirk, a law firm in the south-eastern United States, where CIO Avi Solomon runs what the case study calls a "deny by default" environment. Only software that has been explicitly approved can run, and even approved software is kept inside clear limits.

The story is worth reading for any CIO, not just those in legal services, because it is less about a product and more about an operating model.

The problem

Law firms hold some of the most sensitive data there is, and their people are not security specialists. According to the case study, Solomon's team needed to:

block untrusted executables and scripts appearing on endpoints
stop trusted applications from behaving in unexpected ways
prevent privilege creep across attorneys, IT staff and vendors
protect sensitive case data from misconfigured processes and user error
detect and respond quickly when alerts were noisy or unclear
deal with configuration drift and legacy settings

What deny by default looked like in practice

The case study is built around real moments rather than a feature list. A few stand out.

An unapproved download that went nowhere. One morning an attorney tried to launch a utility they had downloaded without approval. Application allowlisting blocked it and logged the attempt. As the case study puts it, there was no investigation cycle, no clean-up and no chance for lateral movement. Solomon describes allowlisting as the foundation of his defences because it stops untrusted code before it can run.

A trusted tool that strayed. A legitimate application started to access files outside its normal working folders. Ringfencing kept it within its allowed paths, so the application kept working while the unnecessary access was blocked.

A vendor who needed admin rights. A vendor had to run an administrative utility on an attorney's workstation. Nobody at the firm gets blanket local admin rights, so Solomon approved elevation for that one tool only. The job got done and the wider environment stayed locked down.

A workflow that reached too far. A misconfigured workflow tried to access protected legal matter folders. Storage control blocked it and logged the attempt, which gave the team visibility without any data leaving where it should be.

A noisy day. When detection tools surfaced a suspicious pattern of processes, Solomon used the telemetry to find the source and confirm there was no compromise. During a particularly noisy run of alerts, ThreatLocker's managed detection and response team responded within minutes, confirmed the threat level and advised on next steps.

The outcomes the case study lists are practical ones: unauthorised code blocked across several incidents, risky application behaviour contained in real time, response in minutes during threat events, less privilege exposure across attorneys, staff and vendors, and tighter control over sensitive data without slowing the business down.

Five lessons for CIOs

1. Treat it as an operating model, not a tool. The firm's approach works because the rules are clear: approve what is needed, block the rest, and give rights to applications rather than people. That is a policy decision the CIO owns, not a setting.

2. Make approval easy, or people will work around it. Deny by default only survives if the approval route is quick. The NCSC makes the same point in its device security guidance. It says allow lists are a much better strategy than deny lists, and suggests tying them into software licensing and procurement through a lightweight approvals process.

3. Start by watching, then enforce. Both ThreatLocker's learning mode and the NCSC's guidance start the same way: first record what is already running, then switch to enforcement. The NCSC suggests running application control in a reporting mode first, so you can see what would be blocked before anything is.

4. Give rights to tasks, not to people. The vendor example is the one most IT teams will recognise. Temporary, task-specific elevation removes a whole category of risk without leaving the vendor stuck.

5. Keep a human backstop. Prevention reduces the number of alerts, but it does not remove them. The firm pairs its controls with detection and outside analyst support, so a small team is not left to read every alert on its own.

The same thinking now applies to AI agents

This is where the story becomes timely. On 20 October, ThreatLocker launched Zero Trust AI Control, a tool for controlling what AI agents can access, run and connect to. The company's argument is simple. A single request to an agent can set off actions across applications, scripts, browsers and other services, and guardrails built into the AI itself can be worked around. So the limits should sit outside the agent.

"The security challenge has fundamentally changed because AI agents aren't just providing information anymore. They're being used to take actions across an organization's environment," said Danny Jenkins, CEO and co-founder of ThreatLocker, in the launch announcement.

According to ThreatLocker, the tool lets teams start from pre-built policies, decide which files and folders an agent can read or change, keep higher-priority rules in force when an agent calls other tools such as PowerShell or Office, and see agent activity from one dashboard.

For CIOs, the link to the RumbergerKirk story is direct. If you already control which software can run and what it can reach, an AI agent is one more thing to bring inside those limits. If you do not, agents will inherit whatever access the user has.

Questions to take to your next leadership meeting

Do we know every piece of software running on our endpoints today?
How long does it take a member of staff to get a new tool approved?
Who in our organisation still has standing local admin rights, and why?
Which AI agents are in use, and what can they reach on a user's behalf?
If an unapproved tool ran tomorrow, would we be told, and by whom?

The bottom line

Deny by default used to sound like a recipe for unhappy users. The RumbergerKirk case study suggests the opposite can be true when the rules are clear and the approval route is quick. With AI agents arriving in every part of the business, the CIOs who already know what is allowed to run will find the next step much easier.

ThreatLocker will be at our CIO and CISO Inspired Summit in London on 23 and 24 November, and our events calendar shows where we are meeting next.