Don't give it the keys to the law firm: how to limit an AI agent

An AI agent does not need access to everything to do a task well. The useful question is not whether we trust the model, but what it can do even when it makes a mistake.

An assistant answers. An agent acts. It can open files, execute commands, query services, modify documents or send the result to someone else. That capability saves work, but it also changes the security question. Reviewing what the AI says is no longer enough. We need to decide what we allow it to do before it starts.

In a law firm, granting full access to a computer to summarise a contract would be like handing over the keys, the alarm code and the entire archive to find a folder. The task may be legitimate. The permission is still disproportionate.

Two recent developments show why this matters. Claude Code fixed cases in which deny or confirmation rules could fail with compound commands, files opened through symbolic links and commands preceded by environment variables.[1] Apple, for its part, announced additional controls for granting Full Disk Access. The company pointed out that this permission bypasses many of macOS's ordinary protections and can expose files, email, messages and browsing history.[2]

This is not a reason to reject agents. It is a reason to treat them as operators with permissions, not as simple text boxes.

The decisive permission is the scope

The principle of least privilege predates AI. NIST defines it as restricting each user—or a process acting on their behalf—to the minimum privileges needed to perform the assigned task.[3] Applied to an agent, it requires separating capabilities that are often bundled into a single “access” checkbox:

• Read: open documents in a specific folder.
• Write: create or modify files within a workspace.
• Execute: run programs, scripts or commands.
• Connect: access the internet, an API or an internal system.
• Send or publish: produce an effect visible outside the working environment.
• Delete or change permissions: take actions that are difficult to reverse.

These capabilities do not carry the same risk. An agent may need to read three contracts without needing access to the client's entire mailbox. It can prepare a reply without being able to send it. It can generate a new version without overwriting the original. It can check a website without having the credentials to deploy it.

Security improves when permission follows the task and expires with it. “Work on this case file for one hour” is a better-defined authorisation than “you can access the document management system”. “Create a draft in this folder” is easier to control than “edit my files”. The product's name matters less than that effective boundary.

Technical limits can fail too

A deny rule seems simple: if a dangerous command appears, block it. In practice, the same effect can be expressed in many ways. A command can form part of a chain, appear after a variable assignment or reach a file through an indirect path. The fixes in Claude Code v2.1.289 are valuable precisely because they make that complexity visible.[1]

The right conclusion is not that permission rules are useless. It is that no single layer should bear the entire security burden. A list of prohibited commands helps, but does not replace file system isolation. Human approval helps, but does not replace an account without access to production. A log helps with investigation, but does not undo an email sent to the wrong recipient.

Nor do we need to attribute malicious intent to the model. An ambiguous instruction, a file containing misleading content, an interpretation error or a defect in the application executing the action is enough. Designing the boundary helps ensure that an ordinary failure has ordinary consequences.

Apple approaches the same problem from another angle. Full Disk Access was created for exceptional uses, such as certain backup applications. When it is granted to an application with agent capabilities, the permission no longer covers one specific operation and opens up a very broad part of the user's digital life.[2] The question is not just “do I trust this application?”, but “why does it need to see everything to complete this task?”.

A practical model for the law firm

There is no need to build a sophisticated architecture from day one. It is, however, advisable to establish five limits before connecting an agent to real work.

1. A separate working area

Copy or link only the necessary documents into a folder for the matter. Avoid starting the agent from your home directory, the entire mailbox or a shared drive containing other clients' files. If the task can be done with read access, start without write permission. If it needs to produce files, give it a new output folder, not the original.

2. Its own limited identity

Do not hand over the usual credentials of a partner, administrator or head of IT. Use a dedicated account with access to the essential repositories, mailboxes or services. Prefer temporary, revocable credentials. A limited key lets you close one door without changing every lock in the firm.

3. Network access and tools as needed

An agent reviewing local documents may not need the internet. If it needs to consult sources, restrict the destinations where possible. If it uses connectors, enable only the required operations. “Search case files” and “modify case files” should be separate permissions.

4. Approval for external effects

Low-risk, reversible actions can be performed within the boundary without interrupting the professional. Actions that cross that boundary must stop. In a law firm, the checkpoints are usually few and clear: sending an email, filing a legal document, publishing content, deploying a system, deleting information, changing access or sharing data with a third party.

Approval must show exactly what is involved: what will be sent, to whom, from which account and with which files. Authorisation to publish a specific version can cover the entire technical sequence—saving, deploying and checking—provided that the content, destination and permissions remain unchanged. If any of those elements changes, the decision changes.

5. Logging, testing and revocation

Keep a sufficient trail to answer three questions: what the person requested, what the agent tried to do and what actually happened. Record denials and approvals too. When the work is finished, revoke temporary credentials and close off access. A permission that nobody remembers to revoke becomes permanent infrastructure by accident.

Controls work better in layers. For Codex, OpenAI describes two complementary mechanisms: the sandbox sets the technical boundary—where it can write or whether it can use the network—and the approval policy decides when it must stop and ask for permission.[4] The same pattern can be applied without adopting any particular tool: a limit the machine cannot cross and a human decision for exceptions.

Test before expanding: a real pilot

In a recent pilot, I used Hermes to coordinate a task and Codex to execute it within a single repository. The first test began in read-only mode, with no network access and no permission to modify other workspaces. The instruction identified the repository, the branch and the starting point. At the end, we independently checked that the commit had not changed and that the working tree remained clean.

That result did not demonstrate that the model was infallible. It demonstrated something more useful: that it could produce a valid response without being given write permissions or general access to the computer.

The second decision was organisational. Hermes coordinated and verified; Codex executed. There were not two agents writing in the same workspace at the same time. Preparing drafts and running tests could take place within the boundary. Publishing, deploying or contacting third parties remained subject to explicit approval.

Control was not added as a bureaucratic review at the end. It formed part of the assignment: scope, permissions, expected result and verification criterion. Expanding capabilities only made sense after observing a specific need.

The risk of asking too often

A system that asks for permission for every read, search or routine command ends up training the user to click “Accept”. Approval fatigue is not a theoretical objection. OpenAI has described how frequent interruptions can lead users to enable full access, create overly broad rules or approve without understanding the consequence; its internal data on automatic review show a very large reduction in interruptions, although the company itself warns that this mechanism does not offer deterministic guarantees.[5]

The solution is not to remove approvals, but to place them at the right boundaries:

• Within the boundary: reversible, logged operations necessary for the task.
• When crossing the boundary: contextual review or a specific rule.
• For an external effect or one that is difficult to reverse: human approval with the content and destination visible.

This focuses attention where it matters most. The professional does not review a hundred technical steps; they decide on the few actions that can compromise confidentiality, money, rights, reputation or production.

Nine questions before clicking “Allow”

Before using an agent with the firm's data or tools, it is advisable to answer these questions in writing:

1. What is the exact task, and when does it end?
2. Which files and systems does it need to read?
3. Where can it write, and which originals remain protected?
4. Does it need network access? To which destinations?
5. Which credentials will it use, and how are they revoked?
6. Which external or irreversible actions require approval?
7. What will the person giving approval see?
8. What record will remain of instructions, decisions and results?
9. Have we tested both an allowed action and an action that must be blocked?

Trust can grow later. Permissions should not get ahead of it.

A useful agent is not one that receives all the keys. It is one that can complete its work with a limited key, for as long as necessary, while the important doors remain under human control.