AWS shows how ServiceNow agents can preserve user identity

The published integration pattern

AWS published its ServiceNow on-behalf-of token exchange walkthrough on 3 November. The architecture connects an agent application, Microsoft Entra ID, Bedrock AgentCore Gateway and the ServiceNow REST API.

The gateway exchanges the incoming user token for a token scoped to the downstream connector. ServiceNow maps the resulting identity to an existing user and applies that user’s permissions. AWS says the exchange is configured on the gateway target and performed on each request, without an interceptor Lambda or custom exchange code.

This is implementation guidance for a particular architecture, not a claim that every deployed agent already preserves identity. Organizations still need to configure their identity applications, downstream access and mappings correctly. Source: ServiceNow on-behalf-of token exchange with Bedrock AgentCore Gateway

Analysis: tool access should not become shared privilege

An assistant often feels like a single interface, but an action can cross several services before it changes a record. If the downstream application sees only a broadly privileged service account, the user-facing assistant and the actual permission boundary can diverge. The proposed pattern matters because it keeps the person’s identity attached to that chain.

Consider an illustrative service desk where two employees have different access to sensitive incidents. The agent should not make those differences disappear merely because both employees can open the same chat interface. A useful test would have each employee request the same protected record and verify that the downstream system makes the intended access decision.

Authentication does not settle whether an action is appropriate. A user may legitimately have permission to modify a record while the assistant misunderstands the requested modification. Identity propagation and action review answer different questions: whose access applies, and whether this action matches the user’s intention.

A readable audit entry also needs more than a username. Reviewers should be able to relate the initiating request, the selected tool and the downstream outcome. That means deciding what evidence is necessary to explain a business action and handling it under the organization’s controls, rather than storing conversations indiscriminately.

What to test before using it for writes

Begin with read-only calls and two accounts with deliberately different permissions. Verify successful access, denied access and the identity recorded downstream. Test token expiration, revoked access and an account with no matching ServiceNow user. A failure should be visible and should not trigger a fallback to a more privileged identity.

Next, evaluate a narrow write operation with an explicit confirmation step in the application design. Check that the record, requested change and acting user remain consistent through the exchange. If the model picks the wrong record, a correct authentication flow should not be mistaken for a successful task.

These checks are recommendations, not results from a deployment we have run. The AWS article offers a concrete implementation path, but the organization deploying it remains responsible for validating behavior in its own tenant and access model.

Include a test in which the user’s access changes between starting the conversation and attempting the tool call. The desired result should be defined by the organization’s access policy, not inferred from what the model remembers about an earlier successful request. This exposes whether cached assumptions have become a substitute for a current authorization decision. It is especially useful when evaluating long-running tasks that may outlast a normal interactive session.

The larger implication is that agent engineering includes identity engineering. A more capable model cannot compensate for a tool that ignores the caller’s permissions. For teams moving beyond demonstrations, preserving identity at the system that owns the data is a more meaningful milestone than simply showing that the assistant can call another API.