Configuration

Inkog is configured with command-line flags, two environment variables, and an optional .inkogignore file for suppressions. There is no .inkog.yaml config file; everything below is what the CLI actually reads.

Command Line Flags

Flags take precedence over environment variables. Both syntaxes work: inkog ./src (positional) or inkog -path ./src. Single-dash and double-dash forms are equivalent (-policy and --policy).

Flag	Default	Description
`-path`	`.`	Directory or file to scan
`-policy`	`balanced`	`low-noise`, `balanced`, `comprehensive`, `governance`, or `eu-ai-act`
`-severity`	`low`	Minimum severity to report: `critical`, `high`, `medium`, `low`
`-output`	`text`	`text`, `json`, `sarif`, or `html` (written to stdout; redirect to a file)
`-repo`		Scan a remote repository URL instead of a local path
`-agent-name`	auto	Name used for the agent in the dashboard
`-max-files`	`500`	Maximum files to upload
`-deep`	`false`	Run an Inkog Deep scan (requires the Deep role)
`-diff`	`false`	Report only findings that are new since the baseline
`-baseline`	`.inkog-baseline.json`	Baseline file used by `-diff`
`-update-baseline`	`false`	Write the current findings as the new baseline
`-verbose`	`false`	Detailed output
`-no-color`	`false`	Disable colors (also honored via `NO_COLOR`)

Full list: inkog -help, or see the commands reference.

Environment Variables

Variable	Description
`INKOG_API_KEY`	API key. Required for cloud scans. Can also be saved to `~/.inkog/config.json` on first run.
`INKOG_SERVER_URL`	Override the API endpoint (default `https://api.inkog.io`), for self-hosted deployments.
`CI`	When set (most CI platforms set it), spinners and interactive prompts are disabled.
`NO_COLOR`	Disables colored output.

See Environment Variables.

Suppressing Findings

Suppressions are evaluated server-side during the scan; the suppressed findings are dropped from the results while the reasons stay in your repository for audit.

Inline comments

Suppress a finding on the same line, or on the next line, by rule id. Rule ids are the pattern_id values shown in scan output, for example exec_eval, sql_injection, prompt_injection, missing_oversight.


result = eval(expr)  # inkog:ignore exec_eval "expr is a validated arithmetic string"
 
# inkog:ignore-next-line sql_injection "table name comes from an allowlist"
cursor.execute(f"SELECT * FROM {table}")


// inkog:ignore-next-line prompt_injection "input is schema-validated upstream"
const prompt = `Process: ${userInput}`;

`.inkogignore` file

Create a .inkogignore file (YAML) in the directory you scan. Each rule needs at least one matcher (pattern, category, risk_tier, or severity) and a reason. Optional audit fields and an expiry date keep suppressions reviewable.

.inkogignore


version: "1"
suppressions:
  # Suppress one rule everywhere under a path
  - pattern: token_bombing
    paths: ["scripts/**", "notebooks/**"]
    reason: "Batch jobs run with a hard token budget set by the scheduler"
    approved_by: "security@example.com"
    approved_date: "2026-09-04"
    expires: "2027-03-01"
 
  # Suppress one finding at an exact location
  - pattern: exec_eval
    file: "agents/calculator.py"
    line: 42
    reason: "Input restricted to digits and operators by the regex above"
    jira_ticket: "SEC-118"
 
  # Hide an entire tier while you triage (use sparingly)
  - risk_tier: hardening
    reason: "Hardening items tracked in the Q4 backlog"

Matchers: pattern (rule id), category (for example governance, injection, resource_exhaustion), risk_tier (vulnerability, risk_pattern, hardening), severity (CRITICAL, HIGH, MEDIUM, LOW). Location filters: paths (glob list), or file plus optional line.

The current CLI uploads .inkogignore with the scan. Expired suppressions are ignored.

Baselines for CI

Record the findings you already know about, then fail only on new ones:


# Once, on the main branch
inkog -path . -update-baseline
 
# On every pull request
inkog -path . -diff

The baseline file (.inkog-baseline.json by default) can be committed. See CI/CD Integration for GitHub Actions, GitLab CI, and Jenkins examples that use it.

Files that are never scanned

The CLI skips node_modules, vendor, .git, virtual environments, build output, and minified bundles. Paths under test and fixture directories (tests/, __tests__/, fixtures/, examples/, docs/examples/, benchmarks/, migrations/) are uploaded but produce no findings, because the server treats them as test infrastructure. The scan summary reports how many files were classified this way (fixture_files and fixture_dirs in JSON output). Keep agent code out of those directories, or scan it with an explicit path.