Security overview
The trust boundary, permissions and safeguards behind Claervo's Jira configuration-limit controls.
Forge-only architecture
The application runs on Atlassian Forge with no external fetch permission, remote backend, external database, analytics endpoint or AI processor. Configuration metadata stays in Atlassian-hosted compute and storage; the app is eligible for Runs on Atlassian.
Least-privilege scopes
Scopes are limited to reading Jira work metadata, managing Jira configuration (fields, workflows, statuses, permission schemes), managing project releases and components, and storing tenant-local application state.
Safe write path
Every cleanup action is confirmed by an administrator, re-reads the target entity from Jira immediately before mutating and is skipped when the finding no longer applies. Each change is written to an audit trail. Removed permission grants are restorable with one click; trashed fields and archived releases are reversible in Jira; permanent deletions are labelled as such and require explicit confirmation.
Rate limits and budgets
Scans run in small, checkpointed batches with a per-batch request budget. Idempotent Jira requests retry with bounded exponential backoff and honour Retry-After on HTTP 429 and transient 5xx responses.
Data minimization
The app never reads work item content, comments or attachments and never stores user names or e-mail addresses. Atlassian error bodies are not stored or logged in production.
Responsible disclosure
Report suspected vulnerabilities privately to support@claervo.com with impact, safe reproduction steps and affected scope. Do not send live credentials or disclose the report publicly before coordination.