AI agent permissions and governance for a firm

AI agent permissions and governance at a professional firm come down to three decisions for each workflow: what the agent may read, what it may write inside your own systems, and what it may send or do outside the firm. Keep reading limited to the folders and records that one workflow needs, keep writes as drafts or staged changes, and make anything that leaves the firm wait for a named person's approval.

This article is for the operations or IT lead who receives the request. Someone on the team wants the assistant connected to the shared mailbox, the document system, the CRM, or the accounting software, and you are the person who has to say yes, no, or yes with conditions. What follows is a model you can apply with the admin settings you already have.

What changes once AI can act?

A chat assistant produces text, and a person decides what to do with it. An agent connected to your systems can open files, change records, and send messages. The security community has a name for the resulting risk. OWASP's 2025 list of the top risks for applications built on language models includes Excessive Agency, which it defines as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM."

OWASP names three root causes: excessive functionality, excessive permissions, and excessive autonomy. Those three map onto three plain questions a firm can answer without a security team. Which tools does the agent have at all? How much of each system can it reach? Which actions happen without a person looking first?

Three kinds of access: read, write, and send

Sort every capability a connector offers into one of three bins before you approve it.

Kind of access	What it covers	Default rule	Example
Read	Opening files, searching mail, querying records	Allowed, limited to the folders and records the workflow needs	Reading the lease folder for one client to prepare an abstract
Write inside the firm	Creating or changing things only your own people see	Allowed as a draft or staged change that a person can inspect and undo	Saving a draft reply, filling a workbook, proposing a CRM update
Send or act outside the firm	Anything a client, counterparty, regulator, or bank will see	Waits for a named person's approval every time	Sending an email, submitting a filing, releasing a payment

The third bin is defined by who sees the result. A CRM update that triggers a client-facing notification belongs in it, even though the CRM is your own system.

Why untrusted content matters: prompt injection in plain terms

An agent reads text and acts on it, and it cannot always tell your instructions apart from instructions planted in the material it is reading. That is prompt injection. Anthropic's own illustration is a good one: you ask the assistant to read recent emails and draft replies to meeting requests, and one email contains hidden white text directing the agent to forward messages containing the word "confidential" to an outside address. OWASP describes a similar mailbox scenario and notes that it could be avoided by giving the assistant a read-only mail extension, a read-only permission scope, or a manual approval step before any message is sent.

Anthropic is candid that this is not solved. In that same research post, published in November 2025, it wrote that "prompt injection is far from a solved problem, particularly as models take more real-world actions" and that no browser agent is immune to it. The post reports a 1% attack success rate for Claude Opus 4.5 operating a browser against Anthropic's internal adaptive attacker, and says that figure "still represents meaningful risk."

The practical consequence is a rule about combinations. An agent that reads content written by outsiders (inbound email, web pages, documents a counterparty sent) while also holding access to client files and the ability to send is the arrangement that needs the most care. Remove one of the three and a planted instruction has much less to work with.

Give each workflow its own narrow access

Permissions are easier to reason about per workflow than per person or per tool. A lease abstraction workflow needs to read one deal folder and write one workbook. A weekly market report needs to read a data export and write a draft document. Neither needs the whole drive or the mailbox.

OWASP's recommendations on the same page say the same thing: limit the extensions an agent can call to the minimum necessary, and limit the permissions those extensions hold in other systems. The Model Context Protocol (MCP) is the standard that Claude's connectors are built on, and its specification gives matching advice to connector developers in its security best practices: start with a minimal set of low-risk read operations, add privileges only when an operation needs them, and avoid wildcard or "full-access" scopes.

If your team is still deciding whether a job needs an agent at all, our comparison of workflows, agents, skills, and custom software covers that choice.

Where a person approves, and why that step stays

We build workflows so that AI does most of the work and a person checks what matters, and the send step is where that principle is least negotiable. OWASP recommends requiring a human to approve high-impact actions before they are taken. Because prompt injection is not solved, approval on outbound actions is the control that does not depend on the agent noticing an attack.

Two details make the approval worth something. Name the approver in writing, so that "someone reviews it" becomes a person with a job. And show the approver the actual outbound content, including the recipient list and attachments, at the moment of the click. Our article on designing the human review step goes further into what a reviewer should see.

The controls you already have

The settings below are described as of October 2, 2026. Vendors change them often, so check the linked documentation before you rely on any of them.

Per-tool settings on each connector. In Claude, each connector has a tool permissions section where you choose Always allow, Needs approval, or Blocked for a group of tools or a single tool. This is where the three bins become settings: read tools allowed, draft tools allowed or approved, send tools set to needs approval or blocked.

Organization-level controls that staff cannot relax. Anthropic's documentation says an organization can set per-tool controls on connectors. Where Claude Code enforces these settings, a tool the organization sets to ask prompts on every call with no option to remember the choice, and a tool set to blocked is removed before Claude sees it. The documentation notes an exception for the desktop app's local and SSH sessions, where the ask setting does not reach Claude Code. The same blocked setting applies in the desktop app and in claude.ai chat.

Control over who adds a connector. On Claude Team and Enterprise plans, an Owner adds a connector for the organization and members then connect with their own account. On Team plans, members without that permission see a Request button that routes to the Owners. Microsoft describes a comparable arrangement for Copilot: admins can view the permissions and data access an agent requires and select which agents are allowed, and a user can only access agents the admin allows.

Allowlists and managed settings for technical staff. If anyone at the firm uses Claude Code, administrators can publish an allowlist of approved MCP servers and lock it so users cannot broaden it. Administrators can also deploy managed settings that user and project settings cannot override, including deny rules that block Claude's file tools from reading named files or folders and a setting that disables the mode that skips permission prompts.

A directory listing is not a substitute for your own review. Anthropic states that connector verification "isn't a security audit" and that a connector's developer controls its tools and can change them after review.

Use each person's own sign-in so the agent inherits their permissions

Avoid a shared service account with broad access. When each person connects with their own account, the agent can reach what that person can reach and no more. OWASP lists this among its mitigations: actions taken on behalf of a user should run in downstream systems in the context of that specific user, with the minimum privileges necessary.

This cuts both ways. Microsoft states that Copilot only surfaces organizational data to which individual users have at least view permissions, and it asks customers to use the permission models in services such as SharePoint to keep access correct. A folder that was shared with everyone five years ago is now within reach of everyone's assistant. Cleaning up old sharing belongs at the top of the list in an agent rollout.

Logs and a quarterly review

OWASP also recommends logging and monitoring the activity of extensions and downstream systems to identify where undesirable actions are taking place. For a small firm that means knowing, before you approve a connector, where its activity is recorded.

Check two places. The first is the AI vendor's log. Anthropic's audit logs are available for Enterprise organizations only, an export covers the past 180 days, and chat and project titles and content are not included. The article's list of recorded events does not mention connector tool calls, so ask Anthropic what your plan records before you count on it. The second is the connected system itself: your mail platform, document system, and CRM each keep their own record of what was read, changed, and sent. Ask the vendor how an agent's actions appear there.

Once a quarter, review the list of connectors, who has them connected, which tools are set to always allow, and whether each workflow still needs the access it holds.

A permissions register you can keep in a spreadsheet

Write the decisions down in one place the firm owns. One row per workflow is enough. The rows below are an illustrative example of the format.

Workflow	Systems reached	Read	Write	Send	Approver	Date reviewed
Lease abstraction	Deal folder for the assignment, abstract workbook	Deal folder only	Draft workbook	None	Senior analyst on the deal	2026-10-01
Client email drafting	Mailbox, client folder	Client thread and folder	Draft replies only	Blocked for the agent, the person sends	Account owner	2026-10-01
CRM update after a call	CRM, call notes	Contact and deal record	Staged update	Needs approval if it triggers a client notice	Team lead	2026-10-01

The register also answers the questions that come from outside. A client security questionnaire or a regulator's inquiry will ask what your AI tools can reach and who oversees them, and this page is the answer. What a specific rule requires of your firm is a question for your own counsel or compliance lead. The register pairs well with an AI acceptable use policy and with the broader setup described in our guide to secure AI workflows for confidential client data.

What to ask before approving a new connector

1. Which workflow is this for, and who owns that workflow?
2. Which of its tools read, which write, and which send or act outside the firm?
3. Can the read access be limited to specific folders, mailboxes, or records?
4. Does the agent read content written by outsiders while this connector is on?
5. Which tools will be set to needs approval or blocked, and can staff change that setting?
6. Does each person sign in with their own account?
7. Who built the connector, and has anyone at the firm reviewed what it does with our data?
8. Where will its actions be logged, and who will look?
9. Who approves outbound actions, by name?
10. When will this row in the register be reviewed next?

If you would like help working through them for a workflow your team is about to connect, get in touch.

Common questions

Is it safe to connect an AI assistant to our email and files?

It can be reasonable when the connection is read-only or draft-only, limited to the folders a specific workflow needs, and every send action waits for a person's approval. The combination to be careful with is an agent that reads inbound email or web pages while it also holds client files and the ability to send. Confirm the setup with your own security or compliance lead before turning it on.

What is prompt injection and should a small firm worry about it?

Prompt injection is text hidden in an email, document, or web page that an AI agent reads and treats as an instruction. Anthropic wrote in November 2025 that it is far from a solved problem, so a small firm should plan for it by limiting what the agent can do rather than trusting the agent to spot every attack.

Can we stop the AI from sending anything without approval?

In Claude, yes. As of October 2026, each connector lets you set a tool to always allow, needs approval, or blocked, and Anthropic's documentation describes organization-level controls under which a blocked tool is unavailable to members. Check the equivalent setting in whichever assistant your firm uses, because these controls change often.

Does the AI see everything the user can see?

When each person connects with their own account, the agent can generally reach what that person can reach in the connected system. Microsoft states that Copilot only surfaces organizational data that the individual user has at least view permission for. That makes old, overly broad sharing on folders the first thing to clean up.

Should an agent ever run without a person approving?

For reading and for drafting inside your own systems, yes, once you have tested the workflow. For anything a client, a regulator, or a bank will see, keep a named person's approval in place. OWASP's guidance on excessive agency recommends human approval for high-impact actions.