Skip to main content
The Admin page manages LLM provider credentials, scan targets, defaults, and database operations. All settings persist in a local SQLite database with credentials stored securely in the OS keyring. Access via the gear icon in the navigation bar, or navigate to /admin.

​
Providers Section

Add and manage LLM provider credentials. Multiple providers can be configured for redundancy or model variety.

​
Provider Table

Displays all configured providers with status and action buttons:
  • Provider: Name (e.g., “anthropic”, “openai”)
  • Status badge: “configured” (green)
  • Actions:
    • Edit: Modify API key or base URL
    • Test: Validate credentials with a simple API call
    • Delete: Remove the provider

​
Add / Edit Provider Form

Provider dropdown: Select from available providers:
  • Cloud providers (require API key):
    • anthropic
    • openai
    • groq
    • openrouter
  • Local providers (require base URL):
    • ollama (defaults to http://localhost:11434)
    • lmstudio (defaults to http://localhost:1234)
  • custom: Bring your own provider with custom API endpoint
Fields:
  • API Key (cloud/custom providers): Stored securely in OS keyring. Password input field for safety.
  • Base URL (local/custom providers): HTTP endpoint for the provider. Required for non-cloud models.

​
Provider Testing

Click Test next to a provider to validate:
  1. Network connectivity to the endpoint
  2. API key validity (if applicable)
  3. Model availability
Result appears inline (success/failure with message).
Test your providers after configuration to catch credential errors early. Testing is non-blocking; other settings can be configured in parallel.

​
Provider Deletion

Click Delete to remove a provider. If it’s set as the default, you’ll be prompted to select a new default before deletion completes.
Deleting a provider doesn’t affect past runs. Historical results remain accessible; only future runs will be blocked if using that provider.

​
Defaults Section

Configure defaults for workflows that haven’t specified explicit values.

​
Display Mode

When defaults are set, a read-only table shows:
  • Provider / Model: Display of currently selected provider and model variant
  • Audit Transport: Default MCP transport (stdio, sse, or streamable-http)
  • IPI Callback URL: Default listener endpoint for indirect prompt injection tests
Edit button: Switch to edit form. Clear button: Remove all defaults.

​
Edit Form

Fields available for configuration:
  • Provider / Model: Dropdown selector populated from configured providers.
    • Selecting a provider populates available model variants.
    • Example: provider=“anthropic”, model=“claude-3-5-sonnet”
  • Audit Transport: Select default transport for MCP connections.
    • stdio: Invoke command; used by default in Launcher forms
    • sse: Server-Sent Events over HTTP
    • streamable-http: HTTP streaming protocol
  • IPI Callback URL: Listener endpoint for callback-based indirect prompt injection tests.
    • Example: https://your-domain.example.com/callback
    • Can be overridden per-run in the Launcher

​
Saving Defaults

Submit the form to save all values. UI automatically switches back to display mode on success. Changes apply immediately to new workflow runs.
Defaults don’t affect already-running workflows. In-progress runs use values set at launch time.

​
Infrastructure Section

Configure MCP server and connection parameters for advanced scenarios.

​
MCP Connection Settings

  • MCP Connection Type: Select how the UI connects to MCP servers during testing (stdio, sse, streamable-http)
  • Custom MCP Endpoint (optional): For advanced deployments, specify a custom MCP server to connect to instead of the built-in one
Leave these at defaults for typical use. Advanced configurations are needed only for:
  • Multi-machine deployments
  • Custom MCP server implementations
  • Load-balanced MCP clusters

​
Bridge Token Management

The internal bridge token is used for secure communication between the UI and backend. It’s automatically generated and cached in memory; no manual intervention is needed. To rotate the bridge token:
  1. Stop the server (Ctrl+C)
  2. Delete ~/.qai/bridge.token
  3. Restart with qai
A new token is generated on next startup.

​
Scan Targets

Manage scan targets — the MCP servers, platforms, or endpoints that security tests run against.

​
Target Table

Displays all configured targets with:
  • Name: Human-readable identifier
  • Type: server (MCP server) or platform (agentic platform)
  • URI: Connection endpoint (if configured)
  • Delete button: Remove the target
Targets are sorted alphabetically by name.

​
Deleting Targets

Click the trash icon to delete a target. A confirmation modal appears showing:
  • The target name
  • Warning that associated runs will be orphaned (not deleted)
Deleting a target sets target_id to NULL on associated runs. The runs themselves remain accessible with their findings and evidence intact.
Use target deletion to clean up test targets or remove duplicates. Historical run data is preserved for audit purposes.

​
Database

Database management operations for backup and reset.

​
Backup

Click Create Backup to create a snapshot of the database. Backups are saved to ~/.qai/backups/ with timestamped filenames: 
~/.qai/backups/qai-2025-04-10-143052.db
A success toast shows the backup path. Use backups before destructive operations or when migrating to a new machine.
You can also create backups via CLI: qai db backup or qai db backup /custom/path.db

​
Danger Zone

The Danger Zone contains destructive operations that require explicit confirmation.

​
Reset Database

Resets the database to a clean state. Before resetting:
  1. An automatic backup is created
  2. You must type RESET to confirm
What gets deleted:
  • All scan targets
  • All runs, findings, and evidence
  • All IPI campaigns and callback hits
What’s preserved:
  • Provider credentials (stored in OS keyring)
  • Provider configurations
  • Default settings
Reset is irreversible. The automatic backup is your safety net — verify it exists before proceeding.

​
Data Persistence

All settings are stored in the local SQLite database (~/.qai/qai.db). This includes:
  • Provider configurations (API keys in OS keyring, metadata in DB)
  • Workflow defaults
  • Run history and results

​
Backing Up Settings

The easiest way to back up is via the Admin page’s Create Backup button or qai db backup CLI command. For manual backup (e.g., scripted or when the server isn’t running), stop the server and copy all database files: 
# Stop the server first (Ctrl+C in the terminal, or kill the process)
pkill -f 'qai' || true

# Copy the main DB and WAL/SHM files if present
cp ~/.qai/qai.db ~/backup-qai.db
cp ~/.qai/qai.db-wal ~/backup-qai.db-wal 2>/dev/null || true
cp ~/.qai/qai.db-shm ~/backup-qai.db-shm 2>/dev/null || true
Restore from backup: 
# Stop the server first
pkill -f 'qai' || true

# Restore all DB files
cp ~/backup-qai.db ~/.qai/qai.db
cp ~/backup-qai.db-wal ~/.qai/qai.db-wal 2>/dev/null || true
cp ~/backup-qai.db-shm ~/.qai/qai.db-shm 2>/dev/null || true

# Restart the server
qai
SQLite WAL mode uses -wal and -shm companion files. Copying only qai.db while the server is running can produce a corrupted backup. Always stop the server and include all three files.

​
Credential Storage

API keys and sensitive credentials are stored in the OS-level keyring:
  • macOS: Keychain
  • Linux: Secret Service or pass
  • Windows: Windows Credential Manager
The database stores only provider metadata (name, type, base URL). Keys are never written to disk in plain text.
If the OS keyring becomes unavailable (e.g., locked, not initialized), credential operations will fail. Unlock your keyring or reinitialize it according to your OS.

​
Syncing with CLI

Settings configured in the Web UI are immediately available to CLI commands and vice versa. Both use the same database and keyring. Example workflow:
  1. Configure a provider in the Web UI
  2. Use it in a CLI command: qai inject campaign --model anthropic/claude-sonnet-4-20250514
  3. Return to Web UI; the provider is already available for selection

​
Resetting Settings

The Admin page’s Reset Database button in the Danger Zone provides a safe reset with automatic backup. You can also use qai db reset from the CLI. For a complete manual reset:
  1. Remove the settings database: rm ~/.qai/qai.db
  2. Restart the server: qai
A fresh database is created with no defaults or providers configured.
Deleting qai.db only resets the database — provider API keys stored in the OS keyring are not removed. To fully clear credentials, manually remove provider entries from your system keyring (via your OS keyring manager or the keyring CLI) after deleting the database.
Use this approach if you encounter credential issues or want to start fresh. Your run history will be lost; export results before resetting if needed.