You can configure Sentinel with a YAML config file to avoid retyping the same flags on every scan. The config file supports named profiles for multi-tenant or multi-environment workflows.

Config file locations

Sentinel looks for a config file in two locations and merges them:

Location	Scope
~/.config/sentinel/sentinel.yaml	Global — applies to all scans on this machine
./sentinel.yaml	Project-local — applies in the current directory only

Both files are optional. If both exist, the local file overrides the global one for any keys that overlap.

Precedence

Settings are applied in this order (lowest to highest priority):

global defaults → global profile → local defaults → local profile → env vars → CLI flags

CLI flags always win. Environment variables override config file values.

Config file format

# sentinel.yaml

defaults:
  # tenant: contoso.onmicrosoft.com   # Force a specific tenant (skips the picker)
  device_code: false                  # true = device code flow (for headless/SSH environments)
  output: ~/reports                   # Directory to write report files
  format: html,json                   # Output formats: html, json, pdf (comma-separated)
  no_open: false                      # Don't auto-open the HTML report in the browser
  no_color: false                     # Disable colored terminal output
  verbose: false                      # Show detailed progress during the scan
  baseline_name: default              # Named baseline: default, strict, cisa

  # AI — required for AI-assisted checks (e.g. SENT-ADCRED-004)
  # azure_openai_endpoint: https://your-resource.openai.azure.com/
  # azure_openai_deployment: gpt-4o
  # azure_openai_api_key: <key>        # Also accepted via AZURE_OPENAI_API_KEY env var

  # LDAP — user, group, stale object, and ADCS collection (cross-platform, no PowerShell required)
  # ldap_server: dc01.contoso.local:636   # host:port of a Domain Controller
  # ldap_tls: true                        # true = LDAPS (port 636), false = StartTLS
  # ldap_bind_dn: svc_audit@contoso.local # bind DN or UPN
  # ldap_bind_pass: <password>            # Also accepted via LDAP_BIND_PASS env var

profiles:
  contoso:
    tenant: contoso.onmicrosoft.com
    device_code: true
    output: ~/reports/contoso

  fabrikam:
    tenant: fabrikam.onmicrosoft.com
    output: ~/reports/fabrikam

  ci:
    no_color: true
    no_open: true
    format: json
    output: ./reports

Named profiles

Profiles let you switch between different tenants, clients, or environments with a single flag.

# Use the contoso profile
grantflow-sentinel cloud --profile contoso

# Override a profile setting for this run only
grantflow-sentinel cloud --profile contoso --output ./today

# Run without any profile (defaults only)
grantflow-sentinel cloud

If you specify a profile name that does not exist in the config file, Sentinel exits with an error and lists the available profile names.

Environment variables

You can set config values via environment variables. These override the config file but are overridden by CLI flags.

Variable	Maps to	Behavior
AZURE_OPENAI_API_KEY	defaults.azure_openai_api_key	Fallback — used only when the config value is empty
LDAP_BIND_PASS	defaults.ldap_bind_pass	Override — always wins over the config file value
NO_COLOR	defaults.no_color	Fallback — used only when the config value is empty

No ${VAR} expansion in sentinel.yaml

Sentinel does not expand environment variable references like ${LDAP_BIND_PASS} inside YAML values. If you write ldap_bind_pass: "${LDAP_BIND_PASS}", the literal string ${LDAP_BIND_PASS} is used as the password. Set the LDAP_BIND_PASS environment variable instead and omit ldap_bind_pass from the config file.

Security considerations

If your config file contains an azure_openai_api_key, add sentinel.yaml to .gitignore before committing your project directory:

echo "sentinel.yaml" >> .gitignore

Sentinel warns to stderr at startup if the file is world-readable and contains an API key.

Keep secrets out of version control

Never commit a sentinel.yaml that contains API keys, credentials, or tenant identifiers to a shared repository. Use environment variables or a secrets manager for CI/CD pipelines.

Baselines

A baseline defines the expected state for each check. Sentinel compares collected data against the active baseline and flags deviations as findings.

Three built-in baselines are available:

Name	Description
default	Balanced — recommended for most organizations
strict	Higher bar — appropriate for regulated industries or high-security environments
cisa	Aligned to CISA guidelines and M-22-09 requirements

Select a baseline with the --baseline-name flag or the baseline_name config key:

grantflow-sentinel cloud --baseline-name strict

You can also supply a custom baseline JSON file with --baseline /path/to/baseline.json.

Overrides

If you have accepted a risk or a finding does not apply to your environment, you can mark it as manually passed using an overrides file. This prevents the finding from affecting your score on future runs.

grantflow-sentinel cloud --overrides /path/to/overrides.json

The overrides file lists check IDs and an optional justification. Contact your security team for the format if you are using Sentinel in a managed environment.