Guardrails

Guardrails are the rules that decide what the AI agent is allowed to do in your workspace on its own, what it has to ask a human about first, and what it may never do at all.

You configure them on the AI Policies page under Governance in the sidebar.

How Guardrails Work

A policy is a named, switchable set of rules. Each rule has three parts:

When the agent calls a tool, every enabled policy is checked, and every rule inside it, in order. The first rule that stops the call decides the outcome — whether it denies the call or holds it for approval, checking stops there and the remaining rules are not consulted. If no rule stops it, the call goes ahead.

What Guardrails Cover

Guardrails apply to tools that change something or start something — creating an audience, updating a model, triggering a sync, deleting an orchestration. Tools that only read data are never gated, so the agent can always look at your workspace and answer questions about it.

The rules apply to AI-initiated actions from any client: the agent chat inside Zeotap, and any external MCP client connected with an API key. They do not apply to changes you make yourself in the UI or through the REST API — those are governed by RBAC and recorded in the workspace audit log.

Actions

Rule Types

Tool Guard

Matches on the name of the tool being called. This is the most direct rule type and the one the default policies use.

Names match exactly (trigger_sync), or you can end a pattern with * to match a family of tools (delete_* matches delete_journey, delete_identity_graph, and so on). Matching ignores case.

Example: hold every deletion for approval with the single pattern delete_*.

Rate Limit

Limits how many times a tool can be called within a rolling time window.

The count is kept per tool, so a limit of 5 per hour on two tools allows 5 calls of each, not 5 between them. The rule matches once a call would take the tool past the limit.

Example: at most 5 trigger_audience_sync calls per hour.

Banned Filter

Matches when an audience filter references a column or an operator you have put off limits. The whole filter tree is inspected, including conditions nested inside event and relation conditions, so a banned column cannot be hidden a few levels down.

Column and operator names are matched ignoring case.

Example: deny any agent-built filter that references ssn or date_of_birth.

Destination Guard

Matches on the destination type a call is writing to.

Types are matched ignoring case, and the rule only applies to calls that name a destination type.

Example: require approval before the agent creates anything pointed at your ad platforms.

Default Policies

Every new workspace starts with two policies, both enabled:

They are ordinary policies: edit them, switch them off, or delete them. They are created once, when the workspace is created, so a policy you delete does not come back.

Creating a Policy

1. Navigate to AI Policies under Governance in the sidebar
2. On the Policies tab, click Create Policy
3. Give the policy a Name — it has to be unique within the workspace
4. Click Add Rule, then choose a Type and an Action
5. Fill in the rule’s settings — the fields change with the type you picked
6. Add further rules if you want them evaluated in the same policy, in the order you add them
7. Click Create

The policy takes effect immediately, on the agent’s next tool call. Use the Enabled switch in the policies table to turn a policy off without deleting it, or Edit to change its rules.

Approval Workflow

When a call matches a Require Approval rule:

1. The call is held — nothing is created, changed, or triggered yet. The agent is told the request is pending and carries on with the rest of the conversation.
2. The request appears on the Pending Approvals tab of the AI Policies page, and the count shows against AI Policies in the sidebar. Workspace Owners and Admins are also emailed.
3. A reviewer clicks Review and sees which tool was called and the exact arguments it was called with, and can add a note explaining the decision.
4. Clicking Approve runs the held call. Clicking Reject discards it — the action never runs.
5. Requests that nobody reviews expire after 24 hours. They drop off the Pending Approvals tab and can no longer be approved — if the action is still wanted, ask the agent for it again.

Ask the agent whether a request has been resolved and it will check for you; a rejected request comes back with the reviewer’s note, so telling it why you rejected something is worth the extra sentence.

Audit Log

Every guardrail decision is recorded, whichever way it went. Go to Governance → Audit Logs and open the AI Audit Logs tab.

Pending approval is written when a rule holds a call; a second entry with Approved is written if a reviewer later lets it run. Because guardrails only evaluate tools that change something, read-only tool calls do not appear here.

Permissions

Members can see what the guardrails are and what the agent has been doing, but cannot change the rules or resolve an approval. See RBAC for assigning these to custom roles.

API Reference

# Policies
GET    /api/v1/workspaces/{id}/policies
POST   /api/v1/workspaces/{id}/policies
PUT    /api/v1/workspaces/{id}/policies/{policyId}
DELETE /api/v1/workspaces/{id}/policies/{policyId}
 
# Approvals
GET  /api/v1/workspaces/{id}/approvals
POST /api/v1/workspaces/{id}/approvals/{approvalId}/review
 
# AI audit log
GET /api/v1/workspaces/{id}/ai-audit-log?limit=50&offset=0

A policy is created with a name and a rules array, where each rule carries a type, an action, and a condition shaped to the type:

{
  "name": "Production Safety",
  "rules": [
    {
      "type": "tool_guard",
      "action": "require_approval",
      "condition": { "tools": ["delete_*", "trigger_sync"] }
    },
    {
      "type": "rate_limit",
      "action": "deny",
      "condition": {
        "max_calls": 5,
        "window_seconds": 3600,
        "tools": ["trigger_audience_sync"]
      }
    }
  ]
}

The remaining condition shapes are banned_filter (banned_columns, banned_operators) and destination_guard (guarded_types).

To review a request, post {"status": "approved"} or {"status": "rejected"}, optionally with a note.

Next Steps

• AI Agent — what the agent can do inside those boundaries
• MCP Server — the tools guardrails are evaluated against, and the scopes that gate them
• Audit Log — the companion record of changes made by people