Product · 5 MIN READ · JAKE GODGART · JUL 25, 2025 · TAGS: AI & automation
TL;DR
- This auto remediation series focuses on understanding the functionality of all of Expel’s auto remediations
- The disable access key action deactivates a specific cloud access key suspected of compromise, using cloud provider APIs to immediately sever an attacker’s programmatic access
- You can find blogs on our other auto remediations as well: Kill process, contain host, block bad hash, delete malicious file, delete registry key, reset credentials, and remove malicious email
Your developers are building amazing things in the cloud. That’s their job. They’re moving fast, spinning up resources, and using programmatic access keys to make it all happen. But in that rush to innovate, mistakes happen. A developer, working late on a side project, accidentally commits a config file to a public GitHub repository. Buried inside that file is an active, long-term AWS IAM access key.
That’s not just a small oops. That’s like leaving the master key to your entire cloud infrastructure on a park bench with a “please use me” sign on it. An attacker scanning GitHub for this exact kind of mistake can find it in minutes. Before you’ve had your morning coffee, they could be inside your environment, enumerating S3 buckets, spinning up cryptominers, or worse—exfiltrating your most sensitive data.
This is the exact pain point the disable access key auto remediation action is built to solve. It’s the digital emergency brake. The moment we spot a compromised key, we can instantly deactivate it, rendering it useless to an attacker. The “so what” is simple: we slam the door shut before the attacker can do any real damage, giving your team the breathing room to investigate and fix the root cause without the pressure of an active intrusion.
How it works
Disabling an access key isn’t like using a blunt instrument; it’s a precision strike. It’s triggered when we have solid evidence that a key is in the wrong hands, or is being used maliciously.
Let’s stick with our GitHub scenario. A developer pushed code containing an active AWS Access Key ID and its corresponding Secret Access Key to a public repo. If a secret scanner—either run by the customer, an attacker, or someone else—identifies a key and attempts to use it, the activity will generate an alert.
The alert lands in Expel Workbench™ with the critical details: the key ID and the associated IAM user. Our system automatically recognizes the high-risk nature of this event. This puts, a priority one alert in front of an analyst in seconds.
The analyst confirms the key is active and what permissions it holds. Is it a god-mode admin key or something with limited scope? In this case, it has broad administrative privileges. This is a five-alarm fire. The analyst, following your pre-approved rules, executes the disable access key action through Workbench. Our platform sends an API call directly to AWS IAM to change the key’s status to Inactive. The attacker, who just discovered the key, now gets an “access denied” error when they try to use it. Threat contained.
When to expect Expel to use this action
We don’t disable keys on a whim. It’s a calculated move used in specific situations where the risk of leaving the key active is greater than the risk of temporarily breaking something. Here are the most common scenarios where we’ll pull this lever (with your permission, of course):
- Confirmed public exposure: This is the most clear-cut case. An active key for your environment is found on a public GitHub, a paste site, or a misconfigured public storage bucket. This may also be an alert as the result of a secret scanning tool (like GitGuardian or GitHub Advanced Security) which tells us an active key is sitting in a public space. In either case, it’s a race against time, and disabling it’s the first and most critical step.
- Active credential abuse: We observe an access key being used for malicious activity. This could be reconnaissance (List*, Describe*, Get* calls), privilege escalation attempts, or data exfiltration. The goal is to cut the attacker’s session short.
- Compromised cloud workload: If we determine an EC2 instance, Microsoft Azure VM, or container has been compromised, we’ll disable any access keys associated with that resource’s identity to prevent the attacker from moving laterally into your wider cloud environment.
- Major incident containment: During a widespread cloud security incident, disabling any keys known or suspected to be compromised is a key containment strategy to stop the bleeding and regain control.
The disable access key auto remediation workflow
Let’s walk through the GitHub exposure scenario from start to finish to see how this action unfolds in the real world.
1. Detection
Our secret scanning integration detects an active AWS Access Key ID (AKIAIOSFODNN7EXAMPLE) in a file on a public GitHub repository. An alert is automatically generated and sent to Workbench, containing the key ID and a link to the exposed file.
2. Validation & context
An Expel SOC analyst immediately picks up the alert. Their first thought isn’t just “block it,” it’s “what’s the blast radius?” They run through a mental checklist:
- Is this key actually active? (A quick API check confirms this.)
- Who does this key belong to? (They identify the IAM user: dev-user-jane.)
- What permissions does it have? (They review the attached IAM policies and discover it has the AdministratorAccess policy. This is the worst-case scenario.)
- Is it being used right now? (A quick query of CloudTrail logs shows no suspicious activity yet, but it’s only a matter of time.
3. Customer approval check
The analyst sees the risk is critical. They submit a remediation action to disable the API key: based on your settings, the disablement will take place automatically or require manual action from your team. It’s your environment, your rules. You might decide to auto remediate any exposed key, or maybe you require manual approval for keys tied to critical production services. The power is in your hands.
4. Execution
Since the action is pre-approved for this scenario, the automation kicks in. Workbench makes a direct API call to the AWS IAM endpoint, specifically using the UpdateAccessKey function to set the Status parameter for AKIAIOSFODNN7EXAMPLE to Inactive. We disable rather than delete because it’s less destructive. It prevents the key’s use while allowing you time to investigate and safely replace it without breaking dependent applications prematurely.
5. Confirmation & next steps
The AWS API returns a success code. Workbench logs the action, showing the key was disabled, when it happened, and which analyst or automation rule triggered it. You have a full audit trail. The immediate threat is neutralized. Now, the real investigation begins. The analyst documents the findings and provides next-step recommendations: notify the developer, investigate how the leak occurred, and initiate the key rotation process (create a new key, update legitimate applications, and then delete the old, disabled key).
How to set it up
If you’re an Expel customer and want to put this capability to work, getting started is straightforward. It mainly involves ensuring your cloud integration (for AWS, Microsoft Azure, or Google Cloud) is configured with the necessary permissions to modify IAM key statuses. Reach out to your customer success manager, and they can walk you through the setup in Workbench and help you define the specific auto remediation rules that make sense for your organization.
Not an Expel customer yet, but tired of worrying about a simple mistake turning into a catastrophic cloud breach? Let’s talk. We’ll show you how we use our platform, our analysts, and your existing security tools to deliver outcomes like this—no nonsense, just results.
