# Choose MCP Scopes with Least Privilege: A Caroush Example [Read the original article]() By Garry · Founder Published: 2026-09-29T20:05:07.450Z Updated: 2026-09-29T20:13:22Z 6 min read Categories: Social media tools Map Caroush tool permissions to real tasks, separate reading from creation and publishing, and review access as responsibilities change. ![One fitted key and several closed apertures illustrating minimum necessary access.]() ## Key takeaways - Start with a bounded task before selecting permission scopes. - Scope, workspace ownership, plan eligibility, and action approval are separate checks. - Verify intended operations and confirm unrelated capabilities remain unavailable. The easiest way to make a permission error disappear is sometimes to grant more access. It is also an easy way to give an AI connection authority that has little to do with the task. Least privilege starts from a better question: what is the smallest set of operations this workflow genuinely needs? For MCP, scopes describe categories of delegated access, while the server's tool catalog shows the operations that depend on them. Caroush documents separate scopes for reading context, creating content, generating assets, requesting publication, and managing other workspace functions. Use those distinctions to design a connection deliberately instead of treating the consent screen as an all-or-nothing installation step. ## Write the task before choosing the grant Begin with a concrete outcome. “Prepare one text draft from an approved product brief” is a useful task. “Manage our social media” is too broad to map responsibly to permissions because it can include reading, creating, publishing, deleting, reporting, and automation. List the information the assistant must retrieve and the object it must create. If all product facts are supplied in the brief, the workflow may not require every read capability available in the service. If the agent must confirm the workspace, it needs the relevant context operation. The [MCP authorization specification]() describes scope selection and handling insufficient access. Its protocol behavior supports a more specific grant; it does not decide your organization's business need for each permission. Connect permission design to the [AI content workflow]() you actually plan to run. An unused capability is not a benefit merely because it appears in a longer integration checklist. ## Map operations to the catalog's documented scopes Caroush's [tool reference]() associates tools with required scopes. For example, creating a text draft belongs to create:content. Reading the selected workspace and reading existing content are different capabilities. Publishing and scheduling have their own documented permissions and approvals. Build the mapping from the current catalog rather than inferring it from a tool name. Some operations may require ownership conditions or plan eligibility in addition to the scope. A scope is necessary authorization information, not a promise that every object and argument will be accepted. For a draft-only connection, the absence of a publishing tool can be a deliberate success condition. If the workflow never needs deletion, do not grant deletion to avoid a hypothetical future interruption. When the task changes, review the grant then. The [OWASP excessive-agency guidance]() recommends minimizing both tool functionality and permissions. It also emphasizes enforcement in downstream systems rather than asking the language model to decide whether access should be allowed. ## Separate creation from external consequences A draft operation changes the workspace, but it does not have the same consequence as publishing to a connected account. Treat that distinction as an opportunity to create a useful preparation role. An assistant can help turn an approved brief into a reviewable draft while a person retains responsibility for deciding when and where it appears. Caroush's documented publishing and scheduling operations require browser approval. That approval is an additional boundary, not a reason to grant every connection publication scope by default. Suppose a freelance writer prepares product captions for a store. The writer's assistant may need to save drafts, but the store owner handles the [publishing schedule](). Keeping those responsibilities separate reduces the number of connections with publication-request authority. If the writer later takes on scheduling preparation, review the changed responsibility explicitly. The new permission should follow a real assignment and a visible approval path, not accumulate silently because the client offers an “allow all” option. ## Read access also deserves a purpose Least privilege is not only about preventing writes. Reading private drafts, product records, or analytics can expose information outside the immediate task. A connection that cannot publish may still reveal unreleased offers or confidential client strategy to the assistant's processing environment. Ask which records are needed and why. An assistant reviewing one draft may not need the entire content history. A caption task may not need saved analytics. In Caroush, saved analytics access also depends on the documented Pro plan requirement, so permission and eligibility need separate consideration. This distinction helps maintain a focused [content audit](). A human audit may examine broad evidence over time; an individual generation request can often use a much narrower, reviewed context bundle. Do not confuse a read-only label with an absence of data-handling obligations. Limit retrieval to the task and follow the organization's rules for sensitive material. Keep private response bodies out of public debugging notes and copied configuration examples. ## Handle missing scopes as a reviewable decision When an operation fails because a scope is absent, first confirm that the operation is actually required. An assistant can choose a tool that is broader than the user's intended outcome, especially when the instruction is ambiguous. If the task genuinely requires the capability, explain the missing operation and update access through the documented authorization flow. If it does not, adjust the workflow to use permitted operations or a manual handoff. Do not repeatedly widen the grant until an unclear request happens to succeed. A useful failure message would identify the requested action and its missing permission without exposing tokens or unrelated workspace data. A useful human response would decide whether that action belongs in the connection's purpose. For a team, record permission changes beside role changes. If a connection moves from draft preparation to automation management, revisit who owns it, who reviews its actions, and when the grant should be removed. Your [approval process]() should reflect that expanded responsibility. ## Verify both what works and what remains unavailable A least-privilege test has two sides. Confirm that the intended operation succeeds under the chosen grant. Then confirm that unrelated consequential operations are not exposed or are denied according to the service's contract. Use controlled test artifacts and avoid live publication as a permission probe. A read operation can establish context; an authorized draft test can establish creation behavior. A denied action should remain denied even if the prompt strongly asks the assistant to proceed. Review the grant after the pilot. Remove capabilities that were requested for exploration but never used in the actual workflow. Temporary setup convenience should not become permanent standing access through neglect. The final connection should have a short explanation: it belongs to this user, operates in this workspace, and supports these tasks. That explanation gives editors and maintainers a shared basis for evaluating changes. Least privilege is not about making every task difficult; it is about ensuring that useful access stays aligned with a real purpose as the workflow grows. For a quarterly review, compare the connection's permissions with three recent real tasks. Identify the operations each task used, then mark capabilities with no current business reason. Lack of recent use is a prompt for review, not automatic proof that a permission is unnecessary; a rare recovery task may be legitimate. Ask the owner to explain that exception and document it. This evidence-based review is stronger than shrinking or expanding access mechanically. It also makes a future handoff easier because the next owner can understand why an unusual capability was retained instead of assuming every existing grant was carefully designed. A useful permission request names the next task and its expected result. “Allow draft creation so this connection can save the approved caption” is reviewable. “Enable everything for better results” is not. Require that same clarity when removing a restriction after a failed request, because the error may reveal an unnecessary operation rather than a legitimate access gap. Generation permissions also deserve specific review. A task that creates text drafts does not automatically need carousel generation or automation management. These capabilities can introduce credit consumption and additional objects even before publication. Include those effects in the permission decision, so least privilege covers cost and operational complexity as well as public changes. ## Sources - [Authorization - Model Context Protocol]() - [LLM06:2025 Excessive Agency - OWASP Gen AI Security Project]() - [Caroush MCP quickstart and implementation boundaries]() ## Frequently asked questions ### Should I grant every scope during setup? No. Map the actual task to documented tools and scopes. Add permissions later when a real responsibility requires them, using the supported authorization flow. ### Does draft creation require publication authority? They are different capabilities. Caroush’s draft creation tools do not publish, while publication and scheduling have separate scopes and browser approval requirements. ### Is read access harmless? No. Reading can expose private drafts, unreleased product details, or other business information. Limit retrieval to what the task needs and handle results appropriately. ### How often should a grant be reviewed? Review when roles or workflows change, when a pilot ends, and on a regular ownership check. Compare permissions with actual tasks and document legitimate exceptions. ## About the author Garry Gaurav Sapkota builds Caroush, a workspace for creating, scheduling, and publishing social content. - [https://x.com/gauravsapkotanp]()