A Stripe deixa agentes de IA pagar as suas faturas. Os limites de gastos ainda não chegaram: construa um hoje com regras de aprovação

Ver os controlosHover to explore

Na maioria das empresas em fase inicial, é uma só pessoa que paga as contas, e costuma ser o fundador. A 21 de outubro de 2026, a Stripe propôs passar parte desse trabalho para um agente de IA. O interessante não é que um agente já possa pagar uma fatura. É perceber que controlos chegaram com essa capacidade, quais ficaram de fora e o que se pode construir com os que existem.

Este artigo baseia-se no anúncio do Treasury for agents pela Stripe a 21 de outubro de 2026 e na documentação sobre o Treasury for agents, as chaves API de agente e as regras de aprovação, tal como publicada a 29 de outubro de 2026. As ferramentas do Treasury estão em pré-visualização pública e os detalhes podem mudar. A leitura a partir da secção 3 é minha.

1. O que chegou e o que não chegou

O Stripe Treasury for agents permite que um agente, incluindo o ChatGPT e o Claude, consulte saldos, pague faturas, mova dinheiro entre contas e converta moedas. Os agentes ligam-se através do servidor MCP da Stripe, que disponibiliza cinco ferramentas do Treasury em pré-visualização pública: um resumo de saldos, a conversão de moeda, o envio de dinheiro a um destinatário, a configuração de um destinatário e as transferências entre saldos da Stripe. Cada ferramenta exige a sua própria permissão.

Os controlos que a Stripe enumera: escolhe a que contas e dados um agente acede, se pode apenas ler ou também agir, e quando um movimento de dinheiro precisa da aprovação de uma pessoa. Por predefinição, diz a documentação, revê e aprova qualquer ação que resulte num movimento de dinheiro real.

Há duas coisas anunciadas que não chegaram: os limites de gastos, que segundo a Stripe viriam «nas próximas semanas», e a possibilidade de os agentes criarem cartões. A Stripe não é um banco; as contas à ordem são disponibilizadas pelo Fifth Third Bank.

O público é explícito. A Stripe afirma que 63 % das C corporations constituídas através do Stripe Atlas no segundo trimestre de 2026 tinham um único fundador. Um dos clientes de lançamento, a Kubrio, descreve-se como um fundador mais agentes de IA.

2. O controlo que existe hoje é a regra de aprovação

Os limites de gastos são o controlo que a maioria dos fundadores vai procurar, e ainda não existem. O que existe é mais flexível do que parece.

As regras de aprovação interrompem uma ação sensível e criam um pedido que um revisor designado tem de aprovar ou recusar. As ações aprovadas concluem-se automaticamente; as recusadas não alteram nada. Cada regra pode ter condições: um limiar de montante, um ator (por exemplo, apenas ações feitas com chaves marcadas como de agente) e uma frequência (mais de um certo número de pedidos num certo período). Em vez de exigir aprovação, uma regra também pode simplesmente bloquear a ação.

Junte tudo e tem um limite de gastos com outro nome: deixe o agente pagar sozinho as faturas pequenas, exija aprovação acima de um montante, exija-a também quando ele já fez mais do que alguns pagamentos no dia, e bloqueie o que nunca deve fazer. A Stripe inclui regras predefinidas para chaves de agente que cobrem reembolsos, cancelamentos de subscrições, pagamentos de saída, transferências de saída, levantamentos para a conta bancária e conversões de moeda. Parte-se, portanto, de «pedir autorização para tudo» e alivia-se de forma deliberada.

3. Dê ao agente a sua própria chave, não a sua sessão

O servidor MCP da Stripe aceita dois tipos de identidade. O OAuth permite que um cliente aja em nome da sua conta de utilizador. Uma chave API de agente é uma chave restrita, marcada na criação como pertencente a um agente autónomo, pensada para uma aplicação que precisa do seu próprio acesso persistente. A Stripe recomenda a segunda para agentes autónomos.

A diferença pesa sobretudo para quem funda a solo. A aprovação por duas partes exige que quem aprova seja diferente de quem pede, e um utilizador não pode aprovar o seu próprio pedido. Numa conta com um único membro, segundo a documentação da Stripe, uma regra de duas partes só pode ser guardada com o ator definido como chaves de agente, porque a chave de agente conta como um ator independente de si. Se o seu agente trabalhar com a sua própria sessão, age como se fosse você, e não pode ser ao mesmo tempo quem pede e quem aprova. Com a sua própria chave, o agente propõe e você aprova, como duas partes distintas no registo.

Uma chave de agente continua a ser uma chave. Limite as permissões às ferramentas de que precisa, associe-lhe uma política de acesso para que só funcione a partir dos servidores onde o agente corre, e mantenha-a fora do código-fonte. A própria documentação da Stripe recomenda guardá-la numa variável de ambiente em vez de a passar na linha de comandos.

4. A permissão mais arriscada é o destinatário, não o pagamento

É natural concentrar-se em quanto um agente pode enviar. A pergunta mais perigosa é a quem. A fraude com faturas sempre funcionou alterando os dados bancários numa fatura de aspeto legítimo, e um agente que lê faturas e também pode adicionar destinatários é exatamente o alvo para o qual esse ataque foi pensado. Um PDF envenenado a dizer «os nossos dados bancários mudaram» é uma injeção de prompt com um pagamento incluído.

A Stripe separa as duas coisas: enviar dinheiro e configurar um destinatário são ferramentas diferentes, com permissões diferentes. Aproveite essa separação. O agente que lê e paga faturas só deve poder pagar a destinatários já existentes. Adicionar ou alterar um destinatário fica com uma pessoa, com outra identidade e, idealmente, depois de uma confirmação por telefone com alguém que já conhece no fornecedor.

5. Se constrói agentes que lidam com dinheiro

O desenho da Stripe é um modelo útil, mesmo que nunca use o Treasury. Quando uma chave de agente ativa uma regra, a API devolve um erro approval_required e submete o pedido automaticamente. O agente pode anexar uma justificação. Os pedidos expiram ao fim de 14 dias. Os resultados chegam como eventos de webhook, e cada alteração de regra e cada decisão ficam registadas no histórico de segurança da conta.

É esta a forma a copiar no seu próprio produto: uma identidade separada para o agente, uma permissão por ferramenta, condições em vez de um simples interruptor, uma aprovação assíncrona para que o agente não fique pendurado, um motivo em cada pedido e um registo de quem aprovou o quê. Se o seu agente pode gastar o dinheiro de um cliente e os seus controlos são um prompt de sistema, está a depender da única camada onde um atacante consegue escrever.

Atenção também ao erro oposto. Se todas as ações precisarem de aprovação, quem aprova acaba a carregar em «aprovar» sem ler. Escalone as regras para que uma pessoa veja poucos pedidos e cada um mereça atenção.

6. O que eu não afirmaria

Que os agentes já podem gerir as suas finanças sem supervisão. Por predefinição, na Stripe, uma pessoa aprova cada movimento de dinheiro real. Essa predefinição é a própria declaração do produto sobre o ponto em que a tecnologia está.

Que os limites de gastos chegarão numa data concreta. A Stripe disse «nas próximas semanas» a 21 de outubro. Como serão ainda não foi publicado.

Que as regras de aprovação tornam um agente seguro por si sós. Limitam o que um erro ou um ataque pode custar. Não impedem que um agente seja enganado, e um revisor que não lê o pedido acrescenta pouco.

Que isto só diz respeito aos clientes da Stripe. As mesmas perguntas aplicam-se a qualquer agente com acesso a um banco, a um cartão ou a uma API de pagamentos: que identidade usa, que ações precisam de uma segunda parte e quem controla a lista de pessoas a quem pode pagar.

Em resumo

A Stripe tornou rotineiro que um agente pague uma fatura, e lançou a funcionalidade com aprovação humana predefinida para cada movimento de dinheiro real. Os limites de gastos estão prometidos, não entregues, mas as regras de aprovação com condições de montante, ator e frequência já permitem construir um.

Para um fundador, o trabalho é sobretudo de configuração: dê ao agente a sua própria chave, comece só com leitura, alivie por montante e frequência, e nunca deixe o agente que lê faturas decidir quem recebe. Se constrói agentes que movem dinheiro para os seus próprios clientes, copie a forma, não a funcionalidade.

Esta semana, faça uma lista de todos os sistemas onde um agente ou uma automatização pode mover dinheiro, e anote que identidade usa e quem aprova os seus pagamentos. Qualquer linha em que a resposta seja «a minha sessão» e «ninguém» é a primeira a corrigir.

Fontes: Stripe, Introducing Stripe Treasury for agents, 21 de outubro de 2026 — as capacidades, os controlos de acesso, de leitura ou ação e de aprovação, os limites de gastos e a criação de cartões como funcionalidades previstas, a menção ao Fifth Third Bank, o número de fundadores a solo no Stripe Atlas e o exemplo da Kubrio. Documentação da Stripe, Treasury for agents — o servidor MCP, a autenticação com OAuth e com chave API de agente, as cinco ferramentas do Treasury em pré-visualização pública e as respetivas permissões, e a aprovação predefinida dos movimentos de dinheiro real. Chaves API — chaves marcadas como de agente, regras de aprovação predefinidas e políticas de acesso. Regras de aprovação — condições, controlos de bloqueio e de aprovação, as regras predefinidas para chaves de agente, o erro approval_required, as justificações, a expiração ao fim de 14 dias, os eventos de webhook, o histórico de segurança e as contas com um único membro. A leitura das secções 3 a 6 é minha.

Related Posts

Os bancos estão a bloquear agentes de IA que usam a palavra-passe do cliente24 de outubro de 2026

AI Agents Need Permission Systems, Not Better Prompts — A Founder’s GuideJuly 14, 2026

Um modelo Qwen tentou enviar um ficheiro para Pequim num teste da Cohere. O seu controlo é a rede27 de outubro de 2026