Skip to content

Approvals and safety

Approval workflows require explicit human review.

Approval model

  • Workflows can pause with status: "awaiting_approval".
  • Review pending details before deciding.
  • Approve only the exact requested command or plan.
  • Reject anything outside approved scope.

CLI approval example:

skyportalai --json chat status 123

skyportalai chat approve \
  123 APPROVAL_ID \
  --type bash_command \
  --command "EXACT REVIEWED COMMAND"

CLI rejection example:

skyportalai chat reject \
  123 APPROVAL_ID \
  --type bash_command \
  --reason "Outside the approved scope"

Security behavior

Every authenticated request carries an API credential, so clients validate targets before sending traffic.

  • Remote targets must use HTTPS.
  • HTTP is allowed for localhost, 127.0.0.1, ::1, and *.localhost.
  • Embedded URL credentials, query strings, fragments, malformed ports, and non-HTTP schemes are rejected.
  • Trusted non-loopback HTTP requires SKYPORTAL_ALLOW_INSECURE=1 and emits a warning.
  • Authenticated requests use root-relative API paths to prevent cross-origin credential forwarding.
  • Interactive client does not follow authenticated HTTP redirects.
  • Saved credentials/config use user-only permissions on POSIX systems.

Warning

Never include real API keys, access tokens, approval IDs, hostnames, or private infrastructure data in examples or logs.

Safe operational examples

Use low-risk prompts and actions in examples:

  • “Report disk usage and identify largest directory.”
  • “Inspect previous job logs.”
  • “Check API connectivity.”

Avoid unreviewed destructive actions and unconditional automatic approvals.