QuinTek

QuinTek

Native security apps for Atlassian Cloud.

We make security apps for Atlassian Cloud, built on Forge for the Atlassian Marketplace. Every one of them runs entirely inside Atlassian’s infrastructure, so your data never leaves Atlassian Cloud.

Runs on Atlassian

Your data never leaves Atlassian, and that’s by design.

Our apps carry Atlassian’s Runs on Atlassian badge because we built them to. Before the first feature, we decided that nothing we ship would ever hold a customer’s data: no vendor cloud, no outbound calls, no shared storage. The badge is Atlassian confirming that on architecture, not on a questionnaire.

Most Marketplace apps can’t say the same. They’re a web service wearing an Atlassian badge. Your content gets copied out to a vendor’s cloud, processed there, and stored there, which makes that vendor a subprocessor and a breach surface you inherit. Ours run inside Atlassian, so there’s nothing to inherit.

  • 01

    No vendor cloud

    Every line of app code executes on Atlassian-operated infrastructure.

  • 02

    No outbound calls

    No analytics SDK, no error reporting service, no telemetry leaving your tenant.

  • 03

    No shared storage

    Data is isolated per installation by construction, not by a filter in our code.

Jira Cloud · Access review & compliance

Every permission in Jira on any date.

Jira shows you who has access today. It can’t show you who had it last quarter, or why. Permission Audit keeps that record. Look up any user on any past date, see what changed since, and trace each permission back to the group, role, or scheme behind it.

  • Permission history for every user. Every scan is recorded, so you can look up what any user could do on any past date and see exactly what changed between two scans. Jira keeps no such record on its own.
  • The derivation chain, for every grant. Each permission shows the scheme, role, and group that produced it, and every route when there’s more than one. Revoking access means knowing exactly which group to remove someone from.
  • Every account, including the ones with nothing. The scan starts from the user directory, not from grants, so an account with zero access is reported as zero access. That’s how you confirm an offboarding worked.
  • People and apps, reported separately. Installed apps that can act on your site get their own review and their own findings. Most access reviews never look at them.
See the full app
Permission Audit’s Overview tab in Jira, showing five accounts scanned, four holding sensitive permissions, one deactivated account that still has access, and no unreachable projects.
The Overview tab: provenance line, the at-a-glance row, and the findings — accounts with sensitive permissions, deactivated people who still have access, and widest access.

The catalogue

Apps we ship

One app today, more in build. Each one solves a question an Atlassian admin is already answering by hand.

How we build

How every QuinTek app is built.

Nothing leaves Atlassian

Our apps are pure Forge. The code runs on Atlassian’s infrastructure, the data stays in Atlassian’s storage, and there is no QuinTek server in the path — because we do not operate one.

Least privilege, explained

Each app asks for the scopes its job needs and nothing more. If a scope shows up on the consent screen, the docs say exactly why it’s there and what it’s used for.

No API tokens, ever

We will never ask an administrator to paste a personal access token. Atlassian’s Marketplace Security Enforcement Policy prohibits it, and any vendor asking should be declined.

Isolated per install

Your data sits in storage Atlassian partitions per installation, by construction. There’s no shared database, no tenant filter in our code, and no way for one customer’s site to see another’s.

Evaluating us for a security review?

Start with the security page — it describes what our apps can reach, what they store, and where, in the detail a vendor questionnaire asks for.