Taxbit's agent picks its tools, never whose account it uses. Identity is bound before the model runs

Ask an agent to “open a support ticket for my account” and a quiet question hides inside: which account? In many agent designs, the answer is whatever identity the model passes to the tool. If the prompt can influence that parameter, a user can ask for someone else’s account and sometimes get it.

Taxbit, a tax and accounting compliance platform for digital assets used by exchanges, payment companies and brokers, published the design of its production assistant, Taxbit Assist, and the identity decision is the part every enterprise team should copy.

The model never handles identity

Taxbit Assist runs on Amazon Bedrock AgentCore and is built with the Strands Agents SDK. When a request arrives, the trusted service that called the agent supplies the user’s email, organization ID and roles. Taxbit binds those values into each tool when the tools are created, using a programming technique called a closure. The tool already knows whose request it is serving. The model can decide to call it, but there is no parameter through which the model could name another user.

What Taxbit's model decides, and what it cannot

The model chooses

• Which tool to call
• What to search for
• How to phrase the answer

Probabilistic

Trusted code fixes

• Who the user is
• Which organization
• Which roles apply
• Which session memory

Bound before the model runs

Conversation memory follows the same rule: history is partitioned by memory, session and actor ID, so one user’s context cannot surface in another’s session.

A deliberately narrow first version

The second decision is easier to overlook. In this version, Taxbit Assist has no read access to customer tax data. It answers from product knowledge, and the only thing it writes is the caller’s own support tickets.

The knowledge base combines three sources: published content (website, API documentation and help center) crawled on a schedule, documentation generated from the product’s source code, and articles written by hand. Retrieval is tuned with care: 75 candidates from vector search, reranked to 12, a cap of two chunks per source document, and five passed to the model. Guardrails screen each user turn, mask personal data and block secrets outright.

Data residency is handled at inference: cross-Region inference profiles keep European requests in Europe and U.S. requests in the U.S., and customers can bring their own encryption keys.

Taxbit reports that more than 55% of users who ask Assist a question come back with another within 24 hours. That is an engagement measure, not an accuracy one, but it suggests the narrow scope is useful.

What to copy

Bind identity in code, not in the prompt. Any tool that touches user-specific data should receive the user’s identity from the authenticated session, set before the model runs. If your tool schema has a user_id parameter the model fills in, that is the vulnerability.

Ship without tenant data first. Product knowledge plus the user’s own tickets is enough to be useful, and the failure modes are mild. Add access to customer records once the identity binding has been tested, including by people trying to break it.

Separate scope from guardrails. Guardrails catch bad content. The narrow tool set is what limits damage. They do different jobs.

This is the same principle we described for MCP, where every tool call needs a name behind it, applied inside one application. And it matches what MoEngage did with 400 APIs: the most important design choice is what each agent never sees.