EvidencePacks & Transparency Log

Every Dralvia workflow produces an EvidencePack (Dralvia's exportable evidence report): think of it as a notarized envelope with all the facts needed for audits or incident response. If a term is unfamiliar (for example EvidencePack, Transparency Log, or SLO), open the Glossary.

Quick start (10 minutes)

1. Open transparency log view and load recent entries.
2. Select latest entry and run verification.
3. Fetch inclusion proof for one entry.
4. Verify one pack by hash/index.
5. Export verification outcome for audit notes.

Deep dive setup flow (GUI + API parity)

Prerequisites

• Active workspace API key.
• At least one recent workflow/scan that generated an EvidencePack.
• Pack identifier (pack_hash or transparency index) from your workspace history.

Exact fields to fill

• Verify request: pack_hash and/or transparency_index, optional inline pack JSON.
• Proof lookup: transparency entry index.

Step-by-step flow

1. GUI: open verifier and load recent entries.
2. API parity: GET /api/transparency-log?limit=100.
3. GUI: run verify on selected entry.
4. API parity: POST /api/trust/auditor/verify using matching pack_hash/transparency_index.
5. API: fetch proof with GET /api/transparency-log/proof/{index}.
6. (Optional) run threshold/compliance ZK flows for external attestation.

Expected result

• Verification returns pass/fail with consistent details in UI and API.
• Inclusion proof resolves and validates for selected entry.
• Evidence metadata is export-ready for audits.
• The verify response includes a pack_integrity block you can reproduce yourself: it recomputes the pack's merkle root from the pack's own artifacts and reports merkle_consistent and merkle_root_recomputed. Because this check needs no Dralvia secret, anyone you hand a pack to can independently confirm it has not been tampered with, separate from the Dralvia signature check.
• The response also includes a consistency block. Every Dralvia module (URL and phishing, smart contract, repository, email, web access, and agent surfaces) emits packs with the same trust anchors, so the block confirms the pack carries a surface label, a merkle anchor, and a signature and passes the integrity check, regardless of which module produced it.
• The response also includes a compact trust_receipt (schema: dralvia.trust_receipt.v1). It is a small, portable artifact you can share with a customer or auditor in a trust center: it carries the surface, merkle root, integrity and consistency outcome, and artifact count, but no secret and no raw pack body, so the recipient can independently confirm the evidence is intact and correctly formed.

Rollback path

1. If verification fails due to wrong identifiers, re-load recent entries and re-select the correct record.
2. Re-run verification with corrected inputs.
3. Record failed attempts with reason to keep audit trail complete.

Annotated screenshot

Figure: Load transparency entry, verify integrity, and export verification outcome.

What’s inside

• Summary (risk level, score, verdict reason)
• Persona explanations (Exec, SecOps, Compliance)
• Detailed results per subsystem (WHOIS, DNS, SSL, Content, Threat feeds, Email detonation, SWG, EDR actions, etc.)
• links and websites infrastructure summaries when available, including ASN, hosting provider, free-hosting provider, domain age, TLS certificate age, TLS issuer, and the infrastructure decision driver used by the scanner UI.
• Attachments (screenshots, DOM captures, transaction graphs)
• Pre-sign simulation replay metadata when a wallet-risk review includes chain-state simulation
• Merkle proof (root hash, leaf hash) + transparency log index

Downloading

• From any scan/alert view, click Download EvidencePack.
• Via API: GET /evidencepacks/<id> returns the JSON document.
• When sending cases to TicketBridge, the EvidencePack is attached automatically.
• The Reports workspace (#/reports) now opens on an Overview screen and splits generation and history/comparison into explicit sections instead of one long page.
• The Reports workspace (#/reports) now shows the pack hash for every Exec/Tech/Compliance report so you can cross-check against Transparency Log entries.
• Report history and internal report allowlist tables now paginate at 3 rows per page in the console.

Transparency log

• Visit #/transparency to browse the append-only log of EvidencePack entries.
• #/transparency now opens on Overview and keeps raw log browsing and single-proof review in dedicated Entries and Proofs sections.
• Each entry shows the index, timestamp, pack ID, and hash. Use Entries to open one proof at a time without losing the route-level integrity posture.
• For offline verification, request the CLI from Dralvia support or use the API to fetch proofs.

Proving the log only ever grew

An inclusion proof answers one question: is my entry in the log you are showing me now? It cannot tell you whether the log you are shown today is the same log you were shown last month. GET /api/transparency-log/consistency?old_size={N} answers the second question.

Record the merkle_root and the entry count whenever you read the log. Later, ask for a consistency proof against that earlier count. The response carries:

Field	Meaning
old_root / new_root	The root then, and the root now.
old_size / new_size	Entry counts the proof was built for.
proof.subtrees	Hashes covering the first old_size entries.
proof.path	Hashes joining those to the current root.
verified	Our own check of the proof, for convenience only.

Do not rely on verified. Recompute it yourself: fold proof.subtrees into old_root, fold that through proof.path, and compare against new_root. It needs no Dralvia secret and no copy of our log, and the proof stays small (roughly the base-2 logarithm of the log length, about ten hashes for a log of a few thousand entries).

Two limitations, stated plainly:

• Sizes are not hashed into a merkle root. Take old_size and new_size from the signed checkpoints, not from this response, if the exact counts matter to you.
• A proof is only as good as where you kept the old root. If the only copy of old_root lives on our infrastructure, the proof shows the log is internally consistent, not that it was never rewritten. Keep your own copy.

If the proof fails, the log you were shown earlier is not a prefix of the log you are shown now. Treat that as a tamper finding and contact support with both roots.

Anchors: proof that a root is not backdated

A consistency proof shows the log grew. It cannot show when. Both the log and the checkpoints live on Dralvia infrastructure, so on their own they cannot rule out the whole history being rebuilt and re-signed.

Dralvia therefore submits each checkpoint's digest to two independent RFC 3161 timestamp authorities, DigiCert and Sectigo, and publishes the resulting anchor records. Each record contains:

• the merkle root and entry count it covers,
• the hash of the exact signed checkpoint,
• the digest of the previous anchor, so the series is itself a chain,
• one timestamp token per authority.

Those tokens are signed by the authorities, not by Dralvia. We cannot produce one with a date we like, and neither can anyone who compromises us.

To check an anchor yourself, with openssl and nothing from us:

# Extract the token and confirm it covers the anchor digest.
python3 -c "import base64,json,sys; r=json.load(open('anchor.json')); \
  open('token.tsr','wb').write(base64.b64decode(r['timestamps'][0]['token_b64']))"

openssl ts -verify -digest "$ANCHOR_DIGEST" -in token.tsr \
  -CAfile /etc/ssl/certs/ca-certificates.crt

Verification: OK means the authority signed that exact digest at the time the token states. A message imprint mismatch means the anchor document was changed after it was stamped.

The anchors are published at https://github.com/Dralvia/transparency-log.

git clone https://github.com/Dralvia/transparency-log.git
cd transparency-log
python3 verify_anchors.py anchors/

verify_anchors.py imports nothing from Dralvia and makes no network requests. Read it first; it is about 150 lines.

Cloning the repository periodically is worth doing. A force push could remove anchors from the published history, and a clone you already hold is the record of what was there. It cannot be silently altered, because the timestamp tokens are signed by the authorities rather than by us.

Reading the checkpoint without an account

The current signed checkpoint is public. No account, no API key, no licence:

curl -A "my-verifier/1.0" \
  https://dralvia.tech/api/public/transparency-log/checkpoint

{
  "entry_count": 870,
  "merkle_root": "c18e6497c7f4...",
  "log_hash": "28b8ea365a71...",
  "issued_at": "2026-08-19T11:04:25.112289Z",
  "signature": {
    "algorithm": "Ed25519",
    "key_id": "primary-ed25519-2026-08-18",
    "value": "uiR5QqXTo8HXU4XL..."
  }
}

Set a User-Agent. Our edge rejects the default Python one with a 403, which looks like an outage and is not.

Verify it with the public key from the anchors repository and nothing from us:

import json, base64, urllib.request
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

req = urllib.request.Request(
    "https://dralvia.tech/api/public/transparency-log/checkpoint",
    headers={"User-Agent": "my-verifier/1.0"})
cp = json.loads(urllib.request.urlopen(req).read())

signed = {k: v for k, v in cp.items() if k not in ("signature", "witness_hash")}
message = json.dumps(signed, sort_keys=True, separators=(",", ":")).encode()

key = Ed25519PublicKey.from_public_bytes(base64.b64decode(PUBLISHED_KEY))
key.verify(base64.b64decode(cp["signature"]["value"]), message)  # raises if invalid

The response is served exactly as it was signed, including log_path. Removing any field would break the signature, so nothing is trimmed.

Record entry_count and merkle_root whenever you read it. Those two values, kept by you, are what later turn a consistency proof into evidence.

An independent witness you can read

Dralvia operates the log, the signing key and the anchors. A scheduled job on GitHub, which Dralvia does not operate, reads the public checkpoint every six hours, verifies its signature, and commits what it saw to https://github.com/Dralvia/transparency-log under observations/.

It fails loudly if the log reports fewer entries than previously recorded, or if an entry count it already saw comes back with a different root. Those runs are public on that repository's Actions tab.

It does not check that the current log contains the earlier one, because that needs a consistency proof and that endpoint requires an account. If you have one, run the consistency check as well. Together they are much stronger than either alone.

Who can sign a checkpoint

Checkpoints are signed with Ed25519. The public keys are published in the anchors repository above, so you can verify any checkpoint without asking us for anything.

The private keys are held in a secrets manager, not by the service that scans domains and serves verdicts. The scanning API can read a public key and check a signature; it holds nothing that can produce one. The job that signs checkpoints fetches the key for the length of a single run and gives its access back immediately afterwards.

This matters for one specific question you should ask of any transparency log: if the operator is compromised, can the attacker rewrite history and re-sign it so the rewrite verifies? For the scanning service the answer is no, because that key is not there to steal. A compromise deep enough to reach the signing key is still possible, which is why the anchors exist: the RFC 3161 timestamps are signed by DigiCert and Sectigo, and a re-signed history cannot be given an old date.

Two things this does not claim:

• It is not a hardware security module, and it is not threshold signing. A sufficiently deep compromise of our infrastructure could reach the key.
• A checkpoint verifying does not by itself prove the log was not rewritten. Pair it with a consistency proof against a root you kept, and with the anchors.

CI EvidencePacks

• Each pull request run of the release regression gate signs the URL and smart contract summaries via the EvidencePack signer bot.
• GitHub comments include the pack hash, signature (with key ID), and a link to the runner artifact (retained for 30 days).
• Download the artifact and run the EvidencePack verification CLI (evidencepack-cli verify --pack ci_evidencepack.json --secret-text "$KEY"), available from Dralvia support, if you want to independently verify a build.

Best practices

• Store EvidencePack IDs in your incident tracker so you can pull them instantly during audits.
• For long-term storage, archive the JSON files in your own SIEM or object storage.
• Use the persona explanations to tailor communications to different stakeholders (exec summaries vs technical detail).

Automating exports

• Use the REST endpoints (or the support-provided export tooling) to bulk export packs for compliance reporting.
• You can also stream transparency log entries via API to feed a SIEM and prove tamper-evidence.

Workspace auditor verify API

Workspaces can independently verify a pack against the transparency log:

• POST /trust/auditor/verify
• UI: #/trust-verify (Evidence Verifier)
• Body supports:
  • transparency_index (recommended), or
  • pack_hash, and optionally
  • pack (to run structure/signature checks inline).

The endpoint is workspace-scoped: it only returns entries that belong to your workspace.

In the UI (#/trust-verify), the verifier now auto-loads your recent entries and auto-verifies the latest one (zero-touch default). You can also click Load my recent entries and select an item to auto-fill values, or use Verify latest entry. Manual fields are hidden behind Show manual inputs (advanced) to avoid confusion between report hashes and transparency pack hashes. The route now opens on Overview first, then separates work into Verify, Proofs, and ML posture.

Threshold proofs

Workspaces can generate and verify threshold proofs to show a score exceeded a policy threshold without sharing raw feature payloads.

• UI: #/trust-verify -> Threshold proof verifier
• APIs:
  • POST /trust/auditor/zk/threshold/prove
  • POST /trust/auditor/zk/threshold/verify

Example: generate proof

curl -X POST "$BASE_URL/trust/auditor/zk/threshold/prove" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-API-KEY: $DRALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"score": 82.4, "threshold": 70, "context": {"surface": "web2"}}'

Example: verify proof

curl -X POST "$BASE_URL/trust/auditor/zk/threshold/verify" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-API-KEY: $DRALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"proof": { ... }}'

Notes:

• Workspace scope is enforced during verification (proof.context.tenant_id must match caller workspace).
• Current scheme is sha256-range-v1; future versions can introduce stronger cryptographic constructions while preserving verifier API shape.
• Proofs now include schema_version=1.0.0; verifier rejects unknown fields for strict validation.
• Proofs include nonce + timestamp; auditor verification rejects stale/future timestamps and reused nonces for your workspace.

Compliance proofs

You can prove policy compliance outcomes without sharing raw message/content payloads.

• UI: #/trust-verify -> Compliance proof verifier
• APIs:
  • POST /trust/auditor/zk/compliance/prove
  • POST /trust/auditor/zk/compliance/verify

Example: generate compliance proof

curl -X POST "$BASE_URL/trust/auditor/zk/compliance/prove" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-API-KEY: $DRALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": "swg-policy-v1",
    "minimum_pass_ratio": 1.0,
    "controls": [
      {"control_id": "swg.block_malware", "enforced": true, "evidence_digest": "sha256:1111111111111111111111111111111111111111111111111111111111111111"},
      {"control_id": "swg.block_phishing", "enforced": true, "evidence_digest": "sha256:2222222222222222222222222222222222222222222222222222222222222222"}
    ],
    "context": {"surface": "swg"}
  }'

Example: verify compliance proof

curl -X POST "$BASE_URL/trust/auditor/zk/compliance/verify" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-API-KEY: $DRALVIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"proof": { ... }}'

Notes:

• Use digest-only evidence (sha256:<64hex>), not raw content, to keep proofs privacy-preserving.
• Workspace scope is enforced during verification (proof.context.tenant_id must match your workspace).
• Response includes no_content_exposed=true when verification succeeds.
• Proofs include schema_version=1.0.0; verifier rejects unknown fields.
• Proofs include nonce + timestamp; verifier enforces freshness and rejects replayed nonce values for your workspace.

Federated learning privacy summary

Workspaces can inspect differential-privacy and drift signals used by the federated learning pipeline:

• UI: #/trust-verify -> Federated learning (DP) summary
• API: GET /portal/ml/federated/summary?window_days=30

The summary includes:

• epsilon_used, epsilon_cap, privacy_budget_within_bounds
• window_accuracy, historical_accuracy, accuracy_drift_pp
• accuracy_within_2pp
• acceptance.ready_for_rollout

This is read-only telemetry so your team can validate budget and quality envelopes without manual exports.

Scan benchmark

The scan benchmark is an on-demand snapshot of how your workspace scanning performs over a chosen window. It is computed live the moment you run it, against your own scan history, so the numbers are always current and specific to your workspace.

What it answers:

• How many scans ran in the window.
• How fast they were (average, median, and 90th percentile scan time).
• How many distinct threat signals the engine raised, and the average per scan.
• Risk mix (how many landed as avoid, caution, or clear).
• Accuracy, when you have reviewed tickets: how often the scanner verdict matched your analysts' final safe or malicious decisions.

How to use it:

• UI: open #/trust-verify, set the window (days), and press Run benchmark. Results appear as labelled tiles.
• API: GET /portal/ml/scan-benchmark?window_days=30.

Key fields:

• volume.total_scans, volume.risk_avoid, volume.risk_caution, volume.risk_clear, volume.avg_risk_score
• speed.avg_scan_seconds, speed.median_scan_seconds, speed.p90_scan_seconds
• signals.distinct_signals, signals.avg_signals_per_scan
• accuracy.labelled_total, accuracy.accuracy, accuracy.precision, accuracy.recall (populated only once tickets are reviewed)
• analytics_available (false when live analytics are temporarily unavailable)

Notes and limits:

• The window is capped at 180 days, matching how long detailed scan history is retained.
• Accuracy needs ground truth. Until your team resolves tickets as safe or malicious, accuracy.labelled_total is 0 and accuracy reads as not available rather than a guessed number.
• Results are cached for a couple of minutes per window, so a repeated run returns instantly.
• This view is read-only for workspace users.

Adversarial robustness summary

Workspaces can review adversarial-pressure and recall-gate telemetry without manual exports:

• UI: #/trust-verify -> Adversarial robustness summary
• API: GET /portal/ml/adversarial/summary?window_days=30

The payload includes:

• tenant_operational.mutation_signal_rate (how often obfuscation/mutation-like signals appear)
• tenant_operational.model_alignment (TP/FP/FN-based alignment ratios)
• regression_gate.surfaces.*.recall_drop_pp with within_gate per surface
• acceptance flags:
  • acceptance.repeatable_evals
  • acceptance.measured_robustness_improvements

Use this as your adversarial robustness health check before and after major model/policy changes.

Repeatable adversarial evals

Workspaces can also request a repeatable regression snapshot that compares current detection recall against historical baselines.

• API: GET /portal/ml/adversarial/evals?window_days=30

Key fields:

• overall.repeatable_eval_ready
• overall.regressed_surfaces
• overall.failing_gate_surfaces
• surfaces[*].trend (improved, stable, regressed, no_baseline)
• surfaces[*].delta_mutated_recall_pp

Recommended usage:

1. Run before enabling major policy/model changes.
2. Run after rollout and compare trend/gate fields.
3. Escalate if any surface reports trend=regressed or within_gate=false.

Adversarial rollout gate

Workspaces can view the current rollout gate verdict used by internal release controls:

• UI: #/trust-verify -> Adversarial rollout gate
• API: GET /portal/ml/adversarial/rollout/gate?window_days=30

Key fields:

• allowed / blocked
• reasons[] (explicit block causes)
• overall.failing_gate_surfaces
• overall.regressed_surfaces

This endpoint is read-only for workspaces; override approvals require authorized Dralvia support.

Treat EvidencePacks as the source of truth in disputes. They are signed, time-stamped, and anchored in the transparency log.

Fabric ingestion & retention

• Every EvidencePack generated through Evidence Reports or /reports/generate is retained durably. Copies live in your workspace storage under the evidencepacks/ prefix with the pack hash recorded for later audits.
• The ingestion SLO is p95 < 500 ms with a failure rate below 5 %. Ops teams monitor /fabric/ingest/health and the HUD workspace #/fabric-ingest to spot drifts or retry failed uploads.
• If you need to rehydrate an EvidencePack quickly, open #/fabric-ingest, pick the ingest ID, and click Download pack. The panel also shows the storage location so you can pull the canonical copy straight from your object store.

Reporting node exports

• Dralvia can automatically drop packs onto your on-prem share via the reporting node. Operators trigger exports from #/fabric-reporting, which copies the signed JSON into <tenant-local-root>/reporting/ (or the path you provide).
• Ask Dralvia support to enable forwarding for your workspace so compliance teams can collect packs directly from your filesystem without calling the API.

Who this is for

This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day-to-day execution.

Role-based start here

• Workspace Owner: Start with Before you start, then complete Step-by-step and Known limits and rate limits.
• Workspace Admin: Focus on Step-by-step, What each button does, and API and automation.
• Security Analyst: Start at Day-2 operations and Troubleshooting, then use API error quick reference.
• Integrator/Engineer: Start at API and automation, then validate with Step-by-step and FAQ.

Before you start

Use this short checklist before making changes:

1. Confirm you are signed into the correct workspace account.
2. Confirm your role includes the permissions needed for this page.
3. Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
4. Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.

Step-by-step

Follow this sequence for predictable results:

1. Open the workspace from the workspace menu.
2. Review current status/health/last update indicators before making changes.
3. Apply one change at a time and save.
4. Run the available validate/probe/refresh action.
5. Confirm the expected output appears (status change, new event, successful result).
6. If behavior is not as expected, use Troubleshooting below before repeating actions.

Day-2 operations

After initial setup, keep this surface healthy with a simple routine:

1. Daily: verify data freshness and error banners.
2. Weekly: review trends, limits, and failed actions.
3. Monthly: review permissions, keys/tokens, and stale entities.
4. After any incident: capture evidence and update your internal operating notes.

What each button does

Button labels can vary by module, but behavior is consistent:

• Refresh: reloads the latest data from backend APIs without changing configuration.
• Save: persists workspace-scoped configuration changes.
• Run/Probe/Validate: executes a non-destructive health or verification action.
• Download: fetches workspace-scoped artifact(s) (for example bundle, checksum, signature, or report).
• Verify: checks integrity/consistency and returns pass/fail details.
• Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.

If a button appears disabled, check role permissions, required fields, and workspace license/feature entitlement first.

Self-check playbook

Use this 5-step isolation flow before escalating:

1. Configuration: confirm required inputs are present and formatted correctly.
2. Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
3. License/feature: confirm the feature is enabled for your workspace plan and module toggles.
4. Quota/rate limit: check for 429 responses and cooldown windows.
5. Service health: if you see 5xx, retry once after 30-60 seconds and capture exact error text.

If still failing, escalate with workspace ID, UTC timestamp, route, action, payload shape (no secrets), and screenshot/error response.

Troubleshooting

Use this quick triage order to reduce time-to-fix:

1. Auth/session: refresh token by signing out/in.
2. Workspace context: confirm you are in the correct workspace.
3. Inputs/config: verify required fields and formats.
4. Quota/license: confirm limits and feature entitlement.
5. Service health: retry after short delay if backend is transiently degraded.

For escalation, include workspace ID, timestamp (UTC), route name, action attempted, and full error message.

API and automation

Everything in this page should remain workspace-scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:

• Use authenticated requests bound to your workspace context.
• Use idempotency/retry controls where available.
• Validate outcomes in the UI after automated runs.

If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.

GUI -> API quick map

GUI action	API endpoint	Expected outcome
Load transparency feed	GET /api/transparency-log?limit=100	Returns workspace-scoped transparency entries.
Load inclusion proof	GET /api/transparency-log/proof/{index}	Returns proof path and verification result.
Load consistency proof	GET /api/transparency-log/consistency?old_size={N}	Proves the current log still extends the log at N entries.
Verify pack hash/index	POST /api/trust/auditor/verify	Returns verification verdict with details.
Run threshold ZK proof	POST /api/trust/auditor/zk/threshold/prove	Returns generated proof + public inputs.
Verify threshold ZK proof	POST /api/trust/auditor/zk/threshold/verify	Returns cryptographic verification verdict.

Copy-paste curl examples

BASE_URL="https://dralvia.tech"
API_KEY="YOUR_TENANT_API_KEY"

curl -sS "$BASE_URL/api/transparency-log?limit=20" \
  -H "X-API-Key: $API_KEY"

# Prove the log still contains everything it had at 754 entries.
curl -sS "$BASE_URL/api/transparency-log/consistency?old_size=754" \
  -H "X-API-Key: $API_KEY"

curl -sS -X POST "$BASE_URL/api/trust/auditor/verify" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $API_KEY" \
  -d '{"pack_hash":"REPLACE_WITH_PACK_HASH","transparency_index":1234}'

Postman collection notes

• Keep pack_hash and transparency_index as collection variables.
• Save one folder for verification and one for ZK proof flows.
• Validate verified=true before exporting evidence externally.

Idempotency and retry guidance

• Verification endpoints are read/compute operations and can be retried safely.
• Treat proof-generation endpoints as expensive operations: retry with backoff, not tight loops.
• Always re-run verify after any failed/timeout proof generation attempt.

Next best actions

After finishing this page, continue with related workflows so your workspace setup stays end-to-end complete:

• EDR response and host actions
• Web Access Protection and dry-run events
• Identity risk and OAuth response
• Risk economics and plan recommendation
• Autonomous readiness and probes

FAQ

Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.

Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key/session is valid and mapped to the correct workspace scope.

Q: Can non-admin users use this page? A: Usually read-only access is possible; write actions require workspace-admin or equivalent roles.

Next steps

After finishing this guide:

1. Validate the result in the related dashboard/workspace.
2. Export or capture evidence if this affects compliance/incident operations.
3. Share the same runbook internally so other operators follow identical steps.
4. Return to Help Center for adjacent workflows.

API error quick reference

Use this matrix when a UI action fails with an HTTP/API error.

Error	Meaning	What to do now
401 Unauthorized	Session token is missing/expired or request is not authenticated.	Sign out/in, refresh once, then retry. Confirm your session is active in the correct workspace.
403 Forbidden	You are authenticated but your role is not allowed to perform this action.	Confirm your role includes the required permission for this button/action. Ask workspace admin to grant access.
404 Not Found	The route/resource does not exist in current workspace context (or feature not enabled).	Confirm URL/route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support.
429 Too Many Requests	Rate limit/quota window was exceeded.	Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server Error	Backend failed unexpectedly while processing the request.	Retry after 30-60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text.

Known limits and rate limits

These limits can vary by plan and feature, but behavior is consistent:

• Burst traffic can trigger 429 Too Many Requests.
• Workspace quotas apply per feature/module and reset on configured windows.
• Repeated retries without backoff can extend recovery time during saturation.

Recommended operator behavior:

1. Retry once after cooldown for 429 responses.
2. Use exponential backoff in automation.
3. Monitor usage/quota dashboards for sustained high utilization.
4. Request quota review when normal workload regularly approaches limits.