# Policies

A Policy is a rule the MCP Gateway evaluates on every tool call. The rule produces one outcome: **Auto-approve**, **Require approval** or **Deny**.

***

### 📖 Key Concepts

* **Policy**: A rule the MCP Gateway evaluates on every Agent tool call. Inputs: Action type, User attributes, Connection attributes. Output: one of three outcomes.
* **Default Policy**: One of four pre-loaded policies (one per Action type) that ship on day one.
* **Custom Policy**: A Policy authored by an Admin under Settings > Policies.
* **Action type**: Cakewalk's classification of what a tool call does: **Read**, **Write**, **Destructive** or **External**.

:bulb: *Why this matters:* The Policies you author determine what your Agents can do without asking, what pauses for review and what is blocked.

***

### 📐 Action Types

Every tool call is classified into exactly one Action type. Classifications come from MCP annotations the tool author declared. When annotations are missing, Cakewalk infers the Action type from the Catalog.

| Action type     | What it covers                                                                                  | MCP annotation                                |
| --------------- | ----------------------------------------------------------------------------------------------- | --------------------------------------------- |
| **Read**        | No state change. Retrieving data, querying status, listing records.                             | `readOnlyHint: true`                          |
| **Write**       | Creates or updates state. Adding records, modifying configurations. Reversible.                 | `readOnlyHint: false, destructiveHint: false` |
| **Destructive** | Deletes or irreversibly changes state. Dropping records, removing users, purging data.          | `destructiveHint: true`                       |
| **External**    | Interacts with systems outside the tool's domain. Sending emails, posting to Slack, publishing. | `openWorldHint: true`                         |

A tool call can match multiple types. The highest-risk applicable type wins.

***

### 🛡️ Default Policies

Four Default Policies ship on day one: one per Action type. They guarantee governance coverage from the moment an org is created.

| Action type     | Default outcome  |
| --------------- | ---------------- |
| **Read**        | Auto-approve     |
| **Write**       | Require approval |
| **Destructive** | Deny             |
| **External**    | Deny             |

Default Policies are permanent. Admins can edit the outcome to match their org's risk tolerance; the Action types and ordering are fixed.

***

### ✏️ Custom Policies

Custom Policies are the rules an Admin authors for their org. Each Custom Policy has:

* **Name** (required) and Description
* **Conditions** that compose with AND / OR
* **Outcome** (Auto-approve, Require approval or Deny)
* **Status**: Active, Draft or Archived

Each condition pairs a Type with a value or set of values to match:

| Type                      | Examples                                   |
| ------------------------- | ------------------------------------------ |
| **Action type**           | Read / Write / Destructive / External      |
| **Connection attributes** | name, category, risk level                 |
| **User attributes**       | department, title, location, user category |

Connection attributes come from the Catalog. User attributes come from your HRIS sync. Both lists grow as the Catalog expands and as more HRIS fields are mapped.

***

### 🎨 Visual and Code Authoring

Conditions can be authored in two views:

* **Visual**: A condition builder with property dropdowns, operators and AND/OR groups. The default authoring surface.
* **Code**: Rego (the OPA policy language). Use for conditions the visual builder does not yet express. Once a Policy is switched to Code, it stays in Code.

Both views describe the same Policy. The gateway evaluates the underlying Rego.

***

### 🔁 Policy Status

Custom Policies move through three statuses:

* **Draft**: Saved but not evaluated by the gateway.
* **Active**: Evaluated on every tool call.
* **Archived**: No longer evaluated. History preserved.

A Policy created via **Save as draft** is Draft. **Publish** moves it to Active immediately. To return an Active Policy to Draft, use **Move to draft** in the 3-dot menu; to retire it, use **Archive**.

***

### ⚖️ Conflict Resolution

When two Active Policies match the same tool call but produce different outcomes, the gateway resolves deterministically. Two rules:

1. **Custom > Default.** Any Custom Policy outranks any Default Policy.
2. **Within the same tier, more restrictive wins.** Deny > Require approval > Auto-approve.

Every tool call produces exactly one outcome. Nothing falls through.

***

### Related Concepts

* [The Tool Call Lifecycle](/docs/ai-agent-access/concepts/the-tool-call-lifecycle.md): when Policies are evaluated
* [Audit Log](/docs/ai-agent-access/concepts/audit-log.md): what each Policy evaluation records
* [The MCP Gateway](/docs/ai-agent-access/concepts/the-mcp-gateway.md): where Policy evaluation runs


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.cakewalk.security/docs/ai-agent-access/concepts/policies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.