Manage a risk policy audience

If this connection lists call_platform_tool instead of the tools this workflow names, find each named tool with search_platform_tools, describe it with describe_platform_tool, then run it with call_platform_tool and the same arguments. Whether a tool exists for you is decided by describe_platform_tool with its exact name, not by tools/list or one page of search results: a name returned in not_found is unavailable to you, so say so rather than guess. The call itself still checks your access. When execute is also listed, a multi-step read may run in execute with tools.search, tools.describe and tools.call on platform--<tool name> paths. End each execute run at a confirmation point and ask the user before any write.

Use the executing client's authenticated Platform MCP connection. Installing this skill grants no authority. Live membership, organization-admin permission, explicit-project authorization, and the risk-mutation rollout remain authoritative. Never request credentials or use another client's identity.

Inspect and confirm the exact target

1. Call list_projects through this client's connection. Ask the user to choose the exact project slug. If discovery is incomplete or the requested project is unavailable, stop; never substitute Default or another project.
2. Call list_risk_policies for that project and ask the user to select the exact policy. Names are not unique: retain the returned policy ID rather than guessing from a name. Follow pagination for discovery, or accept an exact user-supplied policy ID and verify it directly.
3. Call get_risk_policy for the exact project and policy. Inspect its current audience, compatibility, and opaque version. Keep principal URNs, policy IDs, versions, and idempotency keys as internal tool arguments rather than displaying them as user instructions. A policy audience is a set of positive user/role grants, not a list of exceptions or proof of effective membership.

Remove the authenticated requester

For “remove me,” explain that self-removal and effective exclusion are unavailable pending organization-scoped coordination of audience grants. remove_self_from_risk_policy remains discoverable to external organization administrators but always refuses before database transactions or receipt replay. Do not claim that deleting a positive user grant proves the requester is no longer covered.

Stop without writing. Do not bypass this refusal with change_risk_policy_audience, general audience replacement, policy disablement, role or membership changes, a risk exclusion, or reconstruction of Everyone as today's member list. Never infer a human from managed-assistant attribution. A separately requested administrator change to direct positive grants is a different outcome, not a workaround for self-exclusion.

Add or remove direct audience grants