Claervo Limits Guard for Jira

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.

Authorization

Every resolver call checks an active Marketplace license and that the calling user holds Jira administrator permission. Payloads, identifiers and dynamic Jira paths are validated server-side.

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.