create_csp
Create a contextual security policy (CSP) defining scoped rules for schedule, behavior, data, origin, or custom enforcement, with top-down inheritance and tool-level restrictions.
Instructions
Cria uma nova política de segurança contextual (CSP).
Escopos: tenant (global), team, agent, user — herança automática de cima para baixo. Tipos: schedule (horários), behavior (comportamento), data (dados), origin (origens), custom.
⚠️ Campo fora do contrato é ACEITO em silêncio (o schema permite propriedades extras) e fica INERTE. Não invente nome de campo: leia zihin://schemas/csp_config e use exatamente os de $defs.{tipo}Rules.
Exemplos de rules por tipo (todos os campos abaixo existem no contrato E são aplicados):
schedule: { allowed_hours: { start: "08:00", end: "18:00" }, allowed_days: ["mon","tue","wed","thu","fri"], blocked_dates: ["2026-12-25"], timezone: "America/Sao_Paulo" }
behavior: { max_tokens_per_request: 4096, max_iterations: 10, max_tool_calls: 20, must_not_tools: ["web_search","fetch_url"] }
data: { sensitive_fields: ["cpf","email"], never_expose: ["password_hash"], restricted_entities: ["folha_pagamento"], restriction_message: "Não posso consultar esse dado." }
custom: qualquer shape — é passado ao prompt como bloco de política sem interpretação do runtime.
Controle de superfície de tools (behavior):
must_not_tools: nomes de tools que o agente NUNCA executa, mesmo carregadas. Filtrado antes do turno nos dois runtimes (inclui o resume de HITL). É o único jeito de tirar uma tool nativa do agente sem desligar o recurso no tenant.
⚠️ policy_type "origin" NÃO é aplicado em runtime: nenhum entrypoint propaga o IP/origem do cliente até o loop, e countries/vpn/tor exigem provedor de geo que a plataforma não integra. A CSP é aceita e armazenada, mas não bloqueia nada — não use como controle de segurança.
Contrato formal: resource zihin://schemas/csp_config (envie só name/policy_type/scope/rules/... — tenant_id é injetado pelo servidor).
Aprovação por escopo (OE-2a, só chat nativo) — campos de behavior:
require_approval_for: array de string (nome de tool) ou objetos { tool_name } | { mcp_server_id } | { source: "mcp"|"api"|"db" } — tools casadas exigem aprovação HITL antes de executar
approval_policy_id: UUID de política criada via create_approval_policy — define QUEM aprova (sem ela, aprova o próprio solicitante) Ex: behavior: { require_approval_for: ["create_deal", { source: "db" }], approval_policy_id: "" }
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nome da política | |
| rules | Yes | Regras da política (estrutura varia por tipo — veja descrição acima) | |
| scope | Yes | Escopo de aplicação | |
| priority | No | Prioridade (maior = mais importante, default: 0) | |
| exceptions | No | Exceções às regras (mesma estrutura de rules, sobrescreve campos específicos) | |
| description | No | Descrição da política | |
| policy_type | Yes | Tipo da política | |
| scope_target_id | No | ID do alvo (obrigatório para escopos team, agent, user) |