Security
How Jev for Jira checks access, constrains model decisions, and handles uncertain writes. These are the current application controls and their practical limits.
Platform and credentials
Jev for Jira runs on Atlassian Forge with a native UI Kit interface and backend functions. We The Folks does not operate a separate application server for the app. Rules, activity, receipts, and recovery records are stored in Forge.
The publisher supplies the OpenRouter API key through an encrypted Forge environment variable. Backend code reads it; customer-facing resolvers do not return it or let users replace it. The app declares backend HTTPS egress to OpenRouter for model processing.
Jira authorization
Backend operations check authorization independently of visible controls. Project administrators can manage the projects they administer; Jira site administrators can manage any project and control installation-wide processing consent.
Interactive tests read Jira as the signed-in administrator. Background reads and permission checks use offline impersonation of the administrator who last saved the rule, preserving that person’s current Jira permissions and issue visibility.
Automatic edits and new project moves execute as the app account. Before each write, the backend rechecks the rule owner’s issue visibility and required permissions. The app also needs its own Jira access and does not fall back to user-attributed edits when app access fails.
Activity access checks project administration and current access to the referenced issue. Knowing an issue identifier alone does not grant access to its activity.
Limits on model authority
Administrators define the prompt, allowed outcomes, and actions. The model returns choices and probabilities, which the backend validates against the configured outcomes. It does not supply executable code, free-form Jira actions, field definitions, or project destinations.
Jira variables determine the issue data sent for classification. Variables used only in action templates are expanded locally. Expanded requests above the application’s 30,000-byte budget are rejected without truncation or Jira actions.
Issue content remains untrusted input. Limiting model output to configured choices constrains what it can cause, but it does not guarantee that a classification is correct or that hostile text cannot influence the selected outcome. Test previews a saved rule without applying its actions. Saving a rule enables automatic execution, so use a suitable test project when developing consequential automations.
Execution and recovery safeguards
The backend validates the complete action plan before starting edits. Durable execution receipts track action intent and status, help prevent duplicate execution, and support continuation of accepted Jira moves. Existing matching values produce a Skipped action without a write.
An unconfirmed Jira write is marked Needs review rather than automatically replayed. Inspect the issue and its history before deciding how to resolve it.
Recovery preserves captured automatic events for up to 14 days from their original queue time. Before resuming, it rereads current Jira values and checks consent, permissions, rule revision, enabled state, and the future-items cutoff. Changed or disabled rules do not resume under obsolete configuration.
Data minimization and erasure
Activity and receipts exclude full issue bodies, expanded action values, raw provider responses, and credentials. Errors are sanitized. Stored rule names, outcome labels, and templates can nevertheless contain personal information supplied by administrators.
Activity and receipts have a fixed deadline of at most 14 days from the original run creation time, with the earlier original queue deadline applied to recovered events. Progress updates and retries do not extend retention. Physical storage cleanup is asynchronous.
A privacy job reports stored administrator account references to Atlassian and removes references marked closed or updated. Hashed erasure markers prevent stale workers from restoring them. These pseudonymous markers currently have no automatic expiry; the process does not automatically discover personal details in arbitrary free text.
Current boundaries
Configured classification data leaves Atlassian for OpenRouter and TypeSafe. The application does not enforce zero data retention, no-training guarantees, or a fixed provider processing region. Review this processing before granting site consent.
Consent is checked before a new action batch; withdrawing it is not an immediate stop for every edit already in progress. A transmitted model request or accepted Jira move cannot be recalled, and an already-started batch can finish further edits.
Recovery depends on an event having reached and been captured by the app, and on it remaining within the retention window. It does not reconstruct events never delivered to the app.
This page describes application controls. It is not a certification, independent audit report, or guarantee that every security risk is eliminated.
Report a security concern
Contact We The Folks with “Jev for Jira security” in the subject. Start with the affected feature, a concise description, safe reproduction steps, and the likely impact. Omit API keys, session tokens, passwords, and customer issue content.
If a reproduction needs sensitive material, first ask us to agree an appropriate way to share it. This page does not promise a response time or continuous monitoring.
Contact
Contact We The Folks at [email protected].
Please start with a safe summary and agree a sharing method before sending sensitive material.