How to provide test credentials for Strike's AI agent

Last updated: October 20, 2026

For Strike's AI agent to evaluate your platform with the greatest possible scope and depth, it needs to be able to log in and operate as a real user would. Test credentials give it that access: without them, the agent can only analyze the public part of the application, just as would happen to a human pentester without an account. The more authenticated areas it can explore, the more complete the evaluation.

This article explains the different ways to provide those credentials and how to choose the option that maximizes testing coverage. To see where they are added and which credential types exist, see How to add credentials for testing.

Ways to provide the credentials

There are several ways to provide test credentials. Only one factor defines how much the agent can cover: whether, at some point, it can read the email associated with the account.

  1. Create the credentials with an email address the agent can read. Use any @strike.email address (for example, [email protected]). @strike.email addresses are real mailboxes managed by Strike: you don't need to create them or share access to them. You create the test user in your system, outside of Strike, and add the credentials in the platform. This is the most complete option, because it also enables the flows that depend on email.

  2. Share the credentials of an existing account whose associated email the agent can also check. For example, by forwarding that account's emails to an @strike.email address. As with the previous option, you add the credentials in the platform. The coverage is equivalent.

  3. Let the agent generate its own credentials from the portal, when your platform supports user self-registration. Depending on how the platform is configured, that account may have limited access, so the agent may not be able to work as intended and some flows or areas may be left out of scope.

  4. Share the credentials of an account whose associated email the agent cannot read. The run proceeds normally, but flows that depend on email are left out of scope (more detail in the next section).

Options 1 and 2 are always preferable, because they give the agent the most complete coverage. Options 3 and 4 are the least desirable: depending on the case, they can limit which areas or flows get tested.

Flows that depend on email access

Some features of an application can only be tested if the agent can read the email associated with the account, because they depend on a message that arrives in the inbox. The most common ones are:

  • Password recovery

  • Email verification

  • Two-factor authentication (2FA) via email

  • Magic links

If the agent cannot access that email, these flows are left out of the testing scope. This does not affect the quality or depth of the rest of the evaluation: it simply narrows which areas can be explored. That's why having an email address the agent can read lets you expand coverage.

If your application uses 2FA, see How to add two-factor authentication (2FA) to a credential.

Our recommendation

  • Use dedicated test credentials instead of personal accounts or shared production accounts. This keeps the test environment isolated and under your control.

  • Whenever possible, choose option 1 or 2: create the credentials with an @strike.email address and add them in the platform. It takes a few minutes and also enables the flows that depend on email.

  • If you prefer another option, you can still move forward: testing continues normally and only the flows that depend on email would be left out of scope.

The decision about which credentials to use is yours, and it defines the testing scope according to what best fits your organization.

Have questions about your case?

This topic can involve many specific cases, and we often resolve them individually. If you're not sure what the best way to provide credentials is in your situation, talk to your Customer Success Manager: they can help you find the most suitable solution.