Dê um cartão para seu robô: por que cada agente de IA precisa do próprio cartão pré-pago

Em algum ponto dos últimos 18 meses, agentes de IA pararam de ser chatbots e viraram funcionários que pagam contas. Eles provisionam instâncias de GPU, assinam APIs, compram tokens de modelo, contratam serviços de scraping, alugam workers no Modal. E a maioria dos times está resolvendo isso da pior forma possível: compartilhando o cartão corporativo da empresa com o agente.

Esse post é sobre por que cada robô precisa do próprio cartão pré-pago dedicado — e como dar isso a ele em uma chamada de API.

A gambiarra atual

O setup típico em produção hoje:

1. Empresa tem um cartão corporativo master (de quem? do CFO).
2. Engenheiro cadastra esse cartão na Lambda Labs, OpenAI, Anthropic, AWS, Modal, etc.
3. Agente roda e cobra desse cartão.
4. Quando o agente entra em loop, alguém precisa acordar e cancelar o cartão (derrubando todos os outros 30 serviços que dependem dele).

Isso não escala. Não escala em risco (uma credencial cobre tudo), não escala em observabilidade (qual cobrança veio de qual agente?), não escala em contabilidade (como reembolsar o custo do agente para o cliente certo?).

A primitiva certa: cartão por agente

A regra que aplicamos no HubCard: cada agente que move dinheiro tem o próprio cartão. Não compartilha com humano, não compartilha com outro agente. Quando o agente é instanciado, emite. Quando é destruído, cancela.

import hubcard

# instanciar o agente
agent = ResearchAgent(
    purpose="literature_review_2026",
    budget_usd=200
)

# dar a ele um cartão dedicado
card = hubcard.cards.create(
    supplier=f"agent-{agent.id}",
    limit_cents=agent.budget_usd * 100,
    currency="USD",
    mcc_allow=[5734, 5818, 7372],  # SaaS, software, compute
    active_until=agent.deadline,
    metadata={
        "agent_id": agent.id,
        "agent_class": "ResearchAgent",
        "owner": "team-research"
    },
    idempotency_key=f"emit_agent_{agent.id}"
)

# entregar ao agente
agent.payment_method = card

# quando terminar
agent.run()
hubcard.cards.cancel(card.id)

Os efeitos imediatos:

• O agente não pode gastar mais que o orçamento dele. Cartão tem hard cap.
• O agente não pode cobrar fora do MCC esperado. Se tentar pagar uma TV em Hong Kong, declinado.
• Você sabe exatamente quanto cada agente custou. metadata.agent_id em cada tx.captured.
• Se o agente sair do controle, cancelar não derruba mais nada.

A regra "um cartão, um agente"

Vejo times caindo na tentação de "vamos ter um cartão por tipo de agente". É um meio-termo ruim. O custo de emitir um cartão extra é zero. O benefício de ter granularidade até a instância é alto.

Regra prática:

• Agente persistente (assistant do cliente, agente de scraping diário): cartão por instância, com renovação automática mensal.
• Agente efêmero (job de fine-tune, sprint de pesquisa): cartão por job, expira no fim.
• Agente experimental (devs testando idea nova): cartão por dev por experimento, expira em 7 dias por default.

Cada uma dessas categorias mapeia para um padrão de emissão. Quando dúvida, mais granular sempre.

Webhook como olho do controlador

O agente não fala diretamente com o sistema de monitoramento. O sistema observa as transações do cartão dele via webhook tipado:

async function handleHubcardWebhook(event: HubcardEvent) {
  if (event.type === "tx.declined" && event.data.transaction.reason === "limit_exceeded") {
    const agentId = event.data.transaction.metadata.agent_id;
    await alertOwner(agentId, "Agent hit hard limit");
    await pauseAgent(agentId);
  }

  if (event.type === "tx.captured") {
    await trackCost({
      agent_id: event.data.transaction.metadata.agent_id,
      amount_cents: event.data.transaction.amount_cents,
      merchant: event.data.transaction.merchant.name,
    });
  }
}

Esse pattern é o que separa "agente que paga contas" de "agente que torra dinheiro sem ninguém perceber". O controlador escuta o que o cartão diz — não confia no que o agente reporta.

"Mas e se o agente for malicioso?"

A pergunta que sempre aparece: e se o LLM for prompt-injectado e o agente tentar emitir um cartão de US$ 1M?

Respostas em camadas:

1. A API key do agente tem role limitada. Permissão cards:create:limited com cap de limit_cents por cartão. Mesmo se o agente quiser, não pode.
2. Rate limit por API key. Máximo X cartões/hora. Bloqueia loops.
3. Teto global por organização. Soma de limit_cents ativos tem ceiling. Acima disso, 429.
4. Audit log. Toda emissão registra caller_metadata. Investigação é trivial.
5. Cancelamento humano sempre prioritário. Owner cancela qualquer cartão via painel ou CLI a qualquer hora.

Modelagem de risco igual a dar credencial AWS pra agente: você confia no escopo, não na credencial.

MCP: dar cartão é uma ferramenta

A forma mais limpa de dar cartão ao agente é via MCP server (Model Context Protocol). O agente vê isso como uma ferramenta:

Tool: hubcard.emit_card
Description: Emit a prepaid card scoped to a specific task.
Args:
  purpose: string (what this card is for)
  limit_cents: number (max spend)
  currency: "USD" | "BRL" | "EUR"
  active_until: ISO datetime (optional)
Returns: { id, pan, exp, cvv }

Claude, GPT e qualquer modelo compatível com MCP usam isso de forma natural. O modelo "decide" emitir um cartão quando precisa pagar algo, executa, e cancela depois. Sem você ter que escrever orchestration custom.

Detalhamos esse padrão em API de cartões pré-pago para agentes de IA.

O efeito cultural

Quando você dá cartão ao robô, algo muda na forma como o time pensa:

• Agentes começam a ter orçamento explícito, não "use o cartão da empresa".
• Reviews de agente passam a incluir "qual o gasto previsto vs realizado".
• Custo de IA vira observável por unidade de trabalho, não linha agregada na fatura.
• Devs param de medo de testar agente novo, porque o blast radius é o limite do cartão.

Esse último é talvez o ganho mais importante. A maior barreira pra experimentar com agentes hoje é financeira, não técnica. Remover essa barreira destrava categoria nova de produto.

O que NÃO recomendamos

• Um cartão para "todos os agentes da empresa": perde granularidade, vira mini-master.
• Cartão com limite "alto pra qualquer caso": defeats the purpose. Limite deve ser orçamento real + 5–10%.
• Cartão sem active_until: agente que esqueceu de cancelar vira cobrança eterna. Sempre defina expiração.
• Cartão sem metadata.agent_id: você vai precisar dessa info quando o webhook chegar. Sempre tagueie.

Dê o cartão hoje

Se você opera agentes em produção, dar a cada um seu próprio cartão pré-pago não é otimização — é arquitetura mínima. Compartilhar credencial entre agente e empresa (ou entre agentes) é a versão 2026 de hardcodar password no código.

Comece com a API de cartões pré-pago ou veja o MCP server do HubCard para integrar com Claude e GPT em minutos.

Seu robô merece o próprio plástico (virtual).