Understanding policies

Separate permission from execution

A policy decision answers whether the proposed action may proceed under the current access rules. It does not state that the provider completed the action. Keep identity checks, the decision, any independent approval, and the execution outcome separate when reading an activity record.

This distinction matters during diagnosis. An allowed read can fail because a provider is unavailable. An approval-required request has not executed. A denied request must be investigated at the failed authorization check before retrying, and an uncertain dispatched write needs an outcome check before another attempt.

How policies work

Every request must pass current membership, team and personal access, credential readiness, environment, reviewed tool, resource, and inspection checks. Reviewed reads can then proceed; writes follow the configured write decision. An allow policy does not override a failed guard, and production writes are blocked by the current execution boundary.

Policy evaluation order

Durin checks the requesting identity, membership, client, connection, reviewed capability and resources, inspection results, and upstream credential boundary before execution. A denial stops the request. Team restrictions can further narrow organization policy.

Policy outcomes

Policy outcomes are allowed, denied, or approval-required. Allowed requests still need successful dispatch and upstream execution. Approval-required requests return without executing; after independent approval, the requester must retry the exact request before the grant expires.

Apply the rules to a concrete request

Suppose a member asks to read a reviewed repository resource. Being in the organization is only one condition. The installation must be usable, the member must satisfy its team scope and personal access requirements, and the requested resource must be covered by the reviewed tool.

• If the tool or resource is outside the reviewed boundary, an allow write policy cannot grant access.
• If a team denies an action, membership in another team does not cancel that denial.
• If a supported sandbox write requires approval, the requester needs a different administrator’s exact grant and must retry before it expires.
• Production writes remain blocked even when the configurable write decision allows them.

Understand optional content evaluation

The built-in evaluator is the default. Where TypeSafe is configured on the server, an administrator can opt the organization into TypeSafe AI in the MCP policy evaluation setting. This adds request and response content checks to the existing authorization path.

TypeSafe receives the server-verified consumer permissions and the relevant tool arguments or response content. It can further restrict a request or withhold a response. It cannot overturn a baseline denial or replace independent write approval. Uncertain answers and service failures block access.

Review the data sent to the external evaluator before enabling it. Changing the evaluator invalidates outstanding approvals. Blocking a response after a write does not undo an upstream action that has already happened.

Validate changes using the affected identity

After a policy change, repeat a small, relevant request with the identity and connection it is intended to affect. Check both an expected permitted case and an expected denied case. Use the sandbox to test write approval, and inspect the decision reason together with the outcome.