These docs are in English. If you prefer German, write us at beta@clickprobe.ai.

Test Credentials

Many apps have a login wall. If ClickProbe never gets past it, it can only ever explore the one page behind it. The Credentials section on a project’s edit page lets you give the AI a test login so it can sign in and explore the rest of your app.

Credentials apply to every kind of session — the first-time exploration of your app, and the verification reruns ClickProbe fires when you push a fix for a bug it filed. A rerun’s whole job is reaching bugs an exploration session already found, and those bugs live wherever the exploration session had to sign in to see them — without a credential, a rerun cannot get past the same wall the exploration session needed one for.

What happens with no credential — or the wrong one

If your app has a login wall and no credential is configured (or none of the configured ones apply to the page ClickProbe needs), the AI does not guess a password, try common defaults, or sit there retrying. It records a clear, plain-language note that it hit a wall it could not get past and moves on to whatever else is reachable — which, for an app that requires signing in for everything, may be nothing beyond the login page itself. This shows up as an operational note, not a bug report against your app: a login wall ClickProbe cannot get past is ClickProbe’s limitation, not a defect in your application, unless the AI has genuine evidence the login itself is broken (in which case it is filed, the same as any other bug).

The same applies to a credential whose username is configured but has no usable password attached (for example, one that failed to save correctly, or one meant for a single sign-on provider ClickProbe cannot drive) — it is treated exactly like having no credential for that login, never guessed at.

Adding a credential

  1. Open your project and click Edit project.
  2. Under Credentials, click + Add credential.
  3. Enter a username and password, and optionally a role (e.g. admin) and a short note on when to use it (e.g. for the billing settings page).
  4. Click Save all.

The password field is write-only: once saved, it is never shown again, and the field simply reads “configured — enter a new value to replace”. Leaving it blank on a later edit keeps the password you already saved; you only need to type a new one when you actually want to change it.

What happens to the password

Be deliberate about what you paste here. In order:

  1. Storage. The password is encrypted before it is written to the database (the same mechanism ClickProbe already uses for GitHub/GitLab access tokens and webhook secrets), using a key stored on the same host as the database itself. The database is never returned to you or to anyone else in plaintext or ciphertext through the product’s API, UI, or project export.
  2. Disk encryption. The database host’s disk is not encrypted at rest. Encrypting the password column is what stands between a database backup or a disk image and the plaintext value — there is no second layer beneath it.
  3. The session prompt — exploration or rerun. When a session starts, the password is decrypted and included, in plaintext, in the instructions given to the AI — it needs the real value to type it into your app’s login form. This is true of every session type: a first-time exploration session and a bug-verification rerun both receive it, for the same reason (both may need to sign in to reach a page). That prompt is sent to Anthropic (the AI provider ClickProbe uses), in the United States, as part of running the session.
  4. ClickProbe staff. Anyone with production database access at ClickProbe can, in principle, read the encrypted column and (if they also had the encryption key) decrypt it. This is no different from any SaaS product that stores a secret on your behalf — the encryption defends against a stolen backup or a compromised disk, not against ClickProbe’s own operators.
  5. The session record. ClickProbe’s system prompt instructs the AI never to record a typed password into the session timeline (the “input value” shown next to an action), and the cloud additionally redacts a value that matches your stored password before it is saved. Treat this as a safety net, not a guarantee — the AI’s own behaviour is not perfectly predictable, and a value it phrases slightly differently than the exact stored password will not be caught by the redaction.

Our standing advice: use a dedicated, low-privilege test account for whatever app you’re pointing ClickProbe at — never a production administrator login. A test account limits the blast radius of every step above to something you’d be comfortable losing.

Removing a credential

Click the ✕ next to a credential row and click Save all. This deletes the stored (encrypted) password entirely — there is no way to recover it afterward, from ClickProbe or anyone else.