Automated Access Key Compromise Remediation Using AWS Trusted Advisor, EventBridge, and Cross-Account Lambda Orchestration

Your AWS access key was just pushed to a public GitHub repo. By the time you read the teams notification, we’ve already deactivated it.That’s the message our engineering teams now receive. No panic. No scramble. No 3 AM incident calls.

In a multi-account AWS environment with 250+ accounts and hundreds of developers, leaked access keys aren’t a matter of if — they’re a matter of when. The real question is: how fast can you respond?

In this post, I’ll walk you through exactly how I designed and implemented a fully automated, cross-account access key compromise remediation system that detects a leaked key and deactivates it in under 15 seconds — while simultaneously creating a Jira ticket, notifying the team on Microsoft Teams, and sending an email alert.

No human intervention required.

The Problem: Leaked Keys in a Multi-Account World

• 250+ AWS accounts under a single AWS Organization
• Hundreds of developers, some still using long-lived access keys
• Keys accidentally committed to public GitHub repositories
• Mean Time To Remediate (MTTR) for manual key rotation: 4–6 hours (on a good day)
• A single leaked key can lead to unauthorised resource provisioning, data exfiltration, or crypto-mining operations within minutes.

AWS reports that compromised credentials are the #1 root cause of security incidents in the cloud. The 2024 Verizon Data Breach Investigation Report confirms that stolen credentials account for nearly 50% of all breaches.

We needed a system that was:

1. Immediate — respond in seconds, not hours

2. Autonomous — zero human intervention for deactivation

3. Observable — full audit trail with Jira tickets and notifications

4. Scalable — works identically across 250+ accounts without per-account configuration changes

Architecture Overview

Architecture diagram for Automated Access Key Remediation

The solution follows an event-driven, cross-account remediation pattern built entirely on serverless AWS-native services and operates through a delegated security account model.

Core Components

The Architecture — Step by Step

Let me break down the entire flow, from the moment a key is leaked to the moment it’s deactivated.

Step 1: The Leak — Access Key Exposed on a Public Repository

A developer accidentally pushes code containing an AWS access key to a public GitHub repository. This happens more often than anyone wants to admit. Whether it’s hardcoded in a config file, left in a .env that wasn’t .gitignored, or embedded in a Jupyter notebook — the key is now publicly visible.

# Accidentally committed in config.py
AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

Within seconds, automated scrapers and bots start scanning for these keys. The clock is ticking.

Step 2: AWS Trusted Advisor Detects the Compromise

AWS Trusted Advisor continuously monitors for IAM access keys that have been exposed publicly. When it detects that an access key has been published on sites like GitHub, Bitbucket, or code-sharing platforms, it generates a finding.

Here’s what the detection mechanism looks like under the hood:

• AWS partners with security researchers and uses automated scanning to detect access keys published on public platforms
• When a match is found, Trusted Advisor raises a finding under the ”Exposed Access Keys” check
• This finding generates an AWS Health event of type AWS_RISK_CREDENTIALS_EXPOSED

Important: This event is generated in the us-east-1 region, regardless of where the access key is used. This is a critical detail for the EventBridge configuration.

The Trusted Advisor event payload looks like this:

{
    "version": "0",
    "id": "121345678-1234-1234-1234-123456789012",
    "detail-type": "AWS Health Event",
    "source": "aws.health",
    "account": "123456789012",
    "time": "2016-06-05T06:27:57Z",
    "region": "us-east-1",
    "resources": [],
    "detail": {
        "eventArn": "arn:aws:health:us-east-1::event/AWS_RISK_CREDENTIALS_EXPOSED_XXXXXXXXXXXXXXXXX",
        "service": "RISK",
        "eventTypeCode": "AWS_RISK_CREDENTIALS_EXPOSED",
        "eventTypeCategory": "issue",
        "startTime": "Sat, 05 Jun 2016 15:10:09 GMT",
        "eventDescription": [
            {
                "language": "en_US",
                "latestDescription": "A description of the event will be provided here"
            }
        ],
        "affectedEntities": [
            {
                "entityValue": "ACCESS_KEY_ID_HERE"
            }
        ]
    }
}

Step 3: EventBridge Cross-Account Event Forwarding

This is where the magic of multi-account event orchestration begins.

Each of the 250+ member accounts has an Amazon EventBridge rule in the us-east-1 region that matches the Trusted Advisor credential exposure event. The rule forwards this event to the centralized event bus in the delegated security account.

Event Bus Target: Delegated Security Account

The target for this rule is the custom event bus in the delegated security account (security-remediation-bus). EventBridge natively supports cross-account event delivery — the member account rule simply points to the event bus ARN in the security account.

Step 4: The Remediation Lambda — The Brain of the Operation

This is the core of the system. A Python Lambda function that performs four critical actions upon invocation:

4a. Deactivates the compromised access key (cross-account)

The Lambda extracts the source account ID and the exposed access key ID from the event payload. It then uses AWS STS to assume the cross-account SecurityRemediationRole in the affected member account. Once assumed, it calls iam:UpdateAccessKey to set the key status to Inactive effectively locking out anyone (including attackers) using that key.

4b. Creates a Jira ticket

The Lambda calls the Jira REST API to auto-create a Critical severity Incident ticket with full context: the affected account, IAM user, access key ID, action taken, and timestamp. The ticket is labeled with auto-remediation, exposed-credentials, and security-incident for easy filtering. This provides a complete audit trail and kicks off the incident response workflow.

4c. Sends a Microsoft Teams notification

An AdaptiveCard is posted to the #security-alerts channel via a Teams incoming webhook. The card includes all incident details, the current remediation status, the Jira ticket reference, and a direct link to open the ticket. This gives the security team real-time visibility without needing to check dashboards.

4d. Sends an email alert via Internal SMTP server

A formatted HTML email is sent to the security team distribution list and CC’d to the key owner. The email includes a summary table of the incident, the auto-remediation action taken, and a clear Next Steps

checklist: investigate the exposure source, rotate credentials, review CloudTrail for unauthorized activity, and assess blast radius.

Step 5: Cross-Account IAM Role — The Trust Bridge

Every member account in the organization has a standardized IAM role called SecurityRemediationRole, deployed via AWS CloudFormation StackSets with automatic deployment enabled for the entire organization. When a new account is added to the org, it automatically gets this role — zero manual setup.

Trust relationship: The role’s trust policy allows only the Lambda execution role in the delegated security account to assume it.

Permissions (Principle of Least Privilege): The role only permits three IAM actions:

• iam:UpdateAccessKey — to deactivate the exposed key

• iam:ListAccessKeys — to verify the key exists and check its current status

• iam:GetAccessKeyLastUsed — to assess potential unauthorized usage

Timeline: What Happens in 15 Seconds

15 seconds - From leak to lockdown.

Conclusion

If you’re operating in a multi-account AWS environment, you cannot afford to rely on manual processes for credential compromise response. By combining AWS Trusted Advisor, EventBridge cross-account event buses, a centralized remediation Lambda, and cross-account IAM roles, you can build a system that:

• Detects leaked keys in seconds
• Deactivates them automatically
• Creates a full audit trail with Jira
• Notifies your team in real-time on Teams and email
• Scales to hundreds of accounts without per-account maintenance

The best security incident is the one your team never has to manually respond to.