GuidesTeam Access Controls

Enterprise

Team Access Controls

Cap individual team members to read-only access across every MCP. The cap is set once by the team owner and applies to every API token and OAuth session that member creates — so contractors and analysts can use Pipeboard without the risk of accidental writes.

Available on the Enterprise plan.

One switch. Every MCP. Every token.

Team Access Controls live above per-token permissions. When you set a member to read-only, the cap is enforced server-side on every MCP call — no matter which token, OAuth session, or MCP server the member uses.

Covers every MCP

Meta Ads, Google Ads, LinkedIn Ads, Reddit Ads, Snap Ads, TikTok Ads, plus internal MCPs. One cap, all servers.

Survives token rotation

If a member regenerates their API tokens, the cap still applies. There is no way to escape it short of the owner lifting it.

Per-member, not per-role

Cap Jack but leave Maria on write. Owners are always write; admins and members can be capped.

Read-only members

What a read-only member can do

Anything that views data. Nothing that mutates it. Classification is consistent across every MCP — based on the tool name, not opinions per server.

Allowed

List ad accounts, campaigns, ad sets, ads, audiences, assets
Pull insights and performance metrics
Search campaigns by name, status, date range
View creatives, page details, account activities
Run GAQL queries on Google Ads (read-only)
Generate and download reports
Estimate audience sizes and resolve account info

In code: get_*, list_*, search_*, query_*, check_*, estimate_*, bulk_get_*

Blocked

Create or duplicate campaigns, ad sets, ads, creatives
Update budgets, bids, targeting, ad copy
Pause, resume, enable, or disable campaigns
Upload images or videos
Delete or archive anything
Bulk write operations (bulk_update_*, bulk_create_*)
Arbitrary mutate calls (execute_google_ads_mutate, etc.)

In code: create_*, update_*, delete_*, pause_*, duplicate_*, upload_*, bulk_update_*

When a read-only member calls a write tool, Pipeboard returns a structured permission_denied error with the message “your team owner has restricted this account to read-only MCP access”. The call never reaches the ad platform — and it does not count against your team's execution usage.

How to set it up

A dropdown next to each team member in Settings → Team. Takes a single click.

Open Settings → Team

You must be the team owner or a team admin to manage member access.

Change the access dropdown

Next to each accepted member, pick Write or Read-only. Owners cannot be capped — their dropdown is disabled.

Member sees the cap immediately

Their next MCP call is restricted. tools/list in their MCP client also filters write tools out so the UI matches what is callable.

New invitees default to read-only

On Enterprise teams, anyone you invite from this point forward starts read-only. Flip them to write whenever you are ready to extend trust.

Layered with token permissions

How it composes with API token permissions

Team Access Controls sit above per-token permissions. The effective access for any call is the intersection of both. The team cap wins whenever the two disagree.

Scenario	Team cap	Token scope	Effective
Default member, full token	Write	All tools	Full access
Capped member, full token	Read-only	All tools	Read-only
Capped member, write-only token	Read-only	create_ad, update_campaign…	Read-only (write tools blocked)
Default member, read-only token	Write	get_, list_	Read-only (from token)

Team caps vs. token scopes — which one do you want?

Use Team Access Controls when…

You want a per-person cap that survives token rotation.
Contractors and analysts should never write, no matter what.
You want a single owner-controlled switch instead of auditing every token your team creates.
You need this across every MCP at once.

Use per-token permissions when…

You need finer slices than read/write (e.g. a token that can update_campaign but not create_ad).
An automation (n8n, scripts, reporting bot) needs a narrow scope but is not tied to a human teammate.
You want to restrict by ad account (Enterprise) in addition to by tool.

They compose well. Most teams use Team Access Controls as the floor for human users and per-token permissions to harden automation and bots.

Edge cases

What happens to existing members when I turn this on?

Nothing — existing members keep Write access. The Enterprise read-only default only applies to invitees from the moment you upgrade to Enterprise onward. You can downgrade existing members manually from the team settings page.

Can I cap the team owner?

No. The owner always has Write access. If you need a strict-read seat for yourself, create a second team member account and cap that one.

Does the cap apply to OAuth (web chat) sessions too?

Yes. The cap is keyed to the user, not the credential. Web OAuth sessions and API tokens are both restricted the same way.

Is there a delay after I change the cap?

No more than 30 seconds. We cache effective access in-process for that long to keep tool calls fast. After the cache expires, the new cap is picked up on the next call.

Can a capped member see write tools at all?

Their MCP client's tools/list response filters out write tools, so the UI only shows what is callable. If their client caches tools/list aggressively, restarting it refreshes the view.

What about denied calls — do they count against my usage?

No. The cap is enforced before usage tracking, so denied calls do not consume your team’s execution quota.

How do I audit denied calls?

Every denial emits a structured server log and a PostHog "mcp_access_denied" event with the team_id, user_id, tool_name, and mcp_server. Filter logs by event=*_team_access_denied to see them.

Ready to scale your team safely?

Team Access Controls are part of the Enterprise plan. Upgrade to invite analysts and contractors with read-only access by default.