Cloud risk operations

This page is for customers who need to appeal a Cloud security decision and for operators who handle those appeals. Mockarty Cloud checks account registration, hosted checkout, and Shared or Managed runtime creation. If an action is blocked, the customer can request a review in the Cloud cabinet. Operators can inspect the related case and release a restriction after verification.

The case API returns limited information. It does not return credentials, payment-card data, full request bodies, or raw device identifiers.

For checkout, send a fresh Idempotency-Key for each business operation and reuse that exact key only when retrying the same operation after a lost response. An exact completed retry returns the already settled subscription/invoice result with replayed: true; it does not charge again. Reusing a key with a different amount or scope returns an idempotency conflict. If Cloud cannot prove whether a payment effect completed, it returns 503 risk_unavailable and blocks an automatic repeat until reconciliation; do not switch providers or invent a new key for that same attempt.

Customer reviews and appeals

Open Security & Account → Reviews and appeals in the Cloud cabinet. The list shows only a public case reference, the current review state, timestamps, and the status of an appeal submitted by the signed-in user. It never shows detector signals, thresholds, policy identifiers, fingerprints, payment-provider evidence, or another customer’s data.

A case is visible only to its exact principal, the Billing Account owner, or a Space owner, administrator, or billing manager for the affected Space. A Space viewer or editor cannot view or appeal a billing decision merely because they can use that Space.

Choose Request review, explain why the decision should be checked, and send the appeal. The explanation must contain 10–2,000 characters. Do not include passwords, payment-card data, API keys, or other secrets. Mockarty uses a stable idempotency key for that exact submission, so retrying after a lost response cannot create duplicate active appeals. The cabinet shows the review team’s response when the appeal is resolved.

The operator surface requires PostgreSQL and a verified Cloud operator. Use a dedicated API token with operator:risk:read for monitoring. Releasing an enforcement requires either an interactive one-time step-up proof or a token with the exact operator:risk:write scope. Do not use a wildcard token for support automation. Operator risk routes are intentionally excluded from automatically generated MCP tools.

Review cases

mockarty-cli --server 'https://cloud.mockarty.ru' --token "$MOCKARTY_TOKEN" \
  cloud-risk cases --status open --limit 50

mockarty-cli --server 'https://cloud.mockarty.ru' --token "$MOCKARTY_TOKEN" \
  cloud-risk case CASE_ID

When a response contains next_cursor, pass it unchanged as --cursor NEXT_CURSOR. The cursor is bound to the selected status filter; changing --status requires starting again without a cursor. If a case changes status between pages, the API returns 409 cursor_stale; restart from the first page so no case is silently skipped.

The detail response contains the case, its minimized decision events, and reversible enforcements. It returns at most the 100 newest events and 100 newest controls, plus any older source event required to review an active control. The events_truncated and enforcements_truncated flags disclose that older immutable records remain retained. Release stays unavailable unless the exact source_event_id evidence is present. reason_code is intended for support routing; detector thresholds and other customers’ identifiers are not included.

Release an enforcement

Verify the customer request and the current enforcement revision before releasing it:

mockarty-cli --server 'https://cloud.mockarty.ru' --token "$MOCKARTY_TOKEN" \
  cloud-risk release CASE_ID ENFORCEMENT_ID \
  --revision 2 \
  --reason 'customer identity verified by support ticket SUP-1042'

The revision prevents two operators from applying stale decisions. A 409 revision_conflict means the case changed; read it again and do not repeat the old command. The release reason is mandatory and recorded with the decision. Write a support-case reference and brief rationale, not customer personal data. When the case has no other active restriction, it is resolved automatically.

Release requires an Idempotency-Key. The CLI and Go/Python/Java SDK methods derive a stable key from the exact case, enforcement, revision, and normalized reason, so repeating the same command after a lost response returns the committed release with replayed: true. A changed revision or reason is a different operation and must not reuse the old request.

SDK equivalents are CloudRisk().ListCases/ListCasePage/GetCase/ReleaseEnforcement in Go, client.cloud_risk in Python, and client.cloudRisk() in Java.

Security admission is separate from ordinary HTTP rate limits, plan quotas, and payment-provider authentication. A provider timeout or an ambiguous payment result must be reconciled; it must never be retried against another payment provider as if no charge occurred.