El agente de Taxbit elige herramientas, nunca de quién es la cuenta. La identidad se vincula antes del modelo

Pida a un agente que “abra un ticket de soporte para mi cuenta” y una pregunta silenciosa se esconde dentro: ¿qué cuenta? En muchos diseños de agentes, la respuesta es la identidad que el modelo pasa a la herramienta. Si el prompt puede influir en ese parámetro, un usuario puede pedir la cuenta de otra persona y a veces obtenerla.

Taxbit, una plataforma de cumplimiento fiscal y contable para activos digitales que usan exchanges, empresas de pago y brokers, publicó el diseño de su asistente en producción, Taxbit Assist, y la decisión sobre la identidad es la parte que todo equipo empresarial debería copiar.

El modelo nunca maneja la identidad

Taxbit Assist se ejecuta en Amazon Bedrock AgentCore y está construido con Strands Agents SDK. Cuando llega una solicitud, el servicio de confianza que llama al agente proporciona el correo electrónico, el ID de organización y los roles del usuario. Taxbit vincula esos valores en cada herramienta cuando se crean las herramientas, mediante una técnica de programación llamada clausura (closure). La herramienta ya sabe a quién está sirviendo. El modelo puede decidir llamarla, pero no hay ningún parámetro a través del cual el modelo pueda nombrar a otro usuario.

Lo que decide el modelo de Taxbit y lo que no puede

El modelo elige

• Qué herramienta llamar
• Qué buscar
• Cómo redactar la respuesta

Probabilístico

El código confiable fija

• Quién es el usuario
• Qué organización
• Qué roles aplican
• Qué memoria de sesión

Vinculado antes de que se ejecute el modelo

La memoria de conversación sigue la misma regla: el historial se divide por memoria, sesión e ID de actor, de modo que el contexto de un usuario no puede aparecer en la sesión de otro.

Una primera versión deliberadamente acotada

La segunda decisión es más fácil de pasar por alto. En esta versión, Taxbit Assist no tiene acceso de lectura a los datos fiscales de los clientes. Responde a partir del conocimiento del producto y lo único que escribe son los tickets de soporte del propio usuario que hace la llamada.

La base de conocimiento combina tres fuentes: contenido publicado (sitio web, documentación de la API y centro de ayuda) rastreado según un calendario, documentación generada a partir del código fuente del producto y artículos escritos a mano. La recuperación está ajustada con cuidado: 75 candidatos de búsqueda vectorial, reordenados a 12, un límite de dos fragmentos por documento de origen y cinco que se pasan al modelo. Los guardrails examinan cada turno del usuario, enmascaran datos personales y bloquean secretos sin excepción.

La residencia de datos se gestiona en la inferencia: los perfiles de inferencia entre regiones mantienen las solicitudes europeas en Europa (la parte que importa para el RGPD) y las solicitudes de EE. UU. en EE. UU., y los clientes pueden aportar sus propias claves de cifrado.

Taxbit informa que más del 55% de los usuarios que hacen una pregunta a Assist vuelven con otra en menos de 24 horas. Es una medida de interacción, no de precisión, pero sugiere que el alcance acotado es útil.

Qué copiar

Vincule la identidad en el código, no en el prompt. Cualquier herramienta que toque datos propios del usuario debe recibir la identidad del usuario desde la sesión autenticada, establecida antes de que se ejecute el modelo. Si el esquema de su herramienta tiene un parámetro user_id que el modelo rellena, esa es la vulnerabilidad.

Lance primero sin datos de tenant. El conocimiento del producto más los tickets del propio usuario bastan para ser útil, y los modos de fallo son leves. Añada acceso a los registros de clientes una vez probada la vinculación de identidad, incluso por personas que intenten romperla.

Separe el alcance de los guardrails. Los guardrails atrapan contenido malo. El conjunto acotado de herramientas es lo que limita el daño. Hacen trabajos distintos.

Este es el mismo principio que describimos para MCP, donde cada llamada a una herramienta necesita un nombre detrás, aplicado dentro de una aplicación. Y coincide con lo que MoEngage hizo con 400 API: la decisión de diseño más importante es lo que cada agente nunca ve.