Your first scan

You need the CLI installed and your app running on localhost. This guide uses L1, the policy available in the current release. A model is optional for L1.

1. Create the configuration

Open a terminal in the project you want to test:

insidia init

This writes insidia.yaml. If you already have that file, keep it and review its targets.

2. Point it at your app

Open insidia.yaml before you scan. The generated target is a sample chat endpoint at http://127.0.0.1:8080/chat; replace it with your app’s endpoint. Match kind, request_template, and response_selector to the request and response your app actually uses.

Keep scope on localhost for this first run. See Configuration for target types and examples, and Scope before adding a host.

3. Check the setup

insidia doctor

Doctor checks Python, the config, configured model endpoints, and installed engines. It does not check that your target app responds correctly. Review its output and confirm your app is running.

4. Run L1

insidia scan --policy L1

Exit code	Meaning	Next step
0	The run completed and the policy passed.	Review the report’s coverage and findings.
1	The run completed and the policy failed.	Review the findings and fix the issues.
2	The run was incomplete, or an error stopped it.	Read the error or skipped checks; resolve setup problems before treating the result as a pass.
130	The run was cancelled.	Run it again when ready.

For a local scope, --yes is unnecessary. A non-local host needs both your authorization in the config and --yes at scan time.

5. Review and repeat

insidia report --open

The run is saved in .insidia/runs/<run-id>/. Read the report to check execution status, inspect the evidence, and choose fixes. After changing your app, run insidia scan --policy L1 again to check it.

Built-in probes work without installing extra engines. See Install engines when you want to add tools or compare coverage.

If the run stops or is incomplete, use Troubleshooting. Once it works locally, run it in CI.