How to Block Restricted Projects from Asana MCP
Project managers want Asana connected to Claude so they can pull task updates, check timelines, and draft status reports without switching tabs. The same workspace also holds board-level initiatives, HR restructuring plans, and M&A due diligence. Once the Asana MCP server is connected, an agent can reach every one of those projects that its user can see, and Asana offers no project-level way to treat the agent differently from the person.
This guide covers where Asana’s native controls stop and how a custom rule engine on MCP Manager’s gateway blocks restricted Asana projects for AI agents, while every person’s Asana access stays unchanged.
Key Takeaways
- Asana’s V2 MCP server acts as the authorizing user, uses no OAuth scopes, and has no project-level setting.
- Asana’s admin controls decide which MCP clients and workspaces can connect, not which projects an agent reads.
- A custom rule engine on MCP Manager’s gateway inspects each tool call and result and blocks or filters restricted project GIDs.
- Blocking takes two rules: one on the request leg for calls that name a target, one on the response leg for search and list results.
- The request-leg rule also enables read-only access per project, which Asana’s MCP tokens cannot express.
- The engine is code the team builds, hosts, and maintains; every verdict lands in MCP Manager’s audit logs.
Asana MCP Reaches Every Project a User Can See
Asana states that its MCP token doesn’t grant any permissions beyond what the user already has, and every action over MCP appears as the user who authorized it. MCP apps in Asana also do not use permission scopes, so an authorization covers every available tool. That floor is also the ceiling. Every project a user can open is a project their agent can read and act on.
The difference is intent. A person opens the HR restructuring project on purpose. An agent asked “what’s overdue across my work?” calls search_tasks, search_objects, or get_status_overview, which runs its own keyword search across projects and portfolios. Task descriptions and comments are untrusted text the model processes, so an instruction planted in a task can steer the agent through indirect prompt injection, without any vulnerability in Asana.
Human access is not agent access, yet the usual fixes treat them as one: remove the person from the project and break their job, or leave Asana MCP disconnected for everyone.
What Native Asana Controls Can and Cannot Do
Asana gives admins real MCP controls, and a rollout should use them first:
- App management: on Enterprise+ and Legacy Enterprise tiers, admins can allow or block each AI client’s app, which decides which tools may connect to the Asana MCP server at all.
- Workspace distribution: a registered MCP app can be limited to specific workspaces under Manage distribution.
- Workspace-scoped tokens: each authorization is tied to the one workspace selected at consent.
- Project privacy: settings such as private to members decide which people see a project.
None of these excludes a project, team, or portfolio from MCP, and none makes MCP read-only, because there are no scopes to narrow. Project privacy stops non-members, but a member’s agent reads a private project like any other.
Scoping at the source is the other option: a service account added only to the intended projects limits what the agent can reach, but Asana then attributes every action to that account, and one account cannot vary boundaries per team. Where per-user identity matters, an MCP gateway rule adds the agent-only boundary on top.
What a Custom Rule Engine Adds to an MCP Gateway
An MCP gateway sits between an AI client such as Claude and Asana’s MCP server, calls Asana as each person’s own authorized user, and applies gateway rules to every Asana tool call. Built-in rules match values by shape or context, such as regex for structured identifiers like Social Security numbers, and Microsoft Presidio for personal data such as email addresses in task descriptions and comments. Neither knows what an Asana project is.
A custom rule engine fills that gap:
- What it is: an HTTPS webhook the team builds and hosts, called by the gateway on each tool call.
- What it decides: pass, modify, block, or error, applied before the message moves on.
- What it sees: the full JSON-RPC body, the tool name, and the calling user’s identity.
- Where it applies: only to the gateways it is attached to, so different teams can get different rules.
The person’s own Asana session never passes through the gateway, so their access stays unchanged.
How a Rule Engine Sees Asana MCP Traffic
Asana’s server lives at https://mcp.asana.com/v2/mcp. On each tools/call, the engine receives the JSON-RPC body plus metadata such as serverGuid, toolName, userEmail, and direction, on the request leg, the response leg, or both.
Asana’s V2 server exposes each operation as its own tool, so toolName names the real operation, such as create_tasks or get_task. Under the 2026-07-28 MCP spec, the tool name also travels in the Mcp-Name HTTP header. Neither identifies the project. The GID sits in params.arguments on the request and in the result on the response.
Two protocol details shape the parser:
- Two result representations: the tools specification says a tool returning
structuredContentshould also return the serialized JSON in a text content block. A modify verdict that rewrites one but not the other still leaks restricted data. - Tools only: gateway rules inspect
tools/calltraffic, not prompts or resources.
How to Block Asana Projects from AI Agents Step by Step
Blocking Asana projects takes one custom rule engine, attached to the gateway through two rules: one on the request leg for calls that name a target, and one on the response leg for search and list results. The steps below cover the setup in the order it should be done, from collecting project GIDs to rolling out beyond the pilot team.
Step 1: List the Restricted Project GIDs
Collect the GID of every project to protect, since GIDs survive renames. The project GID is the numeric ID shown in the project’s own URL. Links copied from a task can omit the project. Where the GID is unknown, Asana’s MCP tools reference names search_objects as the first step.
Teams and portfolios need expansion. Each project belongs to a single team, but tasks reference projects, not teams. To block a team, resolve it to project GIDs with get_projects filtered by team, and resync on a schedule so new projects are covered. get_items_for_portfolio does the same for a portfolio.
A blocklist is simpler when a handful of projects are sensitive. An allowlist fails closed, so a new project stays out of reach until approved. Either list belongs in a configuration file or environment variable, not in code.
Step 2: Connect the Asana MCP Server
Asana only accepts MCP connections from an app that is registered in advance, so the setup starts in MCP Manager and moves to Asana and back:
- Start in MCP Manager. On the Servers page, add a server, paste
https://mcp.asana.com/v2/mcp, and click Continue. MCP Manager recognizes that Asana needs a registered app and shows its callback URL. - Register the app in Asana. In Asana’s developer console, create a new app and choose “MCP app” as the type, because standard API apps cannot connect to the MCP server. Paste the callback URL as the redirect URL, then copy the Client ID and Client Secret.
- Finish in MCP Manager. Enter the Client ID and Client Secret and save the server. The Client Secret should be handled like a password.
After setup, each user approves Asana’s consent screen once, and every call from then on runs as that person.
Need the full walkthrough? The Connect Asana guide covers every field, the common pitfalls, and what to do when a connection stops working.
Step 3: Create the Gateway and Assign Asana
In MCP Manager, a gateway is created for one audience, such as product and engineering, and the Asana server is assigned to it with a per-user identity scheme. Every call then runs as the person who authorized it, and the engine sees who is calling.
Rules, the tool allowlist, and the identity scheme all live on the gateway, which makes it the smallest unit of governance. Audiences with different project boundaries get separate gateways. A newly assigned server defaults to Allowing all tools, and nobody can connect until the gateway is provisioned to a team.
Step 4: Trim the Tool Surface with Feature Provisioning
On the gateway’s Asana server, feature provisioning set to “Allow if conditions are met” exposes only allowlisted tools and keeps new or renamed ones hidden. This matters because Asana authorizations also cover tools added later.
Three choices are worth making:
- Leave
delete_taskoff unless needed. It deletes permanently, including subtasks not homed in another project. - Decide on
get_status_overview. It aggregates statuses, task summaries, and blockers from its own internal search, the hardest output to filter. - Decide on
get_attachments. It returns download URLs, so the file itself never passes through the gateway for inspection.
Pin tools by name and description, so a changed description stops passing until reviewed. Set prompts and resources to Blocking all unless the gateway needs them.
Step 5: Write the Request-Leg Logic
The request rule fires before a call reaches Asana. It covers tools whose arguments name a project: get_project, get_tasks with a project filter, create_tasks into a project, update_tasks that changes project membership, and create_project_status_update. Argument names should come from the live tools/list response, which Asana calls the authoritative source.
Write tools such as add_comment and delete_task name only a task GID, and update_tasks identifies its tasks the same way, even when it also names a project. The engine therefore looks up each task’s projects through Asana’s REST API with a separate credential, since Asana’s MCP tokens work only with the MCP server. That credential can read the restricted projects and belongs in the security review. A failed lookup blocks the call, and hiding these write tools with feature provisioning avoids the credential altogether.
This leg is also where read-only access lives. Blocking write tools for a project while its reads pass lets agents summarize the roadmap without commenting on, reassigning, or completing its tasks. A call that should name a target but doesn’t is blocked too.
Step 6: Write the Response-Leg Logic
search_tasks, search_objects, get_my_tasks, get_tasks filtered by assignee, get_projects, and get_items_for_portfolio take no project argument and return items from every project the user can see, including the projects inside a portfolio. The response rule removes restricted items with a modify verdict, so legitimate results still arrive. MCP Manager’s allowlist recipe shows example handlers for both legs as an instructional starting point.
Asana’s data model adds cases the recipe doesn’t cover:
- Multi-homed tasks: a task can belong to several projects, listed in its
membershipsfield. Decide whether one restricted membership blocks the whole task. - Subtasks: subtasks do not inherit their parent’s projects and can nest five levels deep. A subtask under a restricted task can arrive with no memberships, so the engine checks its parent chain.
- Embedded references:
get_taskreturns subtasks, dependencies, and comments, so a permitted task can reference restricted work. - Counts and unparseable results: totals are rewritten to match the filtered list, and a covered result that can’t be parsed is blocked.
Step 7: Deploy and Register the Engine
The engine needs a public HTTPS endpoint with a public CA certificate, HTTP 200 for every verdict, responses well under the 30-second timeout, and idempotent handling, because failed attempts are retried. Calls are authenticated with a static header, and MCP Manager’s static outbound IP can be allowlisted.
Register the engine under Rule Engines with the Custom provider, the endpoint URL, and the authentication header. The built-in Test action previews its verdict and latency before it is attached to any gateway.
Step 8: Add the Rules to the Gateway
On the gateway’s Rules tab, a rule is added with the engine as its detection method. Two rules are needed, one with the request hook and one with the response hook. The engine tells the legs apart by the body: a request carries params.arguments, and a response carries result or error.
- Failure mode: leave it at Block.
- Alerts: turn them on during the pilot, so every block or rewrite raises a real-time alert.
- Order: rules run in order within each hook, and a block stops processing, so block rules go above any Presidio or regex rules.
Troubleshooting tip: if restricted projects still reach agents, check the Rules tab. A registered engine filters nothing until a gateway rule references it.
Step 9: Test with a Pilot Team
Create a team with two or three administrators and provision the gateway to it. In the AI client the team uses, such as Claude, ChatGPT, or Cursor, add the gateway URL as a custom connector or MCP server and authorize Asana once when prompted. Then run each of these paths:
- Fetch a restricted project by GID.
- Search across restricted and permitted projects.
- List “my tasks” while assigned a subtask under a restricted task.
- Read a task multi-homed in a restricted and a permitted project.
- Comment on a task in a read-only project.
Confirm each verdict in the logs: blocks appear as policy_enforced_abort, rewrites as policy_enforced_mutation, and the engine’s comment names the project and tool. Requests are logged before request-leg rules run, and OpenTelemetry export is not filtered by rules, so storage and export settings should match these projects’ sensitivity. Widen access only after every path behaves as intended.
Step 10: Roll Out and Maintain
Once every path behaves as intended, provision the gateway to the broader teams, with alerts left on for the first weeks.
Gateway rules only see gateway traffic, while Asana’s own apps in Claude and ChatGPT connect to the same server directly. On Enterprise+ tiers, app management can block those apps and keep MCP Manager’s registered app allowed.
Need to close every route around the gateway? Follow the MCP Enterprise Lockdown Checklist for the client-side controls.
Re-test the rules whenever Asana’s tool list changes, and subscribe to its developer changelog for update notifications. Asana says new tools can be added, updated, or deprecated at any time.
Building Your Own Engine vs. Waiting for a Managed One
The Google Drive Folder Blocker is a managed engine: MCP Manager hosts the logic, and an admin supplies folder IDs without writing code. An Asana project blocker is a custom engine your team writes, hosts, and maintains. Four ownership points should be settled before the build:
- Maintenance: new Asana tools reach existing authorizations, so someone checks whether each needs parsing.
- Security review: InfoSec will ask how coverage is shown. Test cases, captured payloads, and logs are the evidence.
- Operations: the engine sits in the path of every Asana call. With failure mode Block, an outage pauses Asana MCP until it recovers.
- Credentials: the REST credential from Step 5 needs an owner and a rotation schedule.
A coding agent can draft most of the engine from the MCP Manager docs for agents, and the custom rule engine tutorial covers registration end to end.
Need a managed Asana engine, or help scoping the custom one? Book a consultation with MCP Manager to talk through project-level blocking for Asana.
Typical Scenarios for Blocking Asana Projects
Rules, tool allowlists, and identity schemes all sit on the gateway, so the same Asana engine can enforce different boundaries for different audiences. Three patterns cover most setups.
- Different boundaries per department: the gateway is the smallest unit of governance. The executive gateway blocks the HR project; the product gateway blocks HR, finance, and strategic planning.
- Read-only roadmap: agents draft status summaries from the roadmap project, while write tools targeting it are blocked.
- Personal data in permitted projects: a Microsoft Presidio rule set to Replace turns detected entities into tags such as
<EMAIL_ADDRESS>. Presidio is less reliable for names in free text, so regex rules or AWS Bedrock Guardrails cover the gaps.
Ship the Asana MCP Connection Without Exposing Restricted Projects
Blocking restricted projects does not require blocking the Asana MCP server. Asana’s permissions decide what a person may see, and its admin controls decide which clients connect. A custom rule engine on MCP Manager’s gateway adds per-project, per-team, and per-operation boundaries for agents only. The engine is code with real upkeep, so it should be tested against captured payloads before anyone connects.
The result is an Asana connection that agents can use for everyday work, while the projects that were never meant for them stay out of reach.
FAQ
Can I block Asana projects without a custom rule engine?
Not with per-user identity and project granularity. Feature provisioning can hide a tool such as search_tasks, that hides it for every project. A shared service account scopes at the source, but Asana then attributes every action to that account.
Does the Asana MCP server support OAuth or personal access tokens?
The V2 server uses OAuth 2.1 with PKCE and requires a pre-registered MCP app. Tokens from standard API apps cannot connect to mcp.asana.com, and MCP tokens cannot call the REST API. MCP Manager runs the flow per user and refreshes Asana’s one-hour access tokens automatically.
Will blocking a project change anyone’s Asana access or project membership?
No. The rule only changes what agents receive through the gateway. Membership, privacy settings, and the Asana apps stay untouched.
Can agents read an Asana project but not change it?
Yes, as a policy choice. A request-leg rule blocks write tools that target the project while read tools pass. Asana’s own MCP authorization has no scopes to express this.
How do I know if the rule is working?
MCP Manager logs every tool call and rule verdict with the engine’s comment, and can forward logs and traces over OpenTelemetry to platforms such as Datadog or Grafana Cloud.
Can I apply different Asana rules to different teams?
Yes, through separate gateways, each with its own rules and tool allowlist, provisioned to the teams that need it.
What happens if my custom rule endpoint goes down?
The rule’s failure mode decides. For custom engines it defaults to Block, so an unreachable, slow, or invalid engine stops the call instead of passing it. Setting it to Allow trades protection for availability.
Is there a managed Asana project blocker?
Not yet. MCP Manager offers a managed engine for Google Drive folders, where an admin pastes folder IDs into the UI, but Asana projects currently need a custom rule engine. Teams that need a managed option can raise it with MCP Manager.
Can I combine project blocking with PII filtering?
Yes. One gateway can run the project engine, Presidio or regex rules, and AWS Bedrock Guardrails. Rules run in order within each leg, and a block stops processing, so block rules go first.
