Command-line interface

The tripwire CLI provisions and manages tripwires from a terminal, CI, or immutable-infra userdata. The API surface is identical on SaaS and self-host, so the CLI is endpoint-agnostic — point it at either deployment.

Authenticate

Either store a scoped API key, or log in once to mint one:

# non-interactive: store an endpoint + API key
tripwire configure --set-endpoint https://api.gettripwires.com --set-api-key tw_...

# or log in (username/password) and mint a key automatically
tripwire login --endpoint https://your-control-server.example

Config precedence is flags > environment > config file (~/.config/tripwire/config.yaml). Environment variables: TRIPWIRE_ENDPOINT, TRIPWIRE_API_KEY, TRIPWIRE_ORG, TRIPWIRE_PASSWORD.

Create & manage tripwires

The primary noun is the technology (postgresql, kubeconfig, docx…); the CLI derives the transport automatically.

# create a PostgreSQL decoy, tagged, in a namespace
tripwire create postgresql --name prod-db-primary \
  --tag env=prod --tag instance-id=i-0abc123 \
  --namespace team/prod

# list / filter (server-side); --json or --csv for scripting
tripwire list --search billing --tag env=prod --technology postgresql
tripwire get <id>
tripwire update <id> --name new-name --namespace team/prod/db   # move namespace
tripwire delete <id>
tripwire events <id> --all     # detections (trips) for a tripwire

Organizations, roles & namespaces

Use --org <id> (or TRIPWIRE_ORG) to act within an organization; omit it for your personal workspace. Admins manage members and constrain them to namespaces.

tripwire orgs create "Acme Security"
tripwire orgs list
tripwire orgs members <org-id>

# add a member constrained to namespaces (repeat --grant)
tripwire orgs add-member <org-id> alice@corp.example \
  --role member \
  --grant team/prod:read \
  --grant team/staging:write

tripwire orgs set-role <org-id> <user-id> admin
tripwire orgs remove-member <org-id> <user-id>

Namespaces are hierarchical paths (Vault-style)

A grant covers its own path and everything beneath it: --grant team/prod:write grants write on team/prod and team/prod/db, while --grant team/prod/db:read covers only that leaf — never its parents or siblings. Write on a parent confers write on descendants; read does the same for visibility.

Scoped API keys

Keys carry the format tw_<keyId>.<secret> and the full key is shown once at creation. Grant only the scopes a key needs with one or more --scope flags:

Scope	Allows
`tripwire:create`	Create tripwires
`tripwire:read`	List & read tripwires and their trips
`tripwire:update`	Update existing tripwires
`tripwire:delete`	Delete tripwires

# create-only key for CI (the full key is shown once)
tripwire keys create --name ci-deployer --scope tripwire:create

# a read-only key for a monitoring dashboard
tripwire keys create --name dashboard --scope tripwire:read

# multiple scopes — repeat the flag
tripwire keys create --name deployer --scope tripwire:create --scope tripwire:delete

tripwire keys list
tripwire keys revoke <key-id>

API keys can never manage other keys — key creation/revocation requires an interactive session, not a key.

Declarative apply

Batch-create from a manifest (default tags merge into each entry):

tripwire apply -f tripwires.yaml --dry-run
tripwire apply -f tripwires.yaml