Ask Your Org, and the case for scoping Claude yourself

Claude’s Ask Your Org is the kind of feature that demos beautifully. One project in your sidebar, connected to Slack, Microsoft 365, Google Drive, and more, and you can ask a plain-English question and get an answer drawn from across all of it. On a Team or Enterprise plan it is on by default, waiting for an owner to switch it on. The convenience is real.

The first question everyone asks about a feature like this is the security question, and Ask Your Org answers it well. It is permission-aware, so you only see results from data you already have access to in the source system. And Anthropic does not index your data; the answers come from live calls made when you ask. Those are good properties, and I want to credit them plainly before the rest of this post, because the rest of this post is not a security warning.

It is a different observation. Once the security question is answered, there is a second question that the convenience of Ask Your Org makes easy to skip. The question is not whether this is safe. It is how much Claude should be able to reach at once. That question is about scope, and it has a different answer for different work.

What Ask Your Org is

Ask Your Org is the user-facing half of a feature Anthropic calls enterprise search. On a Team or Enterprise plan it appears as a pre-configured project in the Claude sidebar, and an organization owner connects it to the company’s systems: Slack, Microsoft 365, and Google Workspace, with the option of custom connectors built on the Model Context Protocol. Once an owner has set it up and a user has authenticated to each connected app with their own credentials, anyone in the organization can ask a question and Claude searches across every connected source to answer it. Under the hood it works by making MCP calls to those systems in real time. There is no separate index, no copy of your data sitting in a new place. If you have read my piece on connectors, plugins, and skills, Ask Your Org is connectors assembled into a finished product: the wiring is done, the project is named, and the search is ready on day one.

The pull of that is obvious, and it is a real strength. Most knowledge work fails at the seams between systems, the answer that is half in Slack and half in a document nobody linked. A single project that searches all of it at once does close that gap. Nothing in this post is an argument against using Ask Your Org. It is an argument for noticing what kind of tool it is before it becomes the only one you reach for.

A couple of setup details are worth knowing before you turn it on. The owner who configures Ask Your Org has to choose a connector for both Documents and Chat; an Email connector is recommended but optional, so an organization can decide whether the model reaches into inboxes at all. And the feature works on Claude’s desktop app and on the web, but not on the mobile apps, so a workforce that lives on phones will find it unavailable where they spend much of their day. Neither is a dealbreaker. Both are the kind of thing better known before rollout than discovered after.

Permission-aware is not the whole question

Permission-aware is a precise promise, and it is worth being precise about what it does and does not cover. It covers the question, could Claude show me something I am not allowed to see. The answer is no: Ask Your Org inherits the permissions of each source system, so it cannot widen your access. What permission-aware does not cover is the question of scope. When you ask Ask Your Org a question, it can reach into every connected system at once, and a given answer may have been assembled from your Slack messages and your email and a few documents in Drive, with no particular record handed to you of which ones. That is not a permission failure. Everything it touched, you were allowed to touch. It is a visibility gap: the breadth that makes the feature convenient is the same breadth that makes it hard to reason about exactly what informed any single answer.

For a lot of questions, that does not matter at all. If you are asking what the team decided about the Q3 launch, you want Claude to look everywhere, and you do not need a list of sources. But for some work you do. If the answer is going into a board document, a contract, a regulated filing, you want to know precisely what it rests on, and “somewhere across five connected systems” is not precise enough. There is also the standing-exposure angle: a permanently connected Ask Your Org means the model can reach a large surface of company data at any time, which is a different posture from reaching only what a task needs. The same concern runs through how teams think about exposed assets across SharePoint and OneDrive. Convenience and a small reachable surface pull in opposite directions, and Ask Your Org sits firmly on the convenience side.

Make the scope point concrete. Picture a manager asking Ask Your Org to summarize a direct report’s performance for a review. The feature does exactly what it promises: it pulls from Slack and email and a set of shared documents, all permission-bounded, all data the manager could already open. Nothing improper happens. But the summary now rests on a blend of sources the manager never selected and cannot fully enumerate, and a performance review is precisely the kind of output that should rest on chosen evidence, not a convenient sweep. The tool did nothing wrong. It was just the wrong tool for a task where the provenance of the input matters as much as the answer.

The filesystem MCP alternative

The opposite of broad-and-automatic is narrow-and-explicit, and the cleanest example is a filesystem MCP server. MCP, the Model Context Protocol, is the open standard that lets Claude talk to outside tools and data, and a filesystem server is one of its reference implementations: a small server you run that gives Claude read access to a directory you name. You decide which folder. You decide whether it is read-only. Nothing outside that folder is in reach. When Claude answers using a filesystem MCP server, the scope is not a mystery. It is the directory you pointed it at, and you can open that directory and see exactly the set of files that could have informed the answer. It is more setup than Ask Your Org, which is pre-built and waiting. What the setup buys is a property Ask Your Org does not offer: a scope you chose deliberately and can see at a glance.

I lean on this pattern for any work where I need to reason about what the model saw. When a task is sensitive, or the output has to be defensible, I would rather spend ten minutes pointing a filesystem MCP server at a curated folder than ask a question against everything and hope the retrieval was sound. It is not that the broad search is wrong. It is that a narrow, named scope changes what I can say afterward. With a curated folder I can state, with confidence, the exact material the answer drew on. With a search across all connected systems I can state that it was permission-bounded, which is true and is not the same thing. For me the deciding factor is whether anyone will later ask what this was based on, and how exact the answer needs to be.

There is an operational dividend to that explicitness beyond traceability. A filesystem MCP server pointed at a curated folder means the curation step happens before the model runs, by a person, on purpose. Someone decided these twelve documents are the relevant ones and that one is out of date and excluded. That judgment matters, and it is a judgment Ask Your Org quietly makes for you, by retrieval heuristics, every time. Neither approach removes the judgment. The scoped approach moves it to a human, up front, where you can inspect it. The broad approach delegates it to the search, mid-query, where you cannot. Where that judgment lives is the real difference between the two.

When the broad tool wins

It would be a mistake to read all that as “always scope it yourself.” Ask Your Org wins, cleanly, for a whole class of work, and the class is large. Exploratory questions are its home ground: when you do not know where the answer lives, search everywhere is exactly right, and building a curated folder first would be absurd because finding the material is the task. Onboarding questions are another good fit, where a new hire asks the org’s combined knowledge something a dozen scattered documents half-answer. So is any quick, low-stakes lookup where a slightly fuzzy retrieval costs nothing. For all of those, the convenience is not a compromise. It is the right tool, and the setup cost of a scoped MCP server would be pure friction with no return. The breadth is a feature, and it is a feature you want most of the time.

There is also an adoption argument for the broad tool, and it is not trivial. A pre-built project that works on day one is a project people actually use. A scoped MCP server that each person must set up per task is a tool that, realistically, only the diligent will reach for, and a control nobody uses protects nothing. So Ask Your Org earns its place partly by being frictionless: it makes the safe-enough option the easy option, and for the broad, exploratory majority of questions, easy and safe-enough is the right combination. The scoped tool is the specialist instrument, not the everyday one.

So the working rule is about stakes and traceability, not about which tool is better in the abstract. Reach for Ask Your Org when the question is exploratory and the answer does not need a paper trail. Reach for a scoped MCP server when the output has to be defensible, or the input is sensitive enough that you want to choose it by hand. Most organizations will use both, and the maturity is in knowing which is which, the same judgment that goes into organizing SharePoint and OneDrive for AI well. If you want help drawing that line for your own teams and data, reach out.

A control-first approach to org knowledge

Step back and a principle emerges, one worth holding beyond this single feature. The default instinct with AI and company knowledge is to maximize what the model can reach, on the theory that more access means better answers. A control-first approach inverts that. It treats the reachable surface as something to set deliberately, matched to the task, rather than maximized once and left on. Ask Your Org and a filesystem MCP server are both fine tools under that approach. What changes is that you choose between them on purpose. The control-first question is not how do I connect Claude to everything. It is, for this task, what is the smallest set of knowledge that does the job, and can I see it. Asked that way, the broad tool and the scoped tool each have an obvious home, and neither becomes the lazy default that the other should have been.

Where does this go? My read is that the scoped, explicit pattern grows in importance as AI moves further into work that has consequences. The broad search is the right starting point, and it will stay useful forever for exploration. But as more output flows through models into documents that get signed, filed, and relied on, the ability to say exactly what an answer was built from stops being a nicety and becomes a requirement. The organizations that handle that well will not be the ones that connected Claude to the most systems. They will be the ones that kept the habit of choosing scope, and built the muscle for it early, while the questions were still low-stakes enough that getting it slightly wrong cost nothing.