Testing signed-in flows with AI agents: accounts, sessions and MFA

To test signed-in flows with an AI agent, give it dedicated test accounts, one for each role, and tell it how to keep its session alive. Most of an application's risk sits behind login: records, settings, payments and admin tools. An agent that tests only the public pages sees little of it. Never use real user credentials in this setup.

Why does signed-in testing matter?#

Signed-in testing reaches the features where access control, session handling and business rules apply. An anonymous test reaches the login page and the marketing site. Authorization flaws, such as one user reading another user's record, appear only when the caller is signed in. Our method compares anonymous and signed-in callers, and reads back from a second account to prove cross-account effects.

What test accounts does the agent need?#

The agent needs a set of accounts that matches your role model. Create them before the test, for this purpose only.

Each account should hold some test data, so cross-account reads have something to read. Mark the data as test data. Write the accounts and their roles into the scope document.

What session handling does the agent need?#

The agent needs a way to sign in, notice when a session ends, and sign in again. Web apps and APIs end sessions in different ways, and an agent that misses an expiry will report errors as findings.

1. Record the login flow. Give the sign-in steps, or the token endpoint for an API.
2. Name the session carrier: a cookie, a bearer token, or a custom header.
3. Define expiry. State the lifetime and refresh rules, so the agent renews the session instead of failing.
4. Keep sessions apart. Each account gets its own session store, because a mix-up between accounts invalidates the differential test.
5. Check for silent logout. If a response suddenly returns a login page with 200, the agent must treat the session as lost. Log it in the run log. Do not report it as a finding.
6. Test the session itself. Logout, token reuse after logout and cookie flags are valid tests. See OWASP API2:2023 Broken Authentication.

State-changing requests may need an anti-CSRF token. The agent must fetch a fresh token per session. Browser-observed checks cover this: the WSTG CSRF test describes it, and we show CSRF and stored XSS results in a real browser.

How do you handle MFA and SSO?#

Choose an option that lets the agent sign in without lowering the controls on real accounts. OWASP states that "MFA is a critical security control, and is recommended for all applications", so turning it off for everyone is wrong.

If the login and MFA flow is itself in scope, test it on purpose with accounts you control. OWASP also notes that "account recovery is just an alternate way to authenticate so it should be no weaker than regular authentication". Test password reset and recovery separately.

Why must you never give an agent real user credentials?#

Real credentials put real people and data at risk, and they break the test's own safety rules. The scope covers systems and test-owned accounts, and a real user has not agreed to a test. A write or delete during testing would change a real person's data. Credentials in an agent's logs and saved evidence also get copied into more places.

Destructive proofs use only test-owned accounts and records, marked as test data. The human-in-the-loop pentesting guide covers the rule set, and the safety page covers scope and stop conditions.

How do you keep credentials safe during the test?#

Treat test credentials as secrets, even though the accounts are not real users.

1. Create accounts for the test only, with distinct email addresses on a domain you control.
2. Pass credentials to the tester through a secrets manager or an encrypted channel, not through chat or tickets.
3. Keep credentials out of saved evidence. Replace session values with placeholders in reports.
4. Give the accounts the lowest rights that match the role.
5. Set an end date. Disable the accounts and revoke tokens when the test ends.
6. Run the test in staging when you can, with data that is not real.

What should the scope say about signed-in testing?#

The scope should name each account and role, how to sign in, how MFA is handled, who to contact when a session breaks, and the clean-up step. Excession Labs agrees the scope with you in writing before testing, and written authorization from the system owner comes first.

How AI agents test authorization has a worked example of the test itself. How AI pentesting works covers the whole flow. To ask about a small, scoped test, see the pilot page.