To my understanding you cannot bypass MFA, you Need to automate the authentication flow rather than attempting to inject static tokens. DAST scanners cannot "see" MFA prompts unless they are configured to interact with them programmatically.

Here approaches to resolve this:

1. Automated Credential Harvester (The "Scripted Login" approach): Configure your scanner to use a headless browser automation tool (e.g., Playwright, Selenium, or Puppeteer). Instead of providing a static token, provide the agent with a login script that handles the full SSO flow. When the session expires, the script triggers a fresh login, navigates the SSO page, and solves the MFA challenge.

2. Programmatic OTP Retrieval (For Email OTP): If your security policy permits, create a dedicated service account for scanning. Configure your automation script to fetch the OTP via a secure API:

• Microsoft Graph API / Google Workspace API: Use these to read the inbox of the dedicated scanner account.
• Regex Parsing: Your script should fetch the latest email, extract the OTP via regex, and inject it into the MFA input field during the automated login flow.

3. Transition to TOTP (Recommended): If your security policy allows for it, switch the service account’s MFA from Email OTP to TOTP (Time-based One-Time Password).

• Most enterprise scanners support TOTP natively.
• By providing the TOTP secret seed directly to the scanner, it can generate valid tokens algorithmically in real-time without needing to fetch emails, eliminating the reliance on external mail servers and significantly increasing scan stability.

Summary: Do not attempt manual token injection. You must shift to an automated, scripted authentication workflow that retrieves or generates the OTP at the exact moment of session expiry.

See also:

• https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/qa.st.5-evaluate-runtime-security-with-dynamic-application-security-testing.html

Hola Timmy,

Florian's suggestion to move away from static token injection is spot on, but the key thing you might be missing is that AWS Security Agent has native support for this.

First, instead of passing a static token, configure a credential vendor. AWS Security Agent supports providing credentials via a Lambda function that can dynamically supply or refresh credentials throughout the scan. This is purpose-built for scenarios where short-lived tokens expire mid-test. Your Lambda function could handle the SSO flow programmatically and return fresh credentials whenever the agent requests them.

Second, the agent uses LLM-based sign-in to navigate authentication flows. You can provide "sign-in guidance" with step-by-step instructions describing your login flow (URL, field names, sequence of steps, success criteria). The more specific you are about the MFA challenge steps, the better the agent can handle them autonomously.

For the Email OTP problem specifically, the Lambda vendor approach is probably your best option. You could wire the Lambda to fetch OTPs from your mail provider's API (e.g., Microsoft Graph or Google Workspace API) using a dedicated scanner service account and return them as part of the credential response.

Here are the docs covering authentication configuration and credential vendors.

Additionally, here is the blog post announcing GA. It goes into more detail on the sign-in guidance format with examples.

It's also worth noting the product is called "AWS Security Agent" rather than "AWS AI Security Agent" in case that helps with your doc searches.

Thanks,

James

How to handle strict MFA (SSO & Email OTP) during DAST scans with AWS Security Agent

Hi Timmy,

The previous answers are directionally right — automate the flow, don't inject static tokens — but let me consolidate into what AWS Security Agent actually supports natively, since a couple of the suggestions (Playwright/Selenium scripts, TOTP seed) describe generic DAST scanners rather than this specific service.

1. Use the Lambda credential provider, not static tokens

This is the key mechanism for your exact problem. AWS Security Agent supports supplying credentials through a Lambda function that the agent invokes to obtain/refresh credentials during the scan. Because your multi-hour scan outlives a short-lived token, this is purpose-built for you: the agent calls your Lambda whenever it needs fresh credentials, so token expiry mid-scan is handled programmatically instead of by manual re-injection.

2. Solve the Email OTP inside that Lambda

Since you can't disable MFA (correct posture for a regulated environment), wire the Lambda to complete the OTP step itself:

• Use a dedicated scanner service account for the target app's login.
• Have the Lambda retrieve the OTP from that mailbox via the mail provider API — Microsoft Graph API (M365) or Google Workspace / Gmail API — using app credentials stored in AWS Secrets Manager.
• Parse the code (regex) and return it as part of the credential response so the agent can complete the challenge.

This keeps MFA fully enabled and confined to a purpose-built service identity — no IP allowlisting, no non-MFA environment, which is what your compliance team will care about.

3. Provide sign-in guidance for the SSO/MFA navigation

The agent uses LLM-based sign-in and accepts sign-in guidance: step-by-step instructions of your login flow (login URL, field identifiers, the sequence through the SSO redirect and the OTP prompt, and a success signal such as a post-login URL/element). The more precisely you describe the SSO + OTP steps, the more reliably the agent navigates them autonomously. The service also has documented 2FA/MFA authentication support, so this is a supported scenario, not a hack.

A note on the other suggestions

• TOTP seed: great advice for generic scanners, but here it would mean changing the service account's MFA factor from Email OTP to TOTP. If your policy allows it, TOTP is far more stable than mail-polling (no dependency on mailbox latency/API), so I'd genuinely consider it as the more robust option — just confirm it satisfies your MFA policy. If it must stay Email OTP, the Lambda + Graph/Workspace approach above is the way.
• External Playwright/Selenium harness: not needed as a separate layer — the agent drives the browser itself; you steer it via the Lambda credential provider + sign-in guidance rather than running your own headless browser.

One caveat to set expectations

OTP retrieval has an inherent race (email delivery latency vs. the agent submitting the code). Make sure your Lambda waits for the newest message and returns quickly; a TOTP secret removes this race entirely, which is the main reason it's worth evaluating.

References

• AWS Security Agent authentication / credential configuration docs
• The GA announcement blog post (has the sign-in guidance format with examples)

Minor: the service is "AWS Security Agent", not "AWS AI Security Agent" — helps when searching the docs.

Hope this helps,