How to provide test credentials for Strike's AI agent

Last updated: June 25, 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 the way a real user would. Test credentials give it that access: without them, the agent can only analyze the public-facing part of the application, just as a human pentester would without an account. The more authenticated areas it can explore, the more complete the assessment.

This article explains the different ways to provide those credentials and how to choose the option that maximizes test coverage.

Ways to provide the credentials

There are several ways to deliver test credentials. Only one factor determines how much the agent can cover: that at some point it can read the email associated with the account.

  1. Create the credentials with an email the agent can read. For example, a mailbox on a domain that Strike manages (such as @strike.sh). You create the credentials in your own system, outside Strike, and share them with the team through 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 access. As with the previous option, the credentials are created outside Strike and shared with the team through the platform. Coverage is equivalent.

  3. Allow the agent to create its own credentials from the portal, when your platform supports self-service user registration. Depending on how the platform is configured, that account may have limited access, so the agent might not be able to work the way intended and some flows or areas could fall outside the test scope.

  4. Share the credentials of an account whose associated email the agent cannot read. The test proceeds normally, but the flows that depend on email fall outside its 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 rely on a message arriving in the inbox. The most common ones are:

  • Password recovery

  • Email verification

  • Two-factor authentication (2FA)

  • Magic links

If the agent cannot access that email, these flows fall outside the test scope. This does not affect the quality or depth of the rest of the assessment: it simply narrows which areas can be covered. That is why having an email the agent can read makes it possible to extend coverage a bit further.

Our recommendation

  • Use dedicated test credentials rather than personal 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 email the agent can read and share them with the Strike team through the platform. It takes a few minutes and also enables the flows that depend on email.

  • If you prefer another option, you can still go ahead: the test continues as normal, and only the flows that depend on email would fall outside its scope.

The decision about which credentials to use is yours, and it defines the scope of the test based on what works best for your organization.

Questions about your case?

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