Run a managed pentest of a web app, API, repository, or local workspace on the app.strix.ai platform with the `strix cloud` CLI or REST API — no local Docker or LLM key needed. Safely review and upload local source, register assets, launch and poll scans, triage vulnerabilities, export SARIF, downlo

Strix Cloud (managed, no local infra) Use this when you want Strix's autonomous pentesting without running Docker or an LLM yourself — the scan runs on Strix's infrastructure and results are tracked in a team dashboard. This is the right choice in sandboxed/hosted agent and CI environments, for teams, and for scheduled/continuous testing (downloadable PDF/DOCX reports are an Enterprise plan feature). For fully local, free, air gapped, or BYO LLM runs, use the open source CLI in the penetration testing with strix skill instead — both share the same engine and SARIF output, so you can mix them. There are two equivalent interfaces. Prefer the CLI: strix cloud CLI — every REST operation has a command in the form strix cloud <resource <verb . Install with curl sSL https://strix.ai/install bash . Run strix cloud to list all resources and strix cloud <resource help (or h ) to list a resource's verbs; a bare resource with a safe read operation runs its documented default. REST API — base URL https://app.strix.ai/api/v1 , Authorization: Bearer <token on every request. Full reference: [docs.app.strix.ai](https://docs.app.strix.ai) · agent index: https://docs.app.strix.ai/llms.txt · OpenAPI: https://docs.app.strix.ai/openapi.json . The CLI is equally usable by agents and people. Output is complete JSON when stdout is not a terminal, or when you pass json ; terminal tables favor names, branches, lifecycle states, and numbered selectors. Human lists retain the selectors needed by follow up commands but omit internal organization/user IDs; a selector too long for the compact table is repeated losslessly in a copyable block. Paginated lists print the next page or offset , and detail views preserve useful prose within a safe terminal bound; use json for the complete record. Token lists label credentials as active, expired, or revoked. Binary downloads are the exception: redirect raw bytes intentionally, or use output FILE json to write the file and receive structured metadata. There are no interactive prompts when stdin is not a terminal. Exit codes: 0 success, 1 request/runtime error, 2 invalid usage, 4 authentication or plan limit, 5 payment required. Every resource group with a safe read operation has a useful default action, and h or help always shows its verbs. Native tab completion includes resources, verbs, flags, workspace commands, and local paths: Write commands take request fields as flags. Every write command also accepts one JSON object with data , which is the way to send fields that have no flag: The platform enforces plan and role limits, and the CLI passes the platform message through. Report downloads need the Enterprise plan. Schedules need the Pro plan. Billing writes need an admin token. A blocked command exits with code 4 . Setup: sign in Run the device sign in. It creates the user's account and workspace on first use and stores a personal API token in ~/.strix/platform auth.json : The user approves the sign in in the browser. With scopes (and optionally workspace <name or id ) there are no terminal prompts, so the command works from a non interactive agent shell. In an interactive terminal without flags, the CLI offers a workspace picker and scope presets (Recommended, Full access, Minimal, Custom). Recommended covers ordinary scans, source uploads, workspace switching, and user approved credit top ups; it excludes tokens:write , which must be requested explicitly when credential management is required. Use explicit scopes for a narrower automation token. strix cloud whoami is the fast local status. strix cloud session json verifies the remote device session; strix cloud session scopes shows both effective access and the immutable login ceiling. strix cloud logout revokes the remote session before removing the local token. On a network or server failure it keeps the token so the user can retry; local only deliberately skips revocation. Every other strix cloud command uses the stored token automatically. token <token or STRIX API TOKEN is a stateless per command override and never overwrites the stored account. For an override that is itself a CLI session, also pass workspace id or set STRIX WORKSPACE ID . Never hardcode, log, or commit the token. Store it in an env var or the CI secret store. Scopes (least privilege): assign only what the integration needs and rotate regularly: Scope Grants scans:read / scans:write list/read/report scans · create/rerun/cancel scans vulnerabilities:read / :write read findings · update status & notes assets:read / :write read domains/repos · register/update them schedules:read / :write read schedules · create/trigger recurring scans pr reviews:write trigger PR security reviews webhooks:read / :write manage webhook subscriptions uploads:write upload local source or documents for a scan organizations:read read organization details (listing/switching the signed in user's workspaces needs no API scope) organizations:write create/update workspaces (admin) tokens:write create/revoke ordinary API tokens (not needed to manage the current CLI session) knowledge:read / :write read/update organization knowledge audit:read read/export the Enterprise audit log billing:read / billing:write read credit balance & auto top up settings · buy credits (admin) HTTP errors map to messages and exit codes: 401 bad/expired token (exit 4 ), 402 out of credits (exit 5 ), 403 scope/plan tier limit (exit 4 ), 422 validation error (exit 1 ). Create a time limited automation token with strix cloud tokens create . Use rbac scopes to restrict it to target IDs, tags, or business units; the value is a JSON array of { "type": "target tag business unit", "value": "..." } objects: The token secret is returned once. Store it directly in a secret manager and do not print or commit it. expires at and expires in days are mutually exclusive. 0. Credits & top ups Non Enterprise scans consume org credits. Enterprise engagements are plan included and do not debit the wallet. Check the balance before a scan ( billing:read ): When the balance is too low, buy credits with strix cloud billing topup ( billing:write , admin token). The server answers the first request with HTTP 402 and a machine payment challenge (Stripe Machine Payments Protocol). The CLI pays the challenge with the Stripe Link wallet client when Node.js is available — the user approves the spend in the [Link app](https://link.com/agents). The response returns the receipt ( credits granted , duplicate , reference ) and the new balance. A default tier source only code review currently starts at 60 credits. Source uploads are not free: they launch an ordinary code review and use the same deterministic scope estimator. The service checks the full balance before launch, reserves credits atomically only after validation succeeds, and does not create or charge a rejected scan. Retests and Enterprise scans are exempt. The default payment path is the Stripe Link wallet. When no wallet is connected, an interactive strix cloud billing topup starts the Link sign in for the user and prints the verification link. The user approves the connection one time in the Link app, and then approves each payment there. No keys or variables are necessary. In a non interactive process, the command stops and tells the user to connect the wallet at [link.com/agents](https://link.com/agents) or to use the hosted checkout link. In a non interactive agent or CI process, payment never proceeds unless the command includes yes . Show the challenge or estimated spend to the user and obtain approval before adding it. no pay always stops after printing the challenge. If the user does not want a wallet, create a hosted checkout link with strix cloud billing subscribe plan strix top up and give the link to the user. The user pays in the browser. Automatic top ups (admin): strix cloud billing auto topup shows the setting. Enable it with: An omitted monthly cap credits keeps the stored cap. Pass no monthly cap to remove the cap. Workspaces and account setup Manage workspaces with a personal token from strix cloud login : workspaces use retargets the current personal token to a workspace the user already belongs to and stores the updated workspace metadata; the bearer secret and expiry stay unchanged. It does not reprompt during ordinary switches: the server preserves the chosen profile, enforces the immutable login ceiling, and caps effective scopes by the target role. Use scope profile or scopes to narrow within that ceiling; broader consent requires strix cloud login again. The CLI pins each process to the workspace it started in, so concurrent shells fail with a recoverable conflict instead of silently crossing organizations. Handoffs a person must finish Four steps end at the user. The command creates the link or the record and prints it. Strix opens the browser only in an interactive terminal. Pass no browser to print the URL only. Give the printed URL or DNS record to the user and wait. Do not claim that the payment, the installation, or the DNS change is complete. Confirm the result afterwards with strix cloud credits , strix cloud integrations list , or strix cloud domains list . All four commands need an admin token, except domains verify , which needs assets:write . Organization knowledge Agents can manage the organization knowledge base without the dashboard ( knowledge:read / knowledge:write ): Knowledge policy writes require an admin token. Repository names are passed as normal owner/name values; the CLI handles URL encoding. The costs and llm settings commands target on prem installations and return 404 on app.strix.ai. 1. Register the target as an asset Scans run against registered assets , not raw URLs. Register once, then reuse the returned UUID. Look up existing assets instead of re adding: strix cloud domains list , strix cloud repos list (both assets:read ). 2. Launch a scan strix cloud scans start ( scans:write ). Provide at least one target with domain ids , repository ids , or internal targets (internal infra needs a network connector — see docs). Useful flags (each maps to a CreateScanRequest field): Flag Purpose engagement type live test (default), code review , internal infra , compliance pentest domain ids / repository ids / internal targets targets (at least one) domain paths / repository branches narrow to specific paths / branches (JSON maps) credentials authenticated scanning, incl. mfa method ( totp / email otp /…) + totp secret (JSON list) headers extra target HTTP headers as a JSON array of header objects focus / concerns / context free form strings that steer the agents upload ids attach uploaded source/docs archives for white box context notify on completion / notification emails email when done Without source , the response is { scan id, title, status } with status = pending . Local source success wraps that platform response as { source, upload id, scan: { scan id, title, status } } , so automation can retain the exact approved manifest and staged upload identifier alongside the created scan. Scan a local workspace in the cloud For an agent or CI workflow, bind approval to the exact source snapshot that was reviewed. Run the dry run with the intended source selection flags, review the manifest and selected paths, and capture source.archive sha256 . Then repeat the same source , every exclude , and any include hidden , include sensitive , or include archives flags with approve sha256 :

managed-pentesting-with-strix