Há uma classe nova de problema que está aparecendo em produção: agentes de IA que provisionam infraestrutura precisam pagar pela infraestrutura que provisionam. E hoje, isso é resolvido com gambiarras — cartão master compartilhado, limites genéricos, sem ciclo de vida. Esse post é sobre como expor uma API de cartões pré-pago para que agentes virem cliente legítimo do sistema de pagamento, com idempotência, escopo e cancelamento programado.
O caso de uso
Eu rodo um agente de pesquisa que provisiona instâncias H100 spot em três provedores diferentes (Lambda, RunPod, Hyperstack) dependendo de preço e disponibilidade. Antes do HubCard:
- Cartão pré-cadastrado em cada provedor.
- Limite genérico, porque o custo varia muito por job.
- Cancelamento manual se o agente fugia do controle.
O dia em que um agente meu rodou US$ 18 num GPU spot às 4h da manhã não me incomodou. O dia em que outro agente entrou em loop e rodou US$ 4.300 em 90 minutos me convenceu que pagamento precisa ser orquestrado, não pré-aprovado.
A primitiva: cartão escopado por job
A ideia central: para cada job que vai consumir infra paga, o agente emite um cartão dedicado com limite igual ao orçamento da job, executa, e cancela ao final.
import hubcard
client = hubcard.Client(api_key=os.environ["HUBCARD_KEY"])
card = client.cards.create(
supplier="lambda-h100-job-3814",
limit_cents=2000_00, # US$ 2.000 hard cap
currency="USD",
mcc_allow=[7372], # só compute providers
active_until="2026-04-22T18:00:00Z",
metadata={"agent_run_id": "run_3814", "purpose": "fine_tune"},
idempotency_key=f"emit_lambda_job_3814_{run_attempt}"
)
# usar card.pan no API do Lambda
provision_gpu(api_key=lambda_key, payment_method=card.pan)
# ao final
try:
do_fine_tune(...)
finally:
client.cards.cancel(card.id)
O efeito: mesmo se o agente entrar em loop, o cartão não autoriza acima de US$ 2.000. Mesmo se o agente cancelar mal, o active_until mata o cartão automaticamente. Mesmo se duas tentativas paralelas rodarem, Idempotency-Key garante um único cartão.
MCP: agentes Claude/GPT como clientes nativos
Lançamos um MCP server (Model Context Protocol) que expõe a API de cartões pré-pago como ferramenta nativa para agentes Claude, GPT e similares. O agente fala diretamente:
Tool: hubcard.emit_card
Args: {
supplier: "openai-gpt5-batch",
limit_cents: 50_00,
currency: "USD",
active_until: "in 2 hours"
}
Returns: { id, pan, exp_month, exp_year, cvv, status }
O agente recebe um objeto cartão funcional, usa o PAN para autenticar na API de destino, e devolve via:
Tool: hubcard.cancel_card
Args: { id: "card_01HX..." }
A diferença com cartão master: o agente nunca tem acesso à credencial de pagamento da organização inteira. Ele tem acesso à credencial de pagamento da job que está executando. Se ele se comportar mal, o blast radius é o limite da job.
Idempotência salva a vida
Agentes têm jitter mal calibrado. Já vimos retries de 50ms entre tentativas, threads paralelas tentando a mesma operação, jobs que param e voltam horas depois pensando que precisam emitir cartão novo.
A regra que aplicamos: a chave de idempotência DEVE estar no contexto da job, não no momento da chamada. Algo como emit_lambda_job_{job_id}_{attempt_counter} — não emit_lambda_job_{now()}.
Mais detalhes em idempotência na API de emissão.
Webhooks como sinal para o agente
O agente também consome webhooks. Quando uma transação é autorizada/recusada, o evento volta para o controlador do agente:
{
"event": "tx.declined",
"card_id": "card_01HX...",
"amount_cents": 220_00,
"reason": "limit_exceeded",
"metadata": { "agent_run_id": "run_3814" }
}
O controlador agora sabe que o agente bateu o teto e pode decidir: pausar, emitir cartão novo com mais saldo, abortar a job. Sem o webhook, o agente continuaria rodando achando que tudo está bem.
O risco do "agente que emite cartão"
A primeira pergunta de qualquer security review: "e se o agente decidir emitir um cartão com US$ 1 milhão e fugir com isso?"
Respostas que aplicamos:
- Rate limit por API key: max X cartões/hora. Default conservador.
- Teto global por organização: a soma de
limit_centsde cartões ativos não pode exceder Y. - Roles: a API key do agente tem permissão
cards:create:limitedque aplica um teto duro delimit_centspor cartão. - Audit log: toda emissão tem
caller_metadataregistrando qual agente, qual job, qual run. - Cancelamento por humano sempre prioritário: o owner pode cancelar qualquer cartão a qualquer hora via painel ou CLI, independente do que o agente esteja fazendo.
O modelo de risco aqui é o mesmo de dar acesso AWS a um agente: você confia no escopo, não na credencial. Quem dá acesso *:* a um agente está errando do mesmo jeito que quem dá iam:*.
Padrões de uso emergentes
Em 6 meses observando esse uso em produção:
- Cartão por experimento de fine-tune: limite = orçamento previsto + 10%, expira em 24h.
- Cartão por sprint de scraping: limite = teto da semana, MCC restrito a
5734/7372. - Cartão por usuário final (quando o agente é multi-tenant): cada usuário do produto tem seu cartão, billing volta limpo para reconciliar.
- Cartão por billing cycle: ferramentas que cobram mensal recebem cartão com
limit_cents = preço * 1.05, expira no fim do ciclo, renovado por orquestrador.
O padrão comum: cartão como objeto de orquestração, não como recurso compartilhado.
Por que isso muda a economia da IA
O argumento de quem opera agentes em produção: o custo dominante não é o LLM — é a infra que o agente provisiona. GPU spot a US$ 2/h, API de tools a US$ 0.01/call, storage S3 que ninguém limpa. Esses custos só ficam previsíveis com observabilidade financeira em tempo real.
Cartão dedicado por escopo dá essa observabilidade de graça: cada transação é taggeada, cada limite é hard cap, cada cancelamento é instantâneo. A planilha de custo do agente vira uma view SQL — não uma fatura de fim de mês.
E quando você combina isso com gestão de despesas já estruturada por categoria, a empresa inteira ganha uma camada nova de previsibilidade orçamentária que antes não existia para workloads agênticos.
O dia em que pagamento vira primitiva de SDK
A previsão razoável: nos próximos 12 meses, frameworks como LangChain, AutoGen, LangGraph vão tratar pagamento como primitiva de primeira classe. agent.emit_payment_method(scope, limit) será tão natural quanto agent.invoke_llm(prompt). E quando isso acontecer, a infraestrutura que vencer é a que tiver API de cartões pré-pago programática, com idempotência e escopo, exposta por MCP.
Não é coincidência que a gente esteja descrevendo o HubCard.