/**
 * Policy Engine — permissão CONTEXTUAL, distinta do Security Scanner.
 *
 * SkillScanner responde: "isso parece perigoso?" (varredura estática de
 * conteúdo). PolicyEngine responde: "isso é permitido NESTE CONTEXTO?" —
 * mesma ação pode ser permitida em desenvolvimento e bloqueada em produção,
 * ou permitida para uma skill curada (builtin) e negada para uma skill de
 * baixa confiança (community).
 *
 * Regras são avaliadas em ordem; a primeira que casar decide. Sem match,
 * o default é permitir (o gate de permissão bruta já é feito por quem
 * concede `ToolContext.permissions` — o Policy Engine restringe em cima
 * disso, não substitui o least-privilege da ToolRegistry).
 *
 * Esse default só é defensável para tool cujo código o runtime conhece. Uma
 * tool que entrou por `ToolRegistry.register` não tem regra escrita para ela,
 * e para essa o "não previsto" passa a exigir aprovação humana
 * (`EXTERNAL-TOOL-001`) em vez de virar "permitido".
 */
import type { ToolPermission } from '../tools/registry.js';
export type PolicyEnvironment = 'development' | 'ci' | 'production';
/**
 * Nível de confiança de quem está solicitando a ação — mesma escala usada
 * pelo SkillScanner/SkillFactory: skills embutidas no framework (builtin),
 * geradas pela Skill/Agent Factory (generated, já passaram por scan) ou
 * de fonte externa/comunidade (community, o padrão mais restrito).
 */
export type TrustTier = 'builtin' | 'generated' | 'community';
export type PolicyRequestKind = 'tool' | 'filesystem-delete' | 'network' | 'dependency-install' | 'production-deploy' | 'skill-permission';
export interface PolicyRequest {
    kind: PolicyRequestKind;
    environment: PolicyEnvironment;
    /** Permissão de tool sendo exercida (kind === 'tool' | 'skill-permission'). */
    permission?: ToolPermission;
    trustTier?: TrustTier;
    /** Alvo da ação (path/URL/pacote) — usado só para contexto no motivo. */
    target?: string;
    description?: string;
    /**
     * Origem da TOOL, distinta do trust tier de quem a pede.
     *
     * `builtin`: a tool está no `ToolRegistry` do framework, o código dela foi
     * revisado junto com o runtime e cada uma tem regra de política acima.
     * `registered`: entrou por `ToolRegistry.register` em tempo de execução
     * (plugin, MCP, integração de quem embute o SDK) e o runtime nunca viu o
     * código dela.
     *
     * O default de política é PERMITIR quando nenhuma regra casa, e isso é uma
     * decisão defensável para as builtin (cobertas por regra e por permissão de
     * contrato) e indefensável para uma tool que chegou de fora sem nenhuma
     * regra escrita para ela. Este campo é o que permite separar os dois casos
     * sem virar o default do mundo inteiro e quebrar todo caminho existente.
     */
    toolOrigin?: 'builtin' | 'registered';
}
export interface PolicyDecision {
    allowed: boolean;
    /** Ação bloqueada mas pode prosseguir mediante aprovação humana (Fase 5: izanagi approve). */
    requiresApproval: boolean;
    reason: string;
    ruleId: string;
}
export interface PolicyRule {
    id: string;
    applies: (req: PolicyRequest) => boolean;
    decide: (req: PolicyRequest) => Omit<PolicyDecision, 'ruleId'>;
}
export declare const DEFAULT_POLICY_RULES: PolicyRule[];
export declare class PolicyEngine {
    private readonly rules;
    constructor(rules?: PolicyRule[]);
    evaluate(req: PolicyRequest): PolicyDecision;
}
//# sourceMappingURL=policy.d.ts.map