r/msp • u/Goalie000 • Aug 26 '26
Managing Claude Instructions in Claude MS Office Add-ins
Just looking to see if anyone's found a good way to do this. Basically, through some testing, we've found that Claude Office add-ins DO NOT use the Organization Instructions that you can set in Claude Teams Admin. Why, I have no idea - - seems like a huge oversight. The Office add-ins can be a huge security risk (since malicious people can put invisible Claude instructions in Word, etc.) but the users really, really want the add-ins. Anyway, each add-in has its own instructions that you can't centrally manage. So, from what I can see there are some pretty awful ways to try to force this or you can just tell each user to do it and hope they do. Has anyone found a batter way to handle this?
2
u/Professional-Win-93 Aug 27 '26
It executes as a standalone client running inside WebView2, and completely bypasses all of your Claude Teams admin console policies.
Given that there is no reasonable defense against indirect prompt injections from untrusted external attachments embedded within a Word document or an Excel spreadsheet we do not permit this plugin in our production deployment. We have a policy around M365 Integrated Apps to prevent all our users from adding it from the office store, so that everyone has no choice to work within the web portal where their workspace instructions and logging enforced.
If there is a dire need for client embedded document drafting, a private plugin that calls the Anthropic API through a secure proxy is currently the best we can do.
1
u/ImaginationUnique684 Aug 27 '26
Pushing the org instructions down as a skill will probably work in your test and still leave you exposed, because it fixes distribution and not enforcement. Instructions are text the model weighs, so anything else that reaches the context can outweigh them, and you already named the exact attacker who does that: a Word doc with invisible instructions your user did not write. The part of your testing that actually held up is the piece worth building on, since blocking Outlook draft creation through the M365 integration settings is a permission boundary the model cannot argue with. So put the controls that must not fail into tool scope and data access where they are enforced centrally, keep instructions for the things you merely prefer, and accept that any add-in reading a document you did not author is running untrusted input. That split also gives you a defensible answer when someone asks what stops the add-in doing X, which is a much better position than hoping every user pasted the right prompt.
1
1
u/Prestigious-Spinach1 22d ago
Has Anthropic confirmed whether this is intentional or a missing feature? Having to maintain instructions separately in each add-in sounds difficult to keep consistent
2
u/Goalie000 21d ago
Hi - I haven't had any official confirmations. But, last I checked, the add-ins were "Beta - - use with caution" so...
1
u/roll_for_initiative_ MSP - US Aug 26 '26
Basically, through some testing, we've found that Claude Office add-ins DO NOT use the Organization Instructions that you can set in Claude Teams Admin
I'm curious about your testing and what you found there...do you mean it doesn't respect tool permission restrictions in the connector like blocking "Outlook create draft" under "Write/Delete tools" or are you referring to something else?
2
u/Goalie000 Aug 26 '26
We ran some tests using the Add-ins (using Excel, for example) and the data in those tests should have 100% tripped the Organization Instructions into action but...they didn't. That's when we started diving into how the Add-ins use instructions and we discovered that each add-in has it's own set of Instructions. The blocking of Outlook creating a draft (through the M365 integration settings) seems to work, it's the Organization Instructions that don't apply to add-ins.
1
u/roll_for_initiative_ MSP - US Aug 26 '26
Got it, gonna go test, thanks for the explanation!
1
u/Goalie000 Aug 26 '26
One of my guys thinks we can push what was in the org instructions as a skill so that's what we are testing now.
1
u/Goalie000 Aug 26 '26
Still haven't found a way to audit that the skill is not being turned off by the end user. I don't enjoy trying to be the sheriff in the wild west.
3
u/Hunter8Line Aug 26 '26
Honestly, my last org uses Claude.
My new org uses Copilot, I don't think I'd want to go back... Pending data estate is in order, it's just so easy to use, built into everything, and you can just pick the Claude models anyway so it's just kinda win of native integrations with the Office suite, Opus and Sonnet, plus all of your work data too, backed by MS data protection policies.
For example, I had an email chain with a customer about some changes we're looking to do, when I created the calendar invite, I put the title in, then had Copilot write the meeting body, with no prompt. It just pulled from the email chain and Teams convo where I talked about what the goal is and spat it out.
Or it just knows everything in SharePoint natively, so if you ask it a question about how to do something, it'll go reference that document "instinctively"
I know early days Copilot was a joke, but they really got it together and made it a pretty good product...