# Regras de segurança para agentes de IA que publicam em centenas de contas

_2026-09-09 · Um manual para agentes de IA que publicam em muitas contas: APIs oficiais, chaves com escopo, legendas variadas, envio escalonado, limites e plano de parada._

Um agente de IA que publica em centenas de contas se mantém seguro seguindo um conjunto curto de regras: publicar só pelas APIs oficiais das redes, usar a chave com o menor acesso necessário, nunca enviar legendas idênticas para várias contas, espaçar o envio entre as contas, respeitar os limites e as políticas de cada rede e ter um jeito de interromper uma execução rapidamente. A maior parte disso deve ser garantida pela plataforma e pelos escopos das chaves, com as instruções do agente como uma segunda camada, e não como a única.

Abaixo está o manual que recomendamos, escrito para que você possa colar boa parte dele direto na skill de um agente. Cada regra vem com o motivo, porque um agente que entende o porquê lida melhor com casos fora do padrão do que um que só segue uma instrução seca.

## Por que agentes precisam de regras de segurança próprias?

Uma pessoa agendando posts erra uma vez de cada vez. Um agente erra em lote. Se as instruções têm um erro, ele cai em todas as contas da execução. A escala multiplica igualmente o trabalho bom e o ruim.

As redes também deixam claro que volume e repetição são sinais que elas monitoram. A [política de spam](https://transparency.meta.com/policies/community-standards/spam/) da Meta trata de publicações em frequência muito alta, manuais ou automatizadas, e de conteúdo repetitivo. As [políticas de spam, práticas enganosas e golpes](https://support.google.com/youtube/answer/2801973) do YouTube tratam de conteúdo repetitivo e sem público definido. São políticas sobre comportamento, e não sobre quem apertou o botão, uma pessoa ou um software.

## O manual

### Regra 1: só APIs oficiais

O agente publica por uma plataforma que usa a API oficial de cada rede. Nada de automação de navegador, logins compartilhados ou endpoints não oficiais. O Shager publica apenas pelas APIs oficiais das redes, então essa regra é cumprida pela escolha da plataforma, e não pela disciplina do agente.

Por quê: métodos não oficiais violam os termos de uso, colocam a própria conta em risco e falham de forma imprevisível.

### Regra 2: chaves com o menor privilégio possível

Comece todo agente com `read` e `write`. Adicione `publish` só quando uma pessoa decidir que aquele agente pode agendar. Use chaves separadas por cliente ou por agente, para que revogar uma não pare tudo.

Por quê: uma chave que não pode publicar transforma uma instrução ruim em um rascunho ruim, que é inofensivo. Nosso artigo sobre [chaves de API, escopos e auditoria](/en/blog/api-keys-scopes-and-audit) explica a configuração.

### Regra 3: primeiro o rascunho, depois o agendamento

Toda execução cria rascunhos. Agendar é uma etapa separada, depois da revisão ou da aprovação do cliente.

Por quê: isso cria um ponto de controle natural sem atrasar a produção do agente. O raciocínio completo está em [aprovação humana para posts de agentes](/en/blog/human-approval-for-agent-posts).

### Regra 4: varie a legenda por conta

Quando um post vai para muitas contas, use `per_channel` para dar a cada conta a própria legenda e, quando fizer sentido, o próprio primeiro comentário. Mantenha fixas as afirmações e as ofertas; varie a abertura, os detalhes locais, a redação e a chamada para ação.

Por quê: texto idêntico em muitas contas no mesmo momento é exatamente a cara de conteúdo repetitivo vista de fora. Nosso guia de [variação de legenda por conta](/en/blog/caption-variation-per-account-with-ai) mostra como fazer isso sem fugir da identidade da marca.

### Regra 5: escalone o envio

Não envie para todas as contas no mesmo segundo. O `stagger_seconds` do Shager define um intervalo de atraso aleatório entre as contas, com padrão de `[30, 90]` segundos. Para grupos grandes ou clientes sensíveis, aumente esse intervalo.

Por quê: espalhar os envios no tempo é como uma equipe de verdade publicaria em muitas páginas, e isso reduz os picos com cara de automação.

### Regra 6: conheça os limites rígidos de cada rede

Alguns limites são públicos. O Instagram, por exemplo, documenta que as contas estão [limitadas a 100 posts publicados via API num período móvel de 24 horas](https://developers.facebook.com/docs/instagram-platform/content-publishing). Seu agente nunca deveria chegar perto de limites assim na operação normal; se chegar, o plano está errado. As mídias também têm restrições de formato. Ao enviar vídeo para Reels, Shorts ou stories, passe `width`, `height` e `duration_ms` para `upload_media_from_url`, para que ele possa ser validado antes de qualquer post ser montado.

Por quê: um post rejeitado na hora do envio desperdiça um horário, e falhas repetidas são um ruído que você não quer na conta de um cliente.

### Regra 7: deixe a plataforma conferir antes de enviar

O Shager confere cada post contra as regras da rede de destino antes do envio. O agente deve tratar um erro de validação como informação: ler o código e a mensagem do erro, corrigir o post e tentar de novo uma vez. Se falhar duas vezes, parar e reportar.

Por quê: um agente que tenta de novo às cegas pode transformar um problema em dezenas de chamadas com falha.

### Regra 8: respeite o limite de requisições da própria API

A API do Shager permite 120 requisições por minuto por chave. Uma execução bem planejada usa grupos como destino e `per_channel` num único `create_post`, em vez de uma chamada por conta, então raramente chega perto disso.

Por quê: agrupar é mais rápido e mantém a execução dentro dos limites sem pausas artificiais na lógica do agente.

### Regra 9: tenha um plano de parada

Antes de uma execução grande, saiba como interrompê-la. `list_posts` mostra o que está agendado, e o `label` da execução indica quais posts pertencem a ela; `cancel_post` retira cada um antes do horário de envio. Uma pessoa também pode revogar a chave no painel de agentes, o que bloqueia qualquer nova chamada daquele agente.

Por quê: a hora de projetar o botão de parar é antes de precisar dele.

### Regra 10: mantenha um registro de auditoria e leia esse registro

Toda chamada de agente fica gravada no registro de auditoria do painel de agentes. Alguém deveria olhar esse registro toda semana, e não só depois de um incidente.

Por quê: desvios no comportamento do agente aparecem no registro antes de aparecerem em público.

## O manual em formato de skill

Aqui está uma versão condensada para colocar numa skill ou num prompt de sistema:

```text
SAFETY RULES (always apply)
1. Create drafts only unless the instructions explicitly say to schedule
   an approved post.
2. When targeting more than one account, always use per_channel with a
   distinct caption for each account. Never send identical captions.
3. Use stagger_seconds of at least [30, 90]; use [60, 180] for groups
   larger than 20 accounts.
4. For video, always pass width, height and duration_ms on upload.
5. Never state a price, discount, date or claim that is not in the brief.
6. On a validation error, fix and retry once. On a second error, stop and
   report the error code and message.
7. Label every post in a run with the same label so the run can be listed
   and cancelled as a group.
8. Never call schedule_post on a post that has not been approved.
```

Os limites da regra 3 são uma sugestão nossa, e não uma regra das redes. Escolha valores que façam sentido para seus clientes e mantenha a consistência.

## Como é uma execução grande e segura?

1. `whoami` para confirmar que os escopos da chave correspondem à tarefa.
2. `list_groups` e `list_channels` para definir exatamente quais contas estão incluídas, e informar o total antes de fazer qualquer outra coisa.
3. `upload_media_from_url` com as dimensões e a duração completas.
4. `create_post` com `group_ids`, `per_channel`, `first_comment`, `stagger_seconds` e um `label` da execução, como rascunho.
5. `request_approval`, ou repasse para um revisor humano.
6. Depois da aprovação, `schedule_post` para cada post aprovado.
7. Depois do horário de envio, `get_post` numa amostra para confirmar a entrega, e reporte as falhas.

O passo 2 é o que as equipes pulam e depois se arrependem. Um agente que avisa "esta execução vai para 212 contas em 3 grupos" dá a uma pessoa a chance de dizer "esse é o grupo errado" antes que exista um único rascunho.

## Perguntas frequentes

### Publicar por meio de um agente é mais arriscado do que publicar à mão?

O risco é diferente, não necessariamente maior. Um agente repete erros em escala, enquanto uma pessoa comete erros espalhados. Com chaves com escopo, execuções que começam pelo rascunho e legendas variadas, uma execução de agente pode ser mais consistente do que o trabalho manual em muitas contas.

### Qual é o padrão mais seguro para stagger_seconds?

O padrão do Shager é de 30 a 90 segundos entre as contas. Nenhuma rede divulga um espaçamento ideal, então aumente o intervalo para grupos grandes e avalie pelos resultados, e não por uma regra de bolso.

### Dá para parar uma execução agendada depois que ela começou?

Sim. Posts que ainda não foram enviados podem ser retirados com `cancel_post`, e o label compartilhado da execução facilita encontrá-los em `list_posts`. Revogar a chave bloqueia qualquer nova chamada.

Para entender como as plataformas tratam publicações em grande volume, leia [como evitar bloqueios por spam ao publicar em escala](/en/blog/avoid-spam-blocks-when-posting-at-scale) e depois copie o manual acima para a skill do seu agente antes da próxima execução.

---
Source: https://shager.ai/pt/blog/safety-rules-for-agents-posting-at-scale