O agente da Taxbit escolhe ferramentas, nunca de quem é a conta. Identidade vinculada antes do modelo rodar
O Taxbit Assist, agente em produção no Bedrock AgentCore, recebe a identidade do usuário do serviço que chama e a vincula a cada ferramenta. Foi lançado sem dados fiscais de clientes, de propósito.
Ouça este artigo · 4 min
Narração completa do artigo, gerada por IA.
Peça a um agente para “abrir um ticket de suporte para a minha conta” e uma pergunta silenciosa se esconde ali dentro: qual conta? Em muitos projetos de agente, a resposta é qualquer identidade que o modelo repassa para a ferramenta. Se o prompt puder influenciar esse parâmetro, um usuário pode pedir a conta de outra pessoa e às vezes conseguir.
A Taxbit, plataforma de compliance fiscal e contábil para ativos digitais usada por exchanges, empresas de pagamento e corretoras, publicou o design do seu assistente em produção, o Taxbit Assist, e a decisão de identidade é a parte que todo time enterprise deveria copiar.
O modelo nunca manipula a identidade
O Taxbit Assist roda no Amazon Bedrock AgentCore e é construído com o Strands Agents SDK. Quando uma requisição chega, o serviço confiável que chamou o agente fornece o email do usuário, o ID da organização e os papéis. A Taxbit vincula esses valores a cada ferramenta quando as ferramentas são criadas, usando uma técnica de programação chamada closure. A ferramenta já sabe de quem é a requisição que está atendendo. O modelo pode decidir chamá-la, mas não há parâmetro pelo qual o modelo possa indicar outro usuário.
O que o modelo do Taxbit decide, e o que ele não pode
O modelo escolhe
- Qual ferramenta chamar
- O que buscar
- Como formular a resposta
Probabilístico
O código confiável define
- Quem é o usuário
- Qual organização
- Quais papéis se aplicam
- Qual memória de sessão
Vinculado antes de o modelo rodar
A memória de conversa segue a mesma regra: o histórico é particionado por memória, sessão e ID do ator, então o contexto de um usuário não pode aparecer na sessão de outro.
Uma primeira versão deliberadamente restrita
A segunda decisão é mais fácil de passar despercebida. Nesta versão, o Taxbit Assist não tem acesso de leitura aos dados fiscais de clientes. Ele responde com base no conhecimento do produto, e a única coisa que escreve são os tickets de suporte do próprio usuário que faz a chamada.
A base de conhecimento combina três fontes: conteúdo publicado (site, documentação da API e central de ajuda) rastreado periodicamente, documentação gerada a partir do código-fonte do produto e artigos escritos manualmente. A recuperação é ajustada com cuidado: 75 candidatos da busca vetorial, reordenados para 12, um limite de dois trechos por documento de origem e cinco enviados ao modelo. Os guardrails filtram cada turno do usuário, mascaram dados pessoais e bloqueiam segredos por completo.
A residência de dados é tratada na inferência: perfis de inferência entre regiões mantêm as requisições europeias na Europa e as requisições dos EUA nos EUA, e os clientes podem usar as próprias chaves de criptografia.
A Taxbit relata que mais de 55% dos usuários que fazem uma pergunta ao Assist voltam com outra pergunta dentro de 24 horas. Essa é uma medida de engajamento, não de precisão, mas sugere que o escopo restrito é útil.
O que copiar
Vincule a identidade no código, não no prompt. Qualquer ferramenta que acesse dados específicos do usuário deve receber a identidade do usuário a partir da sessão autenticada, definida antes de o modelo rodar. Se o schema da sua ferramenta tem um parâmetro user_id que o modelo preenche, essa é a vulnerabilidade.
Coloque em produção primeiro sem dados de tenant. Conhecimento do produto mais os tickets do próprio usuário já bastam para ser útil, e os modos de falha são leves. Adicione acesso aos registros de clientes depois que a vinculação de identidade tiver sido testada, inclusive por pessoas tentando quebrá-la.
Separe escopo de guardrails. Os guardrails capturam conteúdo ruim. O conjunto restrito de ferramentas é o que limita o dano. Eles fazem trabalhos diferentes.
Este é o mesmo princípio que descrevemos para o MCP, em que toda chamada de ferramenta precisa de um nome por trás, aplicado dentro de uma única aplicação. E combina com o que a MoEngage fez com 400 APIs: a decisão de design mais importante é o que cada agente nunca vê.