Best practices for authenticated scanning with Zitadel / Keycloak

Hi, thanks for the detailed write-up!

values.yaml / static tokens: The open-source CLI does not read a values.yaml, and it has no flag that injects headers or cookies. You give Strix authentication context with --instruction or --instruction-file. That text is added to the agent's task, so you can paste a Bearer token or cookie there, but nothing attaches it to requests automatically. Short-lived tokens are also a problem: Keycloak access tokens expire after 5 minutes by default. A dedicated test account works better.

Automated login: Yes. The agent drives a headless Chrome browser, so it can follow the OIDC redirect to your identity provider, fill in the login form, and continue with the session. There is no separate login-script hook. You describe the flow in an instruction file instead.

We checked this against Keycloak 26 behind oauth2-proxy, with a planted IDOR in the app. Without instructions, the scan only saw redirects to the login page and reported nothing in the app. With the file below, it logged in through Keycloak, reached the API, and found the IDOR.

Example auth.md:

## Authentication
The app uses Keycloak (OIDC). Opening https://app.example.com redirects to
https://sso.example.com/realms/acme/... for login.

Test accounts (no MFA):
- Regular user: tester@example.com / REGULAR_PASSWORD
- Admin user: admin-tester@example.com / ADMIN_PASSWORD

Log in through the browser, then reuse the session cookie / Authorization header
for direct HTTP testing. If you get a 401 or land on the login page, log in again.
Use both accounts to test access control between roles.

Then run:

strix -n -t https://app.example.com --instruction-file ./auth.md

A few tips:

• Turn off MFA on the test accounts. The CLI has no built-in way to receive OTP codes or approve push prompts.
• Use dedicated test accounts. Instructions become part of the prompt sent to your LLM provider, so do not use real user credentials.
• Read the report, not just the summary. A "0 vulnerabilities" summary only covers what the agent reached. Open strix_runs/RUN_NAME/penetration_test_report.md to confirm it got past the login. If run.json shows the cost close to --max-budget, the agents were stopped early: findings can then appear in the report without being counted.

Docs: Custom instructions and Browser.

If you would rather not manage this yourself, the managed platform at app.strix.ai has saved test users with support for authenticator-app (TOTP) and email-code logins, and it verifies the login before the scan starts.