create_csp
Define contextual security policies for AI agents at tenant, team, agent, or user scope, with schedule, behavior, data, and custom rules.
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 no runtime (inclusive no 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) |