A shared service account cannot tell one rep's pipeline from another's

Maya covers the Americas. On Monday she asks her personal agent (Claude CoWork) for this quarter’s forecast, and the answer includes Erik’s EMEA deals. Nothing was hacked. The agent reads the CRM through one shared service account, that account can see every region, and so can anything that borrows it. When the sales director asks who looked at the EMEA pipeline last week, the CRM log says “forecast-app” and stops there.

I built the version where Maya’s agent sees only her regions and the log names her. The surprise was in what the data source learned: the person and the gateway that called, and never which agent.

One account holds the whole team’s rights

A shared account is the easy way to connect an agent to company data, and it has the rights of the whole team added together. Every user inherits the union of what any user could see. The data source records the account as the caller, so the question “whose request read these rows?” has no answer.

The same shape has gone wrong at larger scale. In August 2025, attackers used stolen tokens from a chatbot vendor’s integration to query customers’ CRM tenants and export support cases, contacts and account details. Anomali’s recap puts the reach at more than 700 organizations, though it notes the count varies by source. One broadly permissioned integration held one set of tokens, and the tokens opened hundreds of tenants.

Per-person identity does not stop a hijacked agent from using its own user’s access. It limits the damage to that one person’s rows and puts that person’s name in the log.

What it should look like

Four parts are involved: Maya, the identity provider that signs her in, the agent she talks to, and the data source. The obvious fix is to forward Maya’s sign-in token to the data source. The MCP authorization spec rules that out for servers that call upstream APIs: they “MUST NOT pass through the token it received from the MCP client.”

The alternative is a swap. The agent presents token A, which says “Maya, meant for the agent.” A gateway trades it at the identity provider for token B, which says “still Maya, meant only for the sales API, valid five minutes.” The trade is RFC 8693 token exchange, and Amazon Bedrock AgentCore Gateway can run it. A hotel works the same way: the lobby key card is swapped at the desk for one that opens a single room. The comparison breaks at one point, which is where this post ends up: a hotel key does not say who carried it.

The data source checks the person

Token B carries Maya’s regions. The sales API verifies the token, reads the regions from it, and sets them on the database transaction. Row-level security in the database does the rest, so a request for EMEA returns nothing from EMEA even if the agent asks for it.

I ran three people through the same questions: Maya on the Americas, Erik on EMEA, and Priya on all four regions. Each saw their own rows and no one else’s. A second route that skipped the swap and used the gateway’s plain service credentials got a 403 on every request.

Under load the picture held. Across five rounds of 50 concurrent calls from the three people, 249 returned the right rows, none returned another person’s rows, and one returned an error. Every call through the gateway also matched a record at the identity provider (40 of 40 in the final check), so the swap happened on each call and was not skipped.

What the data source still cannot tell

I expected the data source to learn two things on each request: who is asking, and which agent acts for them. Token B carried the first. The acting party in it was the gateway’s own client, and the agent appeared only in token A.

The AWS docs say the exchanged token “carries both the agent’s own identity and the original caller’s identity.” In my run the gateway sent no actor token. The docs describe that mode as one for providers that derive the actor “from client authentication alone,” and the client doing the authenticating is the gateway. An AWS builder post on the two-step pattern says the same thing: “whatever the IdP stamps into act describes the Gateway, not the Agent that made the call.” Its fix is a second exchange run by the agent, so the gateway’s token nests the agent inside it.

I did not test that fix or the other two actor modes the docs list. For my setup the consequence is plain: two different agents using the same gateway leave identical entries at the CRM. The log says “Maya, through the gateway.” It cannot say which agent she used.

Which pattern fits

Token exchange fits some cases and not others. These questions sort most of them:

Where this stops

• I ran this against a purpose-built identity provider with generated data for three people in one account and one region. The pattern does not depend on either, but Auth0, Okta and Entra were not tested.
• The database never sees Maya. The API trusts the region claim after verifying the token’s signature, audience and marker claims, then sets it on the transaction. That is app-asserted identity with a database-enforced rule, which is weaker than a warehouse that sees the person.
• Which agent acted is unresolved, as above.

What to check on Monday

If a personal agent can reach your CRM, look at what the data source logs as the caller. A service account name means you cannot answer “who saw this pipeline,” and a hijacked agent can read everything the account can. Per-person token exchange fixes both, for the person. Which agent acted needs its own design.

The question I could not answer is Maya’s next quarter. When she moves to EMEA mid-year and the production identity provider decides what her swapped token may carry, how fast does the old Americas access stop? I measured the gateway’s side of that. I have not seen what a production provider does with it.