Passdown is built to keep the smallest security footprint the automated shift-handoff feature can actually work with. This page explains how Passdown authenticates, what it accesses, and — plainly, because it's a real and visible difference from Isogun Labs' other apps — why it does not currently qualify for Atlassian's "Runs on Atlassian" badge. See also the Privacy Policy for what data is read and why.
Runs on Atlassian eligibility
Passdown does not currently qualify for the "Runs on Atlassian" badge.
Every other Isogun Labs app can make that claim; Passdown cannot, and we'd rather say so
plainly than let it go unstated. The reason is specific: reading Jira Service
Management's on-call schedule from an app's own system identity (Forge's asApp())
fails on the relevant JSM Ops API, a confirmed platform limitation, not a bug in
Passdown's code — JSM Ops API permissions are strictly user-oriented, and Forge apps have
no supported workaround other than acting on behalf of a specific user. The only working
path is a small hosted component (a Cloudflare Worker) that exchanges Passdown's system
token for a token impersonating one designated user, then reads the schedule directly.
That hosted component and the token exchange it performs are real, disclosed external
egress, which is what removes "Runs on Atlassian" eligibility for the base install — not
just for an optional add-on. This is separate from Forge's 0% revenue-share
qualification, which is unaffected.
Authentication & authorization
Passdown authenticates entirely through Atlassian Forge using OAuth 2.0 — there is no
separate login, password, or API key for Passdown itself. Ticket reads and writes run as
the requesting user (asUser) wherever a user is in session, such as the
on-demand summary panel. The scheduled shift-boundary check has no user in session, so it
runs as the app (asApp), and the one call this cannot cover — reading the
on-call schedule — is handled by the hosted component described above, which
impersonates one designated user via Forge's own offline-user-authorization mechanism
rather than holding a standing broad credential.
Scopes requested
read:jira-work— read ticket content needed to generate a summary.write:jira-work— post the handoff comment and reassign the ticket.read:ops-config:jira-service-management(with impersonation allowed for the shift-boundary check only) — read who is currently on-call.storage:app— the one bounded record per on-call schedule described below.
Data flow
On-demand summaries: a Forge resolver reads a ticket's content as the requesting user, generates the summary text via Atlassian's own Forge LLMs API, and returns it to the panel. Nothing is written to storage in this path. Automated handoffs: a scheduled trigger calls the hosted Cloudflare Worker to check on-call state for each schedule; when it detects a change, it queries the outgoing person's open tickets (as the app), generates each summary the same way as the on-demand path, posts the comment, mentions the incoming person, and reassigns the ticket. The hosted component only ever sees on-call participant identifiers — never ticket content or generated summary text.
Hosting & subprocessors
All ticket-facing logic and AI generation run on Atlassian Forge. The one subprocessor is Cloudflare (Workers), operated by Isogun Labs, used solely to relay the on-call-schedule read described above. It receives a short-lived, audience-scoped token minted for that single purpose and validates every request against Atlassian's own JWKS before acting on it.
Data storage & encryption
Passdown's only persisted data is one Forge KVS (storage:app) record per
on-call schedule, holding the current on-call participant identifier. It is overwritten
on every check and never grows into a history. No ticket content, comments, or generated
summary text are ever stored. All requests, including the hosted-component call, use
TLS-encrypted channels in transit.
Logging
Passdown logs operational facts only — for example, that a shift boundary was detected on a given schedule, or that a ticket's handoff failed and was skipped. Logs never contain full ticket content, comment text, or generated summaries, and never contain credentials.
Vulnerability & dependency management
Passdown pins Atlassian Forge SDK dependencies — two packages use pre-release versions where the stable release does not yet support required UI Kit features — and keeps the Cloudflare Worker's dependency surface minimal (token validation and a single outbound API call). Updates are reviewed and redeployed through the Forge CLI and Wrangler respectively.
Access control
Passdown is built and operated by a single developer. Source and deployment access is limited to the developer's Atlassian developer account and Cloudflare account, both protected with two-factor authentication.
Reporting a security issue
If you believe you've found a security vulnerability in Passdown, please report it to support@isogunlabs.com. We aim to acknowledge reports promptly and will work with you on responsible disclosure.