AI Agent Identity for eCommerce: Who Is Calling the Tool (2026)
Quick summary: Three identities, not one token. The workload role, the shopper or associate, and the downstream API account. A shared admin credential fails the split. AgentCore Identity does not replace your order-system scopes.
Key Takeaways
- The workload role, the shopper or associate, and the downstream API account
- On 25 September 2026, "agent identity" in an eCommerce stack is three questions that teams collapse into one API key: 1
- Which workload is running (the IAM role or runtime identity)
- 2
- 3
Table of Contents
On 25 September 2026, “agent identity” in an eCommerce stack is three questions that teams collapse into one API key:
- Which workload is running (the IAM role or runtime identity)?
- Which human is it acting for (shopper, associate, or nobody)?
- Which downstream account is allowed to call Shopify, Adobe Commerce, or BigCommerce?
Who this is for. A CTO or security partner reviewing a design. The policy around writes is securing agents on the store. This page is only the names on the credentials.
Our take: if you cannot point to three credentials, you have one over-powered token. Do not add a write.
The three credentials
| Credential | Answers | Must not |
|---|---|---|
| Workload role | This runtime may call Gateway, logs, and its secret | Be a human’s IAM user with access keys |
| Caller claims | shopper or associate, stable subject id | Be a string the model typed |
| Store API account | Reads this workflow needs | Include refunds “for later” |
Bedrock AgentCore has an Identity component in the same product family as Runtime and Gateway (GA 13 October 2025 for the platform). Use it, or your IdP, to verify the caller. It does not grant Magento resources. Those are still an Adobe integration. Harness (GA 17 June 2026) does not change that split.
On the store side, follow the platform page: Shopify scopes, Adobe integrations, BigCommerce API accounts.
How a tool should check
Before getOrder:
- The workload role is the one deployed for this agent. A developer laptop role fails closed in production.
- The verified subject is present. Anonymous storefront chat gets a narrower tool list than an associate.
- The order id is in the set that subject may see, or the associate claim is present and your policy allows any order. The model does not make that decision.
- The store token used is the read account.
A refund tool, if it exists at all, requires the associate claim and a human approval record and a policy allow. Any missing leg is a deny. Log the deny. The prompt’s apology is irrelevant.
What people confuse with identity
- MCP OAuth (spec 2025-11-25) proves a client may open your MCP server. See MCP security. It is not the shopper.
- Cognito admin APIs in the aws-auth skill post are about changing user pools. They are not a commerce role model.
- Memory. A fact like “prefers ground shipping” is not an authorization. Do not store tokens there.
- Service accounts named after a person. When that person leaves, you will be afraid to rotate the token. Name it after the workflow.
What broke — Support and purchasing shared a Gateway target because “it was already authed.” A support session passed a SKU and the purchasing tool drafted a PO. Detection: the trace showed one role and two tool catalogs. Fix: split targets and split store credentials. Lesson: identity scoped to the gateway, with every tool behind it, is not least privilege.
If you only do one thing
Label the three secrets in the design review. If a box says “admin token,” stop.
What to do this week
- Draw workload, caller, and store account. No arrows that skip a box.
- Issue a read-only store credential for the one workflow.
- Reject tool calls that do not carry a verified subject.
- Rotate anything a prompt or a memory record has seen.
- Readiness under 16 out of 30 still means no write, even with perfect identity. The rubric is the readiness assessment.
- Discuss the architecture. Identity work sits with eCommerce AI agents and, when the control is the point, the security practice.
What this post doesn’t cover
- A full IAM Identity Center build. That is account access for humans.
- Customer account takeover detection.
- A claim that AgentCore Identity is a commerce IdP. It is not, on the documentation we ship against.
Frequently asked questions
When should you NOT use one admin API token for every agent?
What could go wrong if the shopper id is only in the prompt?
Is Amazon Cognito the agent?
What could go wrong if AgentCore Memory stores the access token?
Does MCP authorization replace this?
Reference bounds
How the who is calling the tool stays bounded
Level 2 — reference architecture. Risk critical. Oversight: human control.
Name the principal on every tool call: shopper, associate, or service.
Explore, then act, then confirm, then verify. Explore gathers the context for the who is calling the tool. Act stays reversible. Confirm stops before an irreversible step. Verify is a separate check of the outcome.
- Starts when
- A store agent is about to call an API.
- Tools
- A write goes through a router, a permission check, a policy check, and a budget check. The model does not commit it. An approval token lives in tool context, not in the user message.
- Stops for a person
- A shared service account is not a substitute for the human on an irreversible write.
- Checked by
- The token role matches the tool. A shopper principal is denied associate writes.
- Untrusted data
- Requests that ask the agent to impersonate another user or tenant.
- If it fails
- If the who is calling the tool stops, name the reason: completed, budget_exceeded, timed_out, cancelled, guardrail_blocked, approval_required, tool_failure, verification_failed, or partial_completion. Retry a timeout at most twice. Back off on rate limits. After repeated verification failure, escalate. Stop when the budget is exhausted or a permission is denied. No unbounded loop. A shared service account is not a substitute for the human on an irreversible write.
This is the reference architecture for the page, not a published production deployment. The shared contract is the AWS store-agent architecture. Permissions and data boundaries are in securing store agents.
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
