# Chaperone: every recorded session Real sessions from one AWS account, recorded by CloudTrail, newest first. Identifiers are masked (the account shows as 111122223333). Generated 2026-10-02T13:04Z from https://chaperone.fullstackfusions.com/api/sessions; each summary was written once per session by Amazon Bedrock from the recorded calls. Risk classes come from fixed rules, not a model. 23 sessions, 14 by an AI agent (Claude Code through the AWS MCP Server), 8,668 AWS calls. ## chaperone-agent (AI agent), 2026-10-02T12:52:25Z, 11 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-10-02T12%3A52%3A25Z - 181 AWS calls, 0 MCP tool calls; by risk: write 2, read 179 - Riskiest: write **Agent read across 12 AWS services and invalidated one CloudFront distribution cache.** Over about nine minutes, the agent made 177 API calls, of which 175 were reads spanning ACM, CloudFront, CloudTrail, DynamoDB, EC2, EventBridge, IAM, Lambda, CloudWatch Logs, S3, SSO, and STS. The only two writes were an SSO token creation at the start of the session and a CloudFront cache invalidation against distribution EDFDVBD6EXAMPLE. No resources were created or deleted. The session ended cleanly with no errors or denied calls. Key moments: - 12:52:25 Session opened with an SSO token creation against directory d-0000000000 via the AWS CLI. - 12:52:25 A broad read survey began across 12 services, accounting for 175 of the 177 total calls. - 12:56:58 A cache invalidation was submitted for CloudFront distribution EDFDVBD6EXAMPLE, the only infrastructure-affecting change in the session. - 13:01:36 Session ended after 9.2 minutes with no errors, no denials, and no resources created or deleted. Risk: No calls were classified above a plain write: there were no destructive, public-exposure, identity-escalation, or audit-tampering events. The two writes - an SSO token and a CloudFront invalidation - are low-impact operations. The CloudFront invalidation forces edge caches to refresh but does not alter the underlying content or access controls of the distribution. Access: The role held AdministratorAccess through an Identity Center permission set (all actions allowed), but the session used only 53 distinct IAM actions across 12 services. ## root (person), 2026-09-30T22:30:49Z, 7 min - Page: https://chaperone.fullstackfusions.com/session/root%402026-09-30T22%3A30%3A49Z - 163 AWS calls, 0 MCP tool calls; by risk: read 163 - Riskiest: read **Root user spent six minutes reading billing, cost, and account data across 22 services.** Over about six and a half minutes, the root user made 163 read-only API calls across 22 AWS services, covering billing, cost management, budgets, Cost Explorer, free-tier status, organizations, Security Hub, CloudTrail, Config, and several others. No resources were created, modified, or deleted during the session. Two calls were denied and eight returned errors, but nothing progressed beyond reads. The session was driven entirely through a human console channel with no MCP tool calls. Key moments: - 22:30:49 Root user began the session and started issuing read calls across billing and account services. - 22:31:00 Calls spread to Cost Explorer, budgets, and the cost-optimization-hub, consistent with reviewing spend and savings opportunities. - 22:33:00 Reads extended into CloudTrail, Config, and Security Hub, suggesting a review of compliance and audit posture. - 22:35:00 Two API calls were denied and eight returned errors; none of these unlocked further activity. - 22:37:20 Session ended after 163 read calls with no changes made. Risk: All 163 calls were classified as read. No destructive, public-exposure, identity-escalation, or audit-tampering calls were recorded, and no risky flags were raised. The session posed no change risk to the account. Access: No granted policy was recorded for this identity, so what was allowed cannot be stated. The session used 58 distinct IAM actions spanning 22 services, all reads. ## chaperone-agent (AI agent), 2026-09-28T20:38:23Z, 0 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-28T20%3A38%3A23Z - 5 AWS calls, 0 MCP tool calls; by risk: read 4, write 1 - Riskiest: write **Agent submitted one CloudFront cache invalidation against an existing distribution.** In under a minute, the session made five API calls through the agent channel: four reads and one write. The single write was a cache invalidation submitted to an existing CloudFront distribution. No resources were created or deleted, and no calls were flagged as risky. The session ended cleanly with no errors or denials. Key moments: - 20:38:23 Session opened under the AWSReservedSSO_ChaperoneAgent role via Identity Center. - 20:38:49 A cache invalidation was submitted to CloudFront distribution EDFDVBD6EXAMPLE in us-east-1 via the AWS CLI. Risk: No calls were classified as destructive, publicly exposing, identity-escalating, or audit-tampering. The only write was a CloudFront cache invalidation, which flushes cached content from an existing distribution but does not alter its configuration or permissions. Access: The role held AdministratorAccess through an Identity Center permission set, granting all actions. The session used only 2 actions across 2 services (CloudFront and STS). ## chaperone-agent (AI agent), 2026-09-28T19:43:44Z, 3 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-28T19%3A43%3A44Z - 211 AWS calls, 0 MCP tool calls; by risk: write 7, read 204 - Riskiest: write **Agent deployed updates to three Lambda functions and a CloudFront cache policy over about three minutes.** The chaperone-agent role, acting through an AWS SSO Identity Center session, applied Terraform-driven updates to a CloudFront cache policy and the code for three Lambda functions (chaperone-poller, chaperone-ingest, and chaperone-api) in us-east-1. It then issued a CloudFront invalidation against distribution EDFDVBD6EXAMPLE via the CLI, likely to flush cached content after the deployment. Two SSO token creation calls bookended the session. All 211 API calls completed without errors or denials, and no resources were created or deleted. Key moments: - 19:43:44 Session opened with the first of two SSO token creation calls against Identity Center directory d-0000000000. - 19:45:04 A second SSO token was created, likely a refresh ahead of the Terraform apply. - 19:45:44 Terraform updated the CloudFront cache policy and deployed new code to the chaperone-poller Lambda. - 19:45:50 Terraform deployed new code to the chaperone-ingest Lambda. - 19:45:57 Terraform deployed new code to the chaperone-api Lambda. - 19:46:28 A CloudFront invalidation was submitted via the CLI against distribution EDFDVBD6EXAMPLE to clear stale cached content. Risk: No calls were flagged above a plain write: there were no destructive, public-exposure, identity-escalation, or audit-tampering events. The seven write-class calls were all standard deployment operations — updating existing Lambda function code and a cache policy, and submitting a cache invalidation. Access: The identity held AdministratorAccess (all actions) through an Identity Center permission set, but used only 55 distinct IAM actions across 12 services during the session. ## chaperone-agent (AI agent), 2026-09-28T17:04:31Z, 19 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-28T17%3A04%3A31Z - 231 AWS calls, 8 MCP tool calls; by risk: write 7, read 224 - Riskiest: write **Agent deployed updated Lambda functions and wrote DynamoDB records over 19 minutes.** The agent authenticated via SSO, then spent most of the session reading: it queried CloudTrail events and scanned DynamoDB tables, touching 20 AWS services across 224 read calls. At 17:17 it wrote data to DynamoDB using BatchWriteItem across 18 API calls. Near the end of the session it deployed new code to three Lambda functions — chaperone-ingest, chaperone-api, and chaperone-poller — all in us-east-1, through Terraform. No resources were created or deleted. The session ended cleanly with one final DynamoDB query. Key moments: - 17:04:31 Agent signed in via SSO in us-east-2 and obtained credentials. - 17:06:38 SSO tokens were created twice over the session (first at 17:06, again at 17:21) against Identity Center instance d-0000000000. - 17:11:59 Agent began querying CloudTrail LookupEvents, making two calls. - 17:17:05 Agent scanned DynamoDB tables and wrote records using BatchWriteItem across 18 API calls. - 17:21:42 Via Terraform, the agent pushed updated function code to chaperone-ingest, chaperone-api, and chaperone-poller in us-east-1 within 12 seconds. - 17:23:53 Session closed after a final DynamoDB query with no further changes. Risk: All seven write-class calls fall into the plain-write category; no destructive, public-exposure, identity-escalation, or audit-tampering flags were raised. The DynamoDB BatchWriteItem calls modified existing table data, but the record does not show which table or what data was written. The three Lambda UpdateFunctionCode calls replaced code on pre-existing functions that were not created during this session. One call was denied and one produced an error, though neither is detailed further in the record. Access: The role held AdministratorAccess (Action: *) through an Identity Center permission set. Of that broad grant, the agent used 68 distinct actions across 20 services. ## chaperone-agent (AI agent), 2026-09-27T21:43:30Z, 72 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-27T21%3A43%3A30Z - 18 AWS calls, 3 MCP tool calls; by risk: write 7, read 10, destructive 1 - Riskiest: destructive (sqs:DeleteQueue removes or stops a resource) **Agent authenticated via SSO, invalidated a CloudFront distribution, and created then deleted a test SQS queue.** Over about 51 minutes the agent authenticated through AWS IAM Identity Center (three authorization-pending retries before succeeding), issued a CloudFront invalidation against an existing distribution, and then — near the end of the session — created an SQS queue named chaperone-demo-queue and deleted it within the same second. All activity came through the agent channel, with the three MCP tool calls at the end using the aws___run_script tool. The session ended with no denied calls and three errors, all of which were the expected SSO authorization-pending responses during device-code login. Key moments: - 21:43:30 SSO token creation began; the first three attempts returned AuthorizationPendingException before succeeding on the fourth try at 21:43:34Z. - 21:43:34 SSO authentication succeeded and the session was established. - 21:48:56 A CloudFront invalidation was submitted against distribution EDFDVBD6EXAMPLE, clearing cached content. - 22:29:56 The first two MCP aws___run_script tool calls were made but triggered no AWS API calls, likely running local or inspection commands. - 22:30:13 The third aws___run_script call created the SQS queue chaperone-demo-queue and immediately deleted it in the same API batch. Risk: There is one destructive call: sqs:DeleteQueue against chaperone-demo-queue. The queue was created by this same session moments before it was deleted, so no pre-existing resource was removed. The create-and-delete pattern within the same second, under a name containing 'demo', is consistent with a connectivity or permission test rather than unintended data loss. Access: The role held AdministratorAccess (Action: *) through an Identity Center permission set, but the session used only 5 actions across four services (sso, sts, cloudfront, sqs). ## admin (person), 2026-09-27T21:24:54Z, 16 min - Page: https://chaperone.fullstackfusions.com/session/user%2Fadmin%402026-09-27T21%3A24%3A54Z - 883 AWS calls, 0 MCP tool calls; by risk: read 882, write 1 - Riskiest: write **Admin browsed AWS account and submitted a Bedrock model-access use-case form.** Over 16 minutes, the admin performed 882 read operations across 18 AWS services, covering billing, cost, organizations, S3, EC2, SageMaker, Bedrock, SSO, and several others, all through the AWS console. The only write in the session was submitting a use-case declaration for Bedrock model access, which is a prerequisite step when requesting access to certain foundation models. No resources were created or deleted. The session ended cleanly with no denials and six minor errors. Key moments: - 21:24:54 Session opened via the AWS console and broad read activity began across billing, cost, and account services. - 21:24:54 Read calls spanned 18 services including organizations, SSO, EC2, S3, SageMaker, Resource Explorer, and free-tier, suggesting a general account review. - 21:38:44 A single write was made: bedrock:PutUseCaseForModelAccess in us-east-1, submitting a use-case form to request Bedrock model access. - 21:40:52 Session closed after 16 minutes with no denied calls and no resources created or deleted. Risk: There were no risky calls in this session. The one write action, submitting a Bedrock model-access use-case form, is an account-level configuration step and was not flagged under any risk class. No destructive, public-exposure, identity-escalation, or audit-tampering actions occurred. Access: The identity's granted permissions are not recorded. The session used 62 distinct IAM actions across 18 services. ## chaperone-agent (AI agent), 2026-09-27T12:52:47Z, 0 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-27T12%3A52%3A47Z - 4 AWS calls, 0 MCP tool calls; by risk: write 4 - Riskiest: write **Agent obtained an SSO token after three authorization-pending retries.** This three-second session used the agent channel to acquire an AWS IAM Identity Center token against the SSO instance d-0000000000 in us-east-1. The agent called sso:CreateToken four times in total: the first three attempts returned AuthorizationPendingException, indicating the device-authorization flow had not yet been approved, and the fourth call succeeded. No resources were created or deleted, and no reads were recorded. The session ended immediately after the token was issued. Key moments: - 12:52:47 First sso:CreateToken attempt against SSO instance d-0000000000 returned AuthorizationPendingException. - 12:52:49 Two further retries also returned AuthorizationPendingException, completing the three failed attempts. - 12:52:50 Fourth sso:CreateToken call succeeded and the session ended. Risk: All four calls were classified as writes; none were flagged as destructive, publicly exposing, identity-escalating, or audit-tampering. The only action taken was polling for an SSO token, which is a normal step in a device-authorization flow. No resources belonging to this session or any pre-existing resources were modified or deleted. Access: The role held AdministratorAccess (Action: *) through an Identity Center permission set, but the session used only one distinct action - sso:CreateToken - across one service. ## admin (person), 2026-09-27T12:49:01Z, 5 min - Page: https://chaperone.fullstackfusions.com/session/user%2Fadmin%402026-09-27T12%3A49%3A01Z - 61 AWS calls, 0 MCP tool calls; by risk: read 60, write 1 - Riskiest: write **Admin updated the AWS IAM Identity Center SSO configuration during a five-minute session.** Over five minutes, the admin made 61 API calls through the AWS console, 60 of which were reads spread across services including EC2, Organizations, SSO, and Resource Explorer. The single write was an update to the IAM Identity Center (SSO) instance configuration. No resources were created or deleted, and no calls were flagged as destructive, publicly exposing, or otherwise risky. The session ended cleanly with no denied calls and two non-blocking errors. Key moments: - 12:49:01 Session began; the admin started browsing the account through the AWS console. - 12:49:01 Read activity covered nine service areas including Organizations, SSO, EC2, and Resource Explorer over the first two minutes. - 12:51:17 The admin updated the IAM Identity Center SSO instance configuration (ssoins-6684de71d829deb9) in us-east-2. - 12:53:58 Session ended after five minutes with no further writes and no access denials. Risk: There were no calls flagged in any risk category (destructive, public exposure, identity escalation, or audit tampering). The single write updated an existing IAM Identity Center SSO instance configuration rather than creating or deleting anything, and it was not flagged by any rule. Access: The session used 24 distinct IAM actions across nine services; the granted permissions for this identity were not recorded, so it is not possible to assess how much of the allowed scope was used. ## admin (person), 2026-09-27T01:51:20Z, 19 min - Page: https://chaperone.fullstackfusions.com/session/user%2Fadmin%402026-09-27T01%3A51%3A20Z - 38 AWS calls, 0 MCP tool calls; by risk: read 38 - Riskiest: read **Admin ran a 19-minute read-only survey of account health and cost data.** Over about 19 minutes, the admin made 38 read-only API calls and no changes to any resources. The session touched ten services spanning billing, cost optimization, EC2, service quotas, health events, free-tier status, notifications, and resource inventory. All calls were made directly by the admin user with no tool or agent intermediary. The session ended cleanly with no errors, no denied calls, and no risky activity of any kind. Key moments: - 01:51:20 Session opened; admin began querying account and free-tier status information. - 01:55:00 Calls to Cost Explorer and the Cost Optimization Hub retrieved current spending and optimization recommendations. - 02:00:00 Health and notifications services were queried, likely checking for active events or alerts affecting the account. - 02:05:00 Resource Explorer and service-quota lookups gave a broad inventory of resources and current quota usage. - 02:10:43 Session closed after 38 reads with no modifications, deletions, or risky calls recorded. Risk: No risky calls were recorded in this session. Every one of the 38 API calls was classified as a read, and no destructive, public-exposure, identity-escalation, or audit-tampering actions were made. Nothing was created or deleted. Access: The identity used 14 distinct IAM actions across 10 services; the granted policy for this role was not captured in the record, so it is not possible to say how those 14 actions compare to what was allowed. ## chaperone-agent (AI agent), 2026-09-27T01:25:39Z, 160 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-27T01%3A25%3A39Z - 767 AWS calls, 12 MCP tool calls; by risk: write 14, read 751, identity_escalation 2 - Riskiest: identity_escalation (iam:PutRolePolicy grants or assumes more access) **Agent updated Chaperone Lambda functions and inline IAM policy, then invalidated a CloudFront distribution twice.** Over roughly 160 minutes, the agent used its AWS agent channel to inspect Bedrock model availability, service quotas, CloudWatch logs, and cost data, then applied Terraform changes that updated the code and configuration of three Lambda functions (chaperone-api, chaperone-poller, chaperone-ingest) and modified the inline policy on the chaperone-api role. It also set a lifecycle rule on the CloudTrail logs S3 bucket and created four CloudFront cache invalidations against distribution EDFDVBD6EXAMPLE across two separate tool-call pairs. No resources were created or deleted during the session. The session ended cleanly with no denied calls and one error (an AuthorizationPendingException during the initial SSO token request, which immediately succeeded on retry). Key moments: - 01:25:40 SSO token created for Identity Center directory d-0000000000 after one pending-authorization retry. - 01:45:52 Terraform updated the code for all three chaperone Lambda functions and applied a configuration change to chaperone-api. - 01:45:52 Terraform wrote an inline role policy to chaperone-api via iam:PutRolePolicy (first of two applications). - 02:39:06 Terraform set a lifecycle policy on the CloudTrail logs S3 bucket and ran the second round of Lambda code updates. - 03:11:44 Agent created a CloudFront invalidation against distribution EDFDVBD6EXAMPLE and polled until it completed. - 03:28:37 A second CloudFront invalidation was created against the same distribution and confirmed complete, ending the session's writes. Risk: The two identity-escalation calls are both iam:PutRolePolicy writes targeting the chaperone-api role, applied via Terraform at 01:45:52Z and again at 02:39:06Z. The role was not created during this session, so the policy change affected a pre-existing identity rather than a throwaway resource. The record does not show the policy contents, so it is not possible to determine what permissions were added or removed. No public-exposure or audit-tampering calls were recorded. Access: The role held AdministratorAccess (Action: *) through an Identity Center permission set, so no calls could have been denied by policy. Of the 66 distinct IAM actions actually used, they spanned 15 services, a small subset of what the broad grant permitted. ## chaperone-agent (AI agent), 2026-09-26T14:03:33Z, 12 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-26T14%3A03%3A33Z - 354 AWS calls, 1 MCP tool calls; by risk: read 354 - Riskiest: read **Agent performed a 12-minute read-only survey of infrastructure across 12 AWS services.** Over 12 minutes the agent made 354 API calls, all reads, across 12 services including CloudFront, Lambda, S3, IAM, DynamoDB, EC2, and ACM. All activity came through the agent channel. One explicit tool call (aws___run_script) gathered details on budgets, CloudFront distributions and origin access controls, and Lambda configuration including concurrency and function URL settings. No resources were created, modified, or deleted, and the session ended without errors or denied calls. Key moments: - 14:03:33 Session started under the ChaperoneAgent SSO role. - 14:07:12 A run-script tool call issued 22 read API calls covering budgets, CloudFront distributions and origin access controls, and Lambda configuration details. - 14:15:45 Session ended after 12 minutes with 354 read calls and no changes of any kind. Risk: There were no risky calls of any class. Every one of the 354 calls was a read. No resources were created or deleted, no permissions were modified, and no public exposure or identity changes occurred. Access: The role held AdministratorAccess (all actions allowed) through an Identity Center permission set, but the session used only 57 distinct actions across 12 services and never exercised any write or mutating capability. ## chaperone-agent (AI agent), 2026-09-26T12:11:23Z, 60 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-26T12%3A11%3A23Z - 747 AWS calls, 0 MCP tool calls; by risk: write 17, read 730 - Riskiest: write **Agent deployed updates to Chaperone's CloudFront distribution and three Lambda functions via Terraform and CLI.** Over roughly 59 minutes the agent authenticated through AWS IAM Identity Center, then used Terraform to update code for three Lambda functions (chaperone-ingest, chaperone-poller, chaperone-api), create a new CloudFront cache policy and origin access control, publish a CloudFront function for SPA routing, and update the existing CloudFront distribution. It also set reserved concurrency on chaperone-api and added two Lambda resource-based permissions to it. Two CloudFront cache invalidations were issued via the CLI, the second at the very end of the session, likely to flush stale assets after the deployment. The session completed without any denied calls; two errors occurred during the initial SSO token request before authentication succeeded. Key moments: - 12:11:23 The agent attempted to obtain an SSO token twice before succeeding on the third try at 12:11:25Z. - 12:49:57 Terraform created a new CloudFront cache policy and an origin access control (EDFDVBD6EXAMPLE), and deployed updated code to chaperone-ingest. - 12:49:58 Terraform created and immediately published the chaperone-spa-routes CloudFront function; CloudFront's service-linked IAM role was also created at this point by the service itself. - 12:50:10 Code for chaperone-api was updated and its reserved concurrency was set via Terraform. - 12:50:18 Terraform applied changes to the existing CloudFront distribution (EDFDVBD6EXAMPLE), incorporating the new origin access control and cache policy. - 12:53:35 Two CloudFront cache invalidations were issued against distribution EDFDVBD6EXAMPLE via the CLI, the last one at 13:11:00Z closing out the session. Risk: The session contained no calls classified above a plain write: no destructive deletes, no public exposure changes, no identity escalation, and no audit tampering. The one IAM action recorded was iam:CreateServiceLinkedRole initiated by the CloudFront service itself, not directly by the agent, and no roles were passed. All changes targeted either newly created resources or pre-existing Chaperone infrastructure. Access: The actor held AdministratorAccess (Action: *) through an Identity Center permission set. Of that broad grant, the session actually used 64 distinct actions across 12 services, leaving the vast majority of the allowed surface untouched. ## chaperone-agent (AI agent), 2026-09-25T18:28:27Z, 76 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-25T18%3A28%3A27Z - 3365 AWS calls, 27 MCP tool calls; by risk: read 3298, write 61, identity_escalation 6 - Riskiest: identity_escalation (iam:PutRolePolicy grants or assumes more access) **Agent updated Chaperone infrastructure and added a new API Lambda with IAM roles over 76 minutes.** The agent used its scripting channel (3,392 calls total) to inspect existing Chaperone pipeline components via CloudTrail, DynamoDB, and CloudWatch, then applied Terraform to update Lambda function code and configuration for chaperone-ingest and chaperone-poller, modify EventBridge rules across multiple regions, and update the chaperone DynamoDB table. In the second half of the session it created two new IAM roles (chaperone-api and chaperone-access-analyzer), a new Lambda function (chaperone-api) with a function URL, and an associated CloudWatch log group. The session ended with several further code deployments to chaperone-api, chaperone-ingest, and chaperone-poller, all applied through Terraform. Key moments: - 18:28:46 Agent began by querying CloudTrail and DynamoDB to read recent session activity, making 34 API calls across two scripts. - 18:32:11 Terraform applied updates to the chaperone-poller and chaperone-ingest Lambda functions, EventBridge rules, and inline IAM policies for existing roles. - 18:44:08 Terraform updated the chaperone DynamoDB table configuration. - 19:12:49 Terraform created two new IAM roles (chaperone-api and chaperone-access-analyzer) and a CloudWatch log group for the new Lambda. - 19:13:02 Terraform created the chaperone-api Lambda function and attached a function URL to it. - 19:30:27 Agent deployed two further code updates to chaperone-api through Terraform, ending the main change activity. Risk: There were 6 identity-escalation calls, all iam:PutRolePolicy applied via Terraform. Two of these targeted chaperone-poller and one targeted chaperone-ingest, which are pre-existing roles not created in this session. The remaining three calls attached inline policies to chaperone-api and chaperone-access-analyzer, both of which were created earlier in the same session. The record cannot determine the content of the policies written, only that inline policies were set on these roles. Access: The agent used 65 distinct IAM actions across 15 services and passed one role during the session. It held AdministratorAccess through an Identity Center permission set, so all actions were a small subset of what was permitted. ## chaperone-agent (AI agent), 2026-09-25T15:49:07Z, 2 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-25T15%3A49%3A07Z - 216 AWS calls, 2 MCP tool calls; by risk: read 179, write 35, identity_escalation 1, audit_tampering 1 - Riskiest: identity_escalation (iam:PutRolePolicy grants or assumes more access) **Agent deployed Chaperone forwarder infrastructure across 16 regions and modified an existing CloudTrail trail.** Over two minutes, the agent used Terraform to create EventBridge rules named chaperone-forward-api-calls across 16 regions, create an IAM role named chaperone-forwarder with an inline policy, and update the Lambda functions chaperone-poller and chaperone-ingest. All Terraform changes were made through the agent channel. Late in the session, the agent used the AWS MCP server to call cloudtrail:UpdateTrail on an existing trail named chaperone-trail in us-east-2; the record does not show what was changed in that trail. The session completed without any denied calls or errors. Key moments: - 15:49:19 First tool call enumerated available EC2 regions, likely to determine which regions to target for the EventBridge rules. - 15:50:03 Terraform began creating the EventBridge rule chaperone-forward-api-calls, ultimately placing it in 16 regions over the next two seconds. - 15:50:04 Terraform created the IAM role chaperone-forwarder and immediately attached an inline policy to it via iam:PutRolePolicy. - 15:50:06 Terraform added targets to the 16 EventBridge rules, completing the forwarding rule configuration across all regions. - 15:50:10 Terraform updated the code of the Lambda function chaperone-ingest in us-east-1. - 15:50:28 The agent called cloudtrail:UpdateTrail via the MCP server on the pre-existing trail chaperone-trail in us-east-2; the specific configuration change is not captured in this record. Risk: There are two risky calls. The identity-escalation call is iam:PutRolePolicy on chaperone-forwarder, a role this same session created via Terraform; it attached an inline policy whose permissions are not shown in the record. The audit-tampering call is cloudtrail:UpdateTrail on chaperone-trail, a trail that existed before this session; the record flags it because any UpdateTrail call can disable or redirect audit logging, and the specific change made is not visible here. The combination of a new role with an unknown inline policy and a modification to an existing audit trail warrants review. Access: The agent operated under AdministratorAccess (Action: *) granted through an Identity Center permission set, so no grants were withheld. Of that broad allowance, the session used 54 distinct actions across 11 services, and passed one role during execution. ## admin (person), 2026-09-25T14:40:12Z, 0 min - Page: https://chaperone.fullstackfusions.com/session/user%2Fadmin%402026-09-25T14%3A40%3A12Z - 134 AWS calls, 0 MCP tool calls; by risk: write 1, read 133 - Riskiest: write **Admin signed in to the console and spent 30 seconds reading billing and account data.** The admin user opened the AWS Management Console and performed 133 read operations across 17 services, covering billing, cost management, budgets, CloudTrail, Config, EC2, organizations, and related areas. The single write action was the console sign-in itself. No resources were created or deleted. Two calls were denied and seven returned errors, but no risky actions were flagged. The session lasted roughly 30 seconds. Key moments: - 14:40:12 Admin signed in to the AWS Management Console in us-east-2. - 14:40:12 Session began issuing read calls across billing, cost explorer, budgets, and account services. - 14:40:39 Session ended after 133 reads with no resources created, modified beyond sign-in, or deleted. Risk: There were no risky calls in this session. The only write recorded was the console sign-in. No destructive, public-exposure, identity-escalation, or audit-tampering actions were taken. Access: The identity's granted permissions are not recorded, so a least-privilege comparison cannot be made. The session used 45 distinct IAM actions across 17 services, all concentrated in billing, cost, and account-inspection areas. ## chaperone-agent (AI agent), 2026-09-25T14:07:23Z, 44 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-25T14%3A07%3A23Z - 865 AWS calls, 5 MCP tool calls; by risk: read 831, write 31, identity_escalation 2, audit_tampering 1 - Riskiest: identity_escalation (iam:PutRolePolicy grants or assumes more access) **Agent deployed Chaperone ingest pipeline and then verified its own infrastructure over 44 minutes.** The agent used Terraform to provision a full Chaperone data-ingest stack in us-east-1: an S3 bucket for Terraform state, a DynamoDB table, two IAM roles, two Lambda functions (chaperone-ingest and chaperone-poller), two EventBridge rules, and associated CloudWatch log groups. It then updated both Lambda function codes and configurations three times each before modifying a pre-existing CloudTrail trail in us-east-2. In the final three minutes the agent ran five read-only scripts to verify infrastructure state, CloudWatch metrics, and recent CloudTrail events. All activity came through the agent channel; no resources were deleted. Key moments: - 14:08:37 Created the S3 bucket chaperone-tfstate-111122223333-use1 with encryption, versioning, and public-access blocking; a lifecycle policy call failed once with OperationAborted before succeeding. - 14:20:00 Provisioned the core stack in a single Terraform apply: DynamoDB table chaperone, IAM roles chaperone-ingest and chaperone-poller, two EventBridge rules, and log groups for both Lambda functions. - 14:20:12 Attached inline policies to both newly created IAM roles via iam:PutRolePolicy. - 14:21:35 Updated the code for both Lambda functions three times each between 14:21 and 14:26, ending with a configuration update to each. - 14:48:10 Modified the pre-existing CloudTrail trail chaperone-trail in us-east-2 via Terraform. - 14:49:13 Queried CloudWatch metrics and the DynamoDB table twice in quick succession, apparently checking that the pipeline was receiving data. Risk: There are two identity-escalation calls and one audit-tampering call. The two iam:PutRolePolicy calls attached inline policies to chaperone-ingest and chaperone-poller, both of which were created in this same session; attaching policies to your own new roles is standard deployment practice, though the content of those policies is not visible in this record. The cloudtrail:UpdateTrail call modified a trail named chaperone-trail in us-east-2 that was not created this session, meaning the agent changed an existing audit-logging configuration whose prior state cannot be determined from this record alone. Access: The role held AdministratorAccess (Action: *) through an Identity Center permission set. Of that broad grant, the agent used 74 distinct IAM actions across 10 services, and it passed two IAM roles during the session. ## admin (person), 2026-09-25T13:51:24Z, 0 min - Page: https://chaperone.fullstackfusions.com/session/user%2Fadmin%402026-09-25T13%3A51%3A24Z - 11 AWS calls, 0 MCP tool calls; by risk: read 11 - Riskiest: read **Admin read-only session querying account status across six AWS services** A human admin session lasting under one second made eleven read-only API calls across CloudTrail, Config, EC2, Free Tier, Notifications, and Organizations. No resources were created or changed, and no risky calls were made. One call was denied. The session ended cleanly with no errors. Key moments: - 13:51:24 Session opened by user/admin via direct AWS API calls (no automation channel). - 13:51:24 Read calls issued across CloudTrail, Config, EC2, Free Tier, Notifications, and Organizations. - 13:51:24 One call was denied; the record does not show which service or action was refused. - 13:51:25 Session closed with no changes, no resources created or deleted, and no risky actions recorded. Risk: All eleven calls were classified as reads, and no destructive, public-exposure, identity-escalation, or audit-tampering actions were recorded. The single denied call could represent an attempted action the identity lacked permission for, but the record does not identify it further. Access: The identity used 9 distinct IAM actions across six services; the granted permissions for this identity are not recorded, so it is not possible to assess how much of the allowed scope was exercised. ## admin (person), 2026-09-25T03:19:50Z, 0 min - Page: https://chaperone.fullstackfusions.com/session/user%2Fadmin%402026-09-25T03%3A19%3A50Z - 1 AWS calls, 0 MCP tool calls; by risk: read 1 - Riskiest: read **Admin made a single CloudTrail read call and nothing else.** The session consisted of exactly one API call, a read against CloudTrail, made directly by a human through the AWS console or CLI. No resources were created, modified, or deleted. The session opened and closed at the same recorded timestamp, lasting under a minute. Key moments: - 03:19:50 Admin made one read call to CloudTrail, completing the entire session in under a minute. Risk: There were no risky calls of any class in this session. The single action was a read, which carries no destructive, exposure, escalation, or audit-tampering risk. Access: The identity used 1 action against CloudTrail; the granted permissions for this role were not recorded, so no comparison can be made. ## chaperone-agent (AI agent), 2026-09-25T03:13:15Z, 5 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-25T03%3A13%3A15Z - 11 AWS calls, 5 MCP tool calls; by risk: write 6, read 2, destructive 3 - Riskiest: destructive (events:RemoveTargets removes or stops a resource; events:DeleteRule removes or stops a resource; sqs:DeleteQueue removes or stops a resource) **Agent ran a short-lived EventBridge-to-SQS probe, then cleaned up all resources it created.** Over about five minutes, the agent used the AWS MCP server to set up a temporary probe consisting of an SQS queue named chaperone-eb-probe and an EventBridge rule of the same name that targeted it. It then updated tags on an existing S3 bucket named chaperone-web-111122223333-use1 twice, polled the probe queue five times and looked up CloudTrail events, apparently to verify EventBridge delivery. At the end of the session it deleted the EventBridge rule and its target, then deleted the SQS queue, leaving no net new resources. All 11 API calls succeeded with no errors or denials. Key moments: - 03:13:28 Created the SQS queue chaperone-eb-probe in us-east-1. - 03:13:29 Created an EventBridge rule named chaperone-eb-probe and pointed it at the new queue, then set the queue's access policy to allow EventBridge to deliver messages. - 03:13:42 Read and updated tags on the existing S3 bucket chaperone-web-111122223333-use1 (first of two tag updates). - 03:18:02 Polled chaperone-eb-probe five times with ReceiveMessage, likely checking whether EventBridge had delivered any events. - 03:18:16 Queried CloudTrail with LookupEvents, probably to inspect recent API activity related to the probe. - 03:18:33 Removed the EventBridge target, deleted the rule, and deleted the SQS queue, completing the teardown. Risk: All three destructive calls — removing the EventBridge target, deleting the EventBridge rule, and deleting the SQS queue — acted on resources this same session created, so no pre-existing infrastructure was removed. The S3 bucket chaperone-web-111122223333-use1 was tagged twice; this bucket pre-existed the session and was modified but not deleted. No public-exposure, identity-escalation, or audit-tampering actions were recorded. Access: The agent held AdministratorAccess (all actions allowed) through an Identity Center permission set, but used only 10 distinct actions across four services: CloudTrail, EventBridge, S3, and SQS. ## admin (person), 2026-09-25T02:28:47Z, 0 min - Page: https://chaperone.fullstackfusions.com/session/user%2Fadmin%402026-09-25T02%3A28%3A47Z - 16 AWS calls, 0 MCP tool calls; by risk: read 16 - Riskiest: read **A 13-second read-only survey of account configuration across seven services** The admin user made 16 read calls across seven services — CloudTrail, Config, EC2, Free Tier, Notifications, Organizations, and S3 — in roughly 13 seconds. All activity came through a human channel with no tool or automation involvement. Two calls were denied and none succeeded in making any change. The session ended with no resources created or deleted. Key moments: - 02:28:47 Session opened by user/admin and read calls began immediately across multiple services. - 02:28:47 Two of the 16 calls were denied, suggesting the identity lacked permission for at least two of the read operations attempted. - 02:29:00 Session closed after 13 seconds with 16 reads, no writes, and no changes to any resource. Risk: All 16 calls were classified as reads; there were no destructive, public-exposure, identity-escalation, or audit-tampering actions. The record shows no risky activity of any kind. Access: The identity used 11 distinct IAM actions; what the role was granted is not recorded, so the gap between permissions and usage cannot be measured. ## chaperone-agent (AI agent), 2026-09-25T01:46:58Z, 46 min - Page: https://chaperone.fullstackfusions.com/session/role%2FAWSReservedSSO_ChaperoneAgent_0000000000000000%2Fchaperone-agent%402026-09-25T01%3A46%3A58Z - 24 AWS calls, 10 MCP tool calls; by risk: read 16, write 8 - Riskiest: write **Agent built an S3-backed CloudFront distribution and requested a TLS certificate over 46 minutes.** The agent created an S3 bucket to serve as a web origin, attached a CloudFront Origin Access Control and bucket policy to restrict direct public access, then launched a CloudFront distribution backed by that bucket. About 16 minutes later it requested an ACM certificate, polled for its status, and updated the distribution to attach it. All activity came through the AWS MCP server (agent channel). The session ended with the distribution updated and the certificate issued but likely still pending DNS validation. Key moments: - 01:49:07 Agent confirmed its own identity with STS before doing any other work. - 01:53:44 Agent queried CloudTrail twice, likely reviewing prior activity in the account before making changes. - 02:05:01 Agent created the S3 bucket chaperone-web-111122223333-use1, tagged it, and created a CloudFront Origin Access Control in a single script run. - 02:05:14 Agent applied a bucket policy locking the bucket to the new OAC, then launched CloudFront distribution EDFDVBD6EXAMPLE. - 02:21:19 Agent requested an ACM certificate, with ACM in turn creating a KMS grant to manage the certificate's private key. - 02:32:52 Agent attached the new certificate to distribution EDFDVBD6EXAMPLE via an UpdateDistribution call. Risk: No calls were flagged above a plain write: no destructive deletions, no public-exposure changes, no identity escalation, and no audit tampering. The bucket policy written at 02:05:14Z restricts access to the CloudFront OAC rather than opening the bucket to the public, which is the expected pattern for this setup. All resources modified were created during this same session. Access: The role held AdministratorAccess (all actions, all resources) through an Identity Center permission set. The agent used 13 distinct IAM actions across five services (acm, cloudfront, cloudtrail, s3, sts), a small fraction of what was permitted. ## admin (person), 2026-09-25T01:01:40Z, 52 min - Page: https://chaperone.fullstackfusions.com/session/user%2Fadmin%402026-09-25T01%3A01%3A40Z - 362 AWS calls, 0 MCP tool calls; by risk: write 25, read 331, audit_tampering 3, identity_escalation 3 - Riskiest: audit_tampering (cloudtrail:PutEventSelectors changes or stops audit logging) **Admin bootstrapped CloudTrail, AWS Organizations, and IAM Identity Center in a single 52-minute console session.** Working entirely through the AWS console, the admin set up foundational account infrastructure: an S3 bucket and a CloudTrail trail named chaperone-trail for audit logging, a billing budget, an AWS Organization, and IAM Identity Center (SSO) with an identity store, a new SSO user, a permission set, and an account assignment that provisioned the IAM role AWSReservedSSO_ChaperoneAgent_0000000000000000. The session spanned 362 API calls across 23 services, with 22 denied and 28 errors (including a throttle on SSO startup and an InvalidInputException on one service-linked role creation). The session ended with the core identity and audit infrastructure in place; nothing was deleted. Key moments: - 01:01:40 Admin logged into the console; two additional console logins were recorded during the session, the last at 01:51:55Z. - 01:12:47 A billing budget was created against the primary billing view. - 01:15:33 An S3 bucket for CloudTrail logs was created, encrypted, and given a bucket policy, and the chaperone-trail CloudTrail trail was created and started immediately. - 01:20:42 Event selectors on chaperone-trail were updated twice more, between 01:20:42Z and 01:23:32Z, adjusting what the trail captures. - 01:37:10 An AWS Organization was created, triggering two successful and one failed service-linked role creation, followed by IAM Identity Center registration and initialization. - 01:42:12 A permission set was created in IAM Identity Center, a managed policy was attached to it, and an account assignment was created that provisioned the AWSReservedSSO_ChaperoneAgent role with an attached policy. Risk: There were 3 audit-tampering calls and 3 identity-escalation calls. All three audit-tampering calls were cloudtrail:PutEventSelectors against chaperone-trail; the trail was created this session, but the rule flags the action regardless because it can narrow or disable audit coverage. The three identity-escalation calls (sso:AttachManagedPolicyToPermissionSet, sso:CreateAccountAssignment, and iam:AttachRolePolicy) collectively granted a managed policy to a new permission set and assigned it to an account, resulting in the AWSReservedSSO_ChaperoneAgent role gaining that policy; all three acted on the SSO instance and IAM role created this same session, so no pre-existing access was modified. Access: The identity had no recorded grant (granted is null); the session used 93 distinct IAM actions across 23 services.