WordPress 7.1 cria quatro controles para habilidades de IA

O que mudou na Abilities API do WordPress 7.1

O WordPress 7.1 adiciona quatro filtros ao ciclo de execução da Abilities API. A mudança, documentada em 29 de julho de 2026, permite interromper uma habilidade antes de ela rodar, ajustar a entrada antes da validação, aplicar uma camada extra de autorização e transformar o resultado antes da validação de saída. Para plugins ligados a agentes de inteligência artificial, isso cria pontos de controle que antes exigiam lógica própria em cada callback.

A novidade não coloca um agente autônomo dentro do WordPress. A Abilities API continua sendo a camada que registra ações com nome, descrição, esquemas de entrada e saída, callback de permissão e callback de execução. O MCP Adapter pode converter essas habilidades em ferramentas, recursos ou prompts consumidos por clientes compatíveis com Model Context Protocol. Os novos filtros atuam no momento em que uma dessas habilidades é executada, seja internamente, pela REST API, por WP-CLI ou por uma integração que passe pela mesma camada.

Na prática, desenvolvedores ganham quatro lugares previsíveis para implementar políticas transversais. Um plugin pode pausar uma ação durante manutenção, adicionar contexto calculado pelo servidor, exigir uma regra corporativa além da permissão original e limpar dados internos antes de devolver a resposta a um agente. A responsabilidade também aumenta: um filtro mal escrito pode alterar muitas habilidades de uma vez.

Como era o fluxo antes dos novos filtros

Desde o WordPress 6.9, uma habilidade registrada inclui contratos explícitos. O desenvolvedor informa o que entra, o que sai, quem pode executar e qual função realiza o trabalho. A API normaliza e valida os dados, verifica a permissão, chama o callback e valida a resposta. Essa estrutura é útil para interfaces humanas, automações e agentes porque reduz ambiguidades: o consumidor sabe quais argumentos pode enviar e qual formato deve receber.

Antes do WordPress 7.1, existiam as ações wp_before_execute_ability e wp_after_execute_ability. Elas servem para observar o processo, gerar logs ou métricas, mas ações não mudam o valor que percorre o pipeline. Se um produto precisava bloquear temporariamente uma habilidade, alterar um argumento ou tratar uma falha conhecida, a lógica costumava ir para dentro do próprio callback ou para uma camada particular do plugin.

Isso funciona em integrações pequenas, mas escala mal. Imagine um conjunto de habilidades de WooCommerce, atendimento e conteúdo exposto a um agente. Repetir a mesma regra de janela de manutenção, limite de uso ou mascaramento de dados em cada função multiplica pontos de falha. Também fica mais difícil provar que todos os caminhos aplicam a mesma política.

Os quatro filtros do WordPress 7.1 não eliminam a lógica específica de domínio. Eles oferecem pontos comuns para regras que realmente atravessam várias habilidades.

A ordem do novo ciclo de execução

O fluxo documentado pelo Core segue esta sequência:

1. wp_pre_execute_ability pode encerrar o processamento imediatamente.
2. WP_Ability::normalize_input() aplica a normalização e os valores padrão do esquema.
3. wp_ability_normalize_input pode transformar a entrada normalizada.
4. O WordPress valida a entrada contra input_schema.
5. O callback de permissão da habilidade é executado.
6. wp_ability_permission_result pode aplicar outra decisão de autorização.
7. A ação wp_before_execute_ability é disparada.
8. O callback de execução registrado realiza o trabalho.
9. wp_ability_execute_result pode transformar o resultado ou tratar um WP_Error específico.
10. O WordPress valida o valor contra output_schema.
11. A ação wp_after_execute_ability é disparada e a resposta é devolvida.

A posição de cada filtro importa. Entrada transformada ainda precisa passar pelo esquema de entrada. Resultado transformado ainda precisa passar pelo esquema de saída. O filtro de pré-execução é a exceção: quando retorna um valor diferente do sentinela recebido, ele desvia do restante do pipeline.

Essa diferença evita uma leitura perigosa. wp_pre_execute_ability não é um atalho para corrigir entradas inválidas ou ignorar permissões. Ele deve ser usado quando a intenção é realmente fornecer uma resposta antecipada, como um bloqueio de manutenção ou um resultado armazenado em cache cuja origem e validade sejam controladas.

wp_pre_execute_ability: bloquear ou responder antes do callback

O primeiro filtro roda no início de WP_Ability::execute(), antes de normalização, validação e verificação de permissão. O WordPress usa uma instância única de WP_Filter_Sentinel como valor padrão. Para deixar a execução seguir, o callback precisa devolver exatamente o valor recebido em $pre.

Um bloqueio temporário e restrito a uma habilidade pode ser implementado assim:

add_filter(
    'wp_pre_execute_ability',
    function ( $pre, $ability_name, $input, $ability ) {
        if ( 'minha-loja/sincronizar-catalogo' !== $ability_name ) {
            return $pre;
        }

        if ( ! minha_loja_em_manutencao() ) {
            return $pre;
        }

        return new WP_Error(
            'catalogo_em_manutencao',
            __( 'A sincronização está temporariamente indisponível.', 'minha-loja' )
        );
    },
    10,
    4
);

O cuidado central é o escopo. Um callback que esquece de conferir $ability_name pode interceptar todas as habilidades registradas. Também não se deve fabricar um resultado bem-sucedido para contornar o callback de permissão. Se a resposta antecipada depende do usuário, a própria lógica de pré-execução precisa avaliar esse contexto de forma explícita e segura.

wp_ability_normalize_input: acrescentar contexto antes da validação

Depois que o WordPress aplica os valores padrão do esquema, wp_ability_normalize_input recebe a entrada normalizada. Esse ponto pode completar dados derivados do ambiente, converter uma representação aceita ou recusar uma condição com WP_Error.

Um uso plausível em integração com IA é acrescentar um identificador de política calculado no servidor, sem confiar que o cliente o envie. Porém, a propriedade precisa existir em input_schema; caso contrário, a validação posterior deve rejeitar a estrutura.

add_filter(
    'wp_ability_normalize_input',
    function ( $input, $ability_name, $ability ) {
        if ( 'meu-plugin/resumir-conteudo' !== $ability_name ) {
            return $input;
        }

        $input['politica_editorial'] = meu_plugin_politica_ativa();
        return $input;
    },
    10,
    3
);

O filtro não substitui sanitização e validação. Ele acontece antes da validação justamente para que o valor final seja conferido pelo contrato registrado. Se uma taxa de uso for excedida, o callback também pode devolver WP_Error; na REST API, o controlador propaga esse erro e usa status 400 por padrão, salvo quando outro status, como 429, é informado.

wp_ability_permission_result: somar uma política de autorização

O terceiro filtro roda depois do permission_callback da habilidade. Ele recebe true, false ou WP_Error, além do nome, da entrada e da instância da habilidade. Isso permite aplicar uma regra adicional sem reescrever a permissão original.

Para agentes, o caso mais interessante é combinar capacidade do usuário com uma política operacional. Um site pode permitir que editores executem determinada habilidade, mas restringir chamadas automatizadas a um horário, ambiente ou contexto aprovado.

add_filter(
    'wp_ability_permission_result',
    function ( $permission, $ability_name, $input, $ability ) {
        if ( 'meu-plugin/publicar-resumo' !== $ability_name ) {
            return $permission;
        }

        if ( true !== $permission ) {
            return $permission;
        }

        if ( ! meu_plugin_janela_de_automacao_aberta() ) {
            return new WP_Error(
                'automacao_fora_da_janela',
                __( 'A automação não está autorizada neste horário.', 'meu-plugin' )
            );
        }

        return true;
    },
    10,
    4
);

O padrão acima preserva uma negativa anterior. Transformar false em true sem entender por que o callback original negou acesso pode abrir uma falha de privilégio. A documentação informa ainda que o filtro integra check_permissions(), então ele vale também quando a permissão é consultada separadamente por REST API ou WP-CLI.

wp_ability_execute_result: limpar a resposta ou tratar falhas conhecidas

O último filtro novo recebe o valor devolvido pelo callback de execução, inclusive um possível WP_Error, antes da validação de saída. Isso permite remover campos internos, adaptar uma estrutura ou recuperar apenas falhas bem definidas.

Considere uma habilidade que consulta um serviço remoto e retorna também metadados usados apenas para depuração. O filtro pode retirar esses campos antes que a resposta chegue ao consumidor, desde que o objeto final continue compatível com output_schema.

add_filter(
    'wp_ability_execute_result',
    function ( $result, $ability_name, $input, $ability ) {
        if ( 'meu-plugin/consultar-base' !== $ability_name ) {
            return $result;
        }

        if ( is_wp_error( $result ) ) {
            return $result;
        }

        unset( $result['rastreamento_interno'] );
        return $result;
    },
    10,
    4
);

Também é possível trocar um WP_Error específico por dados de fallback. Essa recuperação deve ser estreita: conferir o nome da habilidade, o código do erro e a validade da fonte alternativa. Engolir qualquer falha produziria respostas aparentemente corretas quando o sistema deveria sinalizar indisponibilidade.

O impacto para plugins conectados a agentes por MCP

O MCP Adapter oficial transforma habilidades do WordPress em componentes que clientes de IA conseguem descobrir e invocar. No servidor padrão, habilidades públicas podem ser acessadas por ferramentas de descoberta, inspeção e execução. Por isso, uma política aplicada no ciclo da Abilities API pode proteger o mesmo comportamento sem depender de qual cliente MCP iniciou a chamada.

Esse desenho favorece separação de responsabilidades. O adaptador trata transporte e protocolo. A habilidade declara contrato, execução e permissão básica. Os novos filtros podem cuidar de regras transversais, como limites, contexto de locatário, janelas de operação, recuperação controlada e redução de dados na resposta.

Ainda assim, filtro não é firewall mágico. Autenticação do transporte, princípio do menor privilégio, escopo das habilidades públicas e revisão de cada callback continuam obrigatórios. Uma habilidade destrutiva não se torna segura porque existe um filtro de permissão; ela precisa de um contrato restrito, um permission_callback correto e testes que cubram chamadas internas e externas.

Checklist para adotar os filtros sem criar outra camada frágil

Antes de usar os novos pontos de extensão em produção, a equipe pode seguir esta sequência:

1. Liste as habilidades registradas e marque quais podem ser acessadas por REST, WP-CLI ou MCP.
2. Mantenha autorização essencial no permission_callback; use o filtro apenas para políticas adicionais.
3. Restrinja todo filtro por $ability_name ou por uma lista explícita de habilidades.
4. Garanta que entradas transformadas continuem previstas em input_schema.
5. Garanta que resultados transformados continuem previstos em output_schema.
6. Registre bloqueios e recuperações sem armazenar prompts, chaves ou conteúdo sensível desnecessário.
7. Teste null, false, arrays, objetos e WP_Error no caminho de pré-execução.
8. Teste a mesma habilidade por PHP, REST, WP-CLI e MCP quando esses caminhos estiverem habilitados.
9. Preserve negativas de permissão; nunca use um filtro genérico para elevar acesso.
10. Faça teste de compatibilidade com WordPress 7.1 em staging antes da versão final, prevista para 19 de agosto de 2026.

O que muda para quem mantém plugins de IA

Para um plugin isolado, colocar toda a regra no callback ainda pode parecer mais simples. A vantagem dos filtros aparece quando várias habilidades compartilham políticas. Um único mecanismo de limitação pode cobrir operações relacionadas; uma camada de autorização pode respeitar regras da organização; uma etapa de saída pode remover metadados internos de todas as respostas destinadas a agentes.

O ganho mais importante é a previsibilidade do pipeline. Há um ponto para interromper, outro para transformar a entrada, outro para decidir a permissão e outro para ajustar a saída. Como a validação continua em torno dessas transformações, o contrato permanece como limite técnico, desde que o desenvolvedor não use a pré-execução para evitá-lo.

WordPress 7.1 ainda estava em ciclo de pré-lançamento na data desta apuração. Portanto, a ação recomendada é adaptar e testar integrações, não atualizar sites críticos para uma versão de desenvolvimento. Plugins que já mantêm hooks próprios podem comparar suas camadas com os novos filtros e decidir o que pode migrar para o Core sem perder contexto específico do protocolo ou do domínio.

Fontes consultadas

• Make WordPress Core: novos filtros do ciclo de execução da Abilities API no WordPress 7.1
• WordPress Trac: ticket 64989 sobre filtros nos métodos de WP_Ability
• Developer.WordPress.org: manual oficial da Abilities API
• GitHub do WordPress: documentação oficial do MCP Adapter