Policies
Policies define what Agents are allowed to do, what requires human approval, and what is always blocked. They are the core governance surface in Cakewalk Agent Access.
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.
💡 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.
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.
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:
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:
Custom > Default. Any Custom Policy outranks any Default Policy.
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: when Policies are evaluated
Audit Log: what each Policy evaluation records
The MCP Gateway: where Policy evaluation runs
Last updated
Was this helpful?