For Tom and Miles
The Control Points
You Own.
The companion document for the rest of the team is What Max Can Do, and What Always Needs Your Click.
This describes the controls and where they live. It deliberately does not record what any of them is set to right now, because a document that states a current setting is wrong the first time somebody changes one. Each control below tells you where to read its live state.
The frame
What leaves the building.
Most of what Max does is reading, and reading is not the risk. The risk is the smaller set of actions that become externally visible or irreversible the moment they happen:
- an email sent
- a calendar invite to an external attendee
- a file or link shared outside QMax
- an invoice or a collections notice reaching a customer
- a form submitted on a website
- a record written into a system of record
There are five surfaces on which one of those can occur. They have different owners and different controls, and a control on one surface does not constrain another. That is the single most important thing on this page.
Surface 1
Max working
inside a browser.
- What it can do
- Operate any website in a signed-in browser session, as that person. Click, type, submit. It is not asking a system for permission, because from the site's point of view it is the signed-in user.
- Why it is first
- Every other control described below sits on the connection path between Claude and a system. A browser action does not travel that path. Connector permissions, directory consent, and the approval gate in the QMax system are all bypassed, not because they failed, but because they are not on this road.
- Click path
- Claude → Settings → Organization settings → the Claude in Chrome section
Where the control lives
Claude organization settings, in the section governing the browser extension. Two levers:
- A site blocklist set at the organization level. This overrides what individual users have allowed for themselves, which is what makes it a control rather than a suggestion. Blocking the web applications that perform outbound actions, webmail in particular, closes the gap.
- Turning the extension off for the organization, if you would rather not run this surface at all right now.
The granularity is the site, not the action
This is the property that matters most and the one that is easiest to get wrong. Within a site Max is allowed to reach, every action is a click, and nothing distinguishes reading a page from pressing send. There is no per-action control on this surface. The site list decides where Max can go, not what it can do once it is there — so a site Max can reach is a site where it can do anything the signed-in person could do.
What it does not cover
A blocklist is a list. It constrains the sites on it and nothing else. Adding a new web application to how QMax works is a moment to revisit the list, and the question to ask about each one is whether an action taken there would be visible outside QMax.
Our recommendation
Blocklist webmail at the organization level and let mail flow through the connected path described next, where drafting and sending are separate and controllable. People keep the ability to send email. They send it themselves, from Outlook, after reading it.
Surface 2
The Microsoft 365 connection.
What it can do. Read mail and calendar, create drafts, send mail, create and change calendar entries, reach files. These are separate capabilities, which is what makes this surface controllable in a way the browser is not: reading and drafting can stay on while sending is restricted.
Where the control lives. Two levers, and they are owned by different people.
Lever 1 — fast
In Claude
Your organization admin
Each capability can be set to allow, to require approval per use, or to block. This changes behavior immediately and you can change it back just as fast.
Claude → Settings → Organization settings → Connectors → Microsoft 365, then set the individual capabilities
Lever 2 — durable
In your Microsoft directory
Your IT administrator
The permissions granted to the connecting application can be revoked outright. Where the fast lever is a policy that a system honors, this one removes the ability. If sending permission is not granted, no setting anywhere and no instruction to Max can produce a sent message.
Microsoft Entra admin center → Enterprise applications → the Microsoft 365 connector application → Permissions
The combination worth having
Keep reading and draft creation. Remove sending. Max then prepares the message in Outlook and a person opens it and sends it. You lose nothing except the step you wanted a human on anyway.
Verify after using the durable lever
Ask Max to draft a message and confirm the draft appears in Outlook. Then ask it to send one and confirm it cannot. Both halves matter. A permission change that quietly breaks drafting is worth catching the same day you make it, not three weeks later when somebody works around it.
Also worth reviewing while you are in there. Calendar write access, file write access, and mailbox settings follow the same pattern and the same reasoning.
Surface 3
Other connections
on your organization.
- What they can do
- Every connection added to the QMax organization carries its own set of capabilities, and the same split applies: reading is one thing, writing and sending are another.
- Where the control lives
- The same place as the fast lever above. Each connection is listed, and each capability within it can be allowed, gated behind an approval, or blocked.
- Click path
- Claude → Settings → Organization settings → Connectors
What to look at
Not the count. Go through the list and, for each connection, ask one question: can anything here reach a person outside QMax? Sending, sharing, publishing, and posting are the words to look for. Reading is not the concern.
This is the surface that changes most. A connection added for a good reason on a Tuesday brings its write capabilities with it, set to whatever its defaults are. That is why the review below is worth having on a calendar rather than in someone's memory.
Surface 4
The QMax system
we built.
What it can do. Read across your connected business systems, and propose changes to them: vendor bills, bill date corrections, customer invoices, sales orders, and collections emails.
Where the control lives. In the system itself. This one is built rather than configured, which is the point of it.
- Reading is scoped by role, enforced on our servers. A person who is not cleared for a financial surface cannot read it through Max. The request is refused before any data is fetched. This is not the assistant being asked to behave. It is a check on our side that Max cannot route around.
- Writing is gated on a human click. Max can only ever propose. A proposal appears as a card. The component that performs the actual write is not available to Max at all. It runs when a cleared person clicks approve, and the approver is identified by their own sign-in rather than by anything the assistant supplies. Nobody can approve a change they are not cleared for, and Max cannot approve anything at all.
- Read clearance and approval clearance are separate. A person can be trusted with financial visibility without being handed the ability to approve financial changes. That separation is deliberate, and it is how the six people on your restricted-access list are handled.
- Writing can also be switched off wholesale, independently of everything above, per environment.
- Live state
- Ask us. Unlike the surfaces above this is not a settings screen you own, and we can tell you the posture of any environment at the time you ask.
What it does not cover
This gate governs the QMax system only. It has no visibility into the browser surface or the Microsoft connection. It was never intended to. The fact that it is the strongest control we run is exactly why it should not be mistaken for a control over the others.
Surface 5
Organization-wide
capabilities.
- What they can do
- Independent of any connection: searching and fetching from the web, and the standing instructions your organization gives the assistant.
- Where the control lives
- Claude → Settings → Organization settings
- Web search and web fetch can be enabled or disabled for the organization. Fetching reaches outward, so restricting it is a real boundary rather than a preference.
- A domain restriction list governs which sites can be reached. This is the right instrument for whole categories of site that should simply be out of reach, and it is worth revisiting whenever the answer to "what should Max never touch" changes.
- Organization instructions are standing guidance the assistant receives. Useful for shaping behavior and setting expectations. Worth being clear-eyed about what it is: guidance, not enforcement. Anything that must be guaranteed belongs in one of the layers above, where it is structural.
Summary
The control map.
| Surface | Who owns it | Where |
|---|---|---|
| Browser extension | Claude org admin | Org settings, browser extension section |
| Microsoft 365, fast lever | Claude org admin | Org settings → Connectors |
| Microsoft 365, durable lever | Microsoft directory admin (IT) | Entra → Enterprise applications → Permissions |
| Other connections | Claude org admin | Org settings → Connectors |
| The QMax system | Visionary, built in | Ask us for current posture |
| Web reach and org instructions | Claude org admin | Org settings |
Rows two and three are the ones to watch. On the Microsoft surface, the control you most want lives in a different console, owned by a different person, than the one you will naturally reach for first.
Where you already are
Two of three, done.
- Webmail is blocklisted for the browser extension. That closes the only path on this page where an action could reach a customer with no gate in front of it.
- The Microsoft 365 write and delete tools are switched off. Reading and drafting stay on.
The one left
Walk the connector list once, asking only whether anything on it can reach someone outside QMax. Ten minutes, and it is the review that stays accurate longest.
When we set up the Microsoft Graph connection, sending permission is granted in your Microsoft directory rather than in Claude — which is the durable version of the control you already applied on the Claude side.
Cadence
What to check,
and when.
After a change
Confirm both directions
After any change to a permission or a blocklist, check that what you intended to stop is stopped, and that what you intended to keep still works. A control that quietly disables something people depend on gets switched back off within a week, usually by someone who does not know why it was on.
On a new connection
Walk the list
When a new connection or capability is added, walk the list in surface 3 and ask the single question: can anything here reach someone outside QMax. That is also the trigger for us to update this document.
Quarterly
Review who holds what
Quarterly, or after any change to who does what at QMax, review who holds which role.
What we owe you
Telling you where a new surface can reach outside QMax is our job, not something you should have to ask for. As we connect systems and as the platform gains capabilities, this document gets updated and we flag anything that changes the answer to "what can leave the building."
If you add a connection or turn on a capability on your side, tell us and we will tell you what it opened.
The short version
Controls do not carry
across surfaces.
The browser surface is the one where an action can reach a customer without an approval step, and it is controlled in a different place from everything else. The strongest guarantees are the ones where the ability is removed rather than the permission declined, which is why the directory lever is worth using even though the Claude-side lever is faster.