Amazon Cognito
Merchant sign-in, tokens, MFA and session-risk signals
AWS service architecture + incident path
The service map names the AWS building blocks and their purpose. The attack-path map below shows how the compromised merchant session moves across those boundaries.
Architecture at a glance
AWS managed service labels distinguish cloud services from Roaming Bites application components and external providers.
Merchant sign-in, tokens, MFA and session-risk signals
Campaign requests, tenant checks and context assembly
Tool policy, job state and ECS task creation
Five-minute tool workspace running the campaign job
Orchestrator, task, execution and EC2 node roles
Authorizes AWS actionsKeeps provider tokens away from the workspace
Uses the merchant's Google grantLLM inference requested by the application
Called by the orchestratorApproved tenant-scoped campaign artifacts
Read and written by scoped rolesRunTaskScope of this map: the evidence identifies the Campaign Assistant as an application and shows the AWS services it calls, but it never identifies how its web tier or business database are hosted. Those parts are therefore shown as logical Roaming Bites components rather than being labelled as API Gateway, Lambda, CloudFront, DynamoDB or another guessed implementation. This does not mean a web host or database is absent—only that participants do not need an invented service choice to investigate this incident.
Interactive incident path
Choose a phase, then select a node to inspect its runtime, service identity, permissions and evidence. The architecture above highlights the same phase.
A stolen password creates a valid merchant session and reaches the normal campaign workspace.