1. Overview

‍

This Security Policy describes the security controls, practices, and responsibilities that AIVERY LABS PTY LTD (ABN 89 696 967 209 / ACN 696 967 209), a company incorporated in Western Australia, Australia (“we”, “us”, “our”, or “Aivery Labs”), applies to the following Atlassian Marketplace apps (together, the “Apps”):

• Support Intelligence — a Jira Cloud add-on that uses AI to analyse the summary, description, and reporter-authored comments of Jira tickets to surface escalation risk, churn signals, sentiment, and complaint categorisation.
• Org Intelligence — a Jira Cloud add-on that manages an internal org chart and routes approval workflows automatically based on that chart.

This policy is intended to inform Atlassian Marketplace reviewers, Jira site administrators, and end-user security teams of the measures in place to protect data processed by the Apps.

Both Apps are built end-to-end on the Atlassian Forge platform — a serverless, sandboxed execution environment managed by Atlassian. We do not operate any servers, databases, or infrastructure outside Atlassian's environment. Because the Apps run entirely on Forge, they inherit the platform's security model rather than implementing parallel security controls. This document describes both what the Apps inherit from Forge and the App-specific practices we apply on top.

‍

1.1 Scope

‍

This policy covers: the Apps' runtime code, the data each App processes, the Apps' interactions with Atlassian APIs and (where applicable) external AI providers, the Apps' use of Forge storage, the optional Rovo agent integration, and the Apps' published distribution on the Atlassian Marketplace. It does not cover the security of the underlying Atlassian Cloud platform, Jira Cloud itself, or your organisation's own Atlassian configuration — those are governed by Atlassian's own security programme and trust documentation.

‍

1.2 What this policy is not

‍

This is a working description of our security practices. It is not a contractual SLA, warranty, or substitute for the legal terms in the Atlassian Marketplace EULA or any separate agreement between us.

Where this policy applies to only one App, it is called out explicitly. Where no App is named, the provision applies to both.

‍

2. Data Classification

‍

The following tables describe the data each App processes, where it is stored, and whether it leaves Atlassian's infrastructure.

‍

2.1 Support Intelligence

‍

‍

‍

2.2 Org Intelligence

‍

‍

‍

‍

Org Intelligence does not send any data to services outside Atlassian. All data stays within the customer's Atlassian tenant.

‍

3. Platform Security (Atlassian Forge)

‍

Both Apps are built end-to-end on Atlassian Forge. The platform provides the following security guarantees, which the Apps inherit:

• Tenant isolation. Runtime, storage, and execution context are isolated per Atlassian Cloud tenant by Forge. App code cannot read or write data belonging to another customer. One installation cannot query or access another installation's data.
• Sandboxed execution. Each function invocation runs in an isolated, short-lived Node.js sandbox. Functions cannot access the host operating system, file system, or other tenants' data, and cannot communicate with each other outside defined interfaces.
• No persistent server. There are no long-running processes or open ports to compromise. The execution environment is ephemeral.
• Managed runtime and patching. Atlassian provisions, patches, and manages the Node.js runtime, OS images, container images, and kernel. We do not manage any of these.
• Managed authentication. All inbound and outbound API calls are authenticated by Forge using Atlassian-managed tokens. The Apps never see, store, or handle user passwords or Atlassian API tokens.
• Managed deployment pipeline. App distribution goes through Atlassian's review and signing process. End users install only signed, vetted bundles via the Atlassian Marketplace.
• Managed storage. Forge SQL (relational) and Forge KVS (key-value) are managed services provided by Atlassian. Data is tenant-isolated at the infrastructure level.
• Egress controls. Forge enforces that an App can only make outbound network requests to domains explicitly declared in its manifest under permissions.external.fetch.
• Atlassian-grade compliance posture. Forge inherits Atlassian's broader certifications and security programme (SOC 2, ISO 27001, penetration testing, vulnerability disclosure). Refer to the Atlassian Trust Center for the current scope and attestations. We do not claim any certifications of our own beyond what Forge provides.

‍

4. External Network Access

‍

4.1 Support Intelligence

‍

Support Intelligence makes outbound HTTPS requests only to the following explicitly declared endpoints (declared in manifest.yml under permissions.external.fetch):

‍

‍

‍

No other outbound connections are made. No data is sent to vendor-operated servers, analytics platforms, advertising networks, or any other third party.

‍

4.2 Org Intelligence

‍

Org Intelligence makes no outbound calls to non-Atlassian services. The App's manifest declares external.fetch.backend: [] — the Forge platform will refuse any attempt by the App to call a non-Atlassian host.

Outbound calls from Org Intelligence go only to Atlassian's own REST endpoints (the customer's Jira tenant REST API and the Atlassian Identity API).

‍

5. Authentication and Authorisation

‍

Neither App implements its own authentication. Every user accessing either App is already authenticated by Jira.

‍

5.1 Identity

‍

• Each App receives the calling user's accountId from Forge's resolver context.
• This identity is used to (a) record the actor in the audit log where applicable, and (b) check Jira permissions before authorising any administrative action.

‍

5.2 No custom credentials

‍

• Neither App issues its own session tokens, API keys, or credentials for end-user authentication.
• Neither App stores passwords, OAuth refresh tokens, or any user secret.
• Neither App supports a “service account” or impersonation mechanism. Every action is attributed to a real Jira user.

‍

5.3 License enforcement

‍

Each App checks its Atlassian Marketplace license as the first line of every resolver (before reading or writing any data). If the App's subscription is inactive, the operation is rejected with a clear error and no data is read or written. This is enforced at every UI resolver, Rovo action (Org Intelligence), and scheduled trigger.

‍

5.4 Authorisation model (Org Intelligence)

‍

Org Intelligence enforces three layered checks on every administrative operation, in this order:

• License check — as described in 5.3.
• Forge module-level enforcement — the admin page is declared as jira:adminPage and the project settings page as jira:projectSettingsPage. Forge itself prevents users without the appropriate Jira permission from rendering these surfaces.
• Resolver-level permission check — for operations that mutate state (rules, member changes), the resolver re-verifies the caller has either site-admin (Administer Jira) or project-admin (Administer Projects for the relevant project key) before performing the action.

‍

5.5 Authorisation model (Support Intelligence)

‍

Support Intelligence resolvers verify the Atlassian license status before returning any data, preventing access from unlicensed installations. The App's data access is additionally constrained by its declared Jira scopes (see Section 6).

‍

5.6 AI provider credentials (Support Intelligence)

‍

• The Anthropic and OpenAI API keys are stored as Forge environment variables (encrypted at rest by Atlassian) and are never exposed to the frontend, written to logs, or checked into source control.
• Key rotation can be performed at any time via forge variables set without redeployment.
• Org Intelligence stores no secrets at all — there are no API keys, signing keys, webhook secrets, or service-account credentials in the App's runtime or storage.

‍

6. Minimum-Privilege API Scopes

‍

Each App declares only the Atlassian OAuth scopes strictly required for its functionality. No administrative or configuration scopes are requested.

‍

6.1 Support Intelligence scopes

‍

‍

‍

Support Intelligence has no write access to Jira. It holds no write:jira-work or administrative scopes. It cannot create, modify, or delete Jira issues, comments, or projects. Reply suggestions are surfaced to agents through the Atlassian Rovo Agent add-on UI — the App itself never writes to Jira.

‍

6.2 Org Intelligence scopes

‍

‍

‍

‍

Org Intelligence does not request manage:jira-project, manage:jira-configuration, or any administrative scope. It cannot create projects, modify workflows, install other apps, or change Jira configuration.

‍

7. Data Protection

‍

7.1 In transit

‍

• All HTTP traffic is TLS-encrypted (TLS 1.2 or above), terminated by Atlassian's edge. The Apps do not open, terminate, or proxy raw connections.
• Data transmitted to Anthropic and OpenAI (Support Intelligence only) is also TLS-encrypted in transit.

‍

7.2 At rest

‍

• All App-managed data is persisted via Forge SQL and Forge KVS/Storage, which are managed services provided by Atlassian.
• Encryption at rest is provided and managed by Atlassian's storage layer. We do not manage encryption keys; we cannot disable encryption.

‍

7.3 Data minimisation (Support Intelligence)

‍

• Ticket text is not stored. The ticket summary, description, and reporter-authored comments are transmitted to AI providers transiently and are not retained by the App after analysis. Only AI-derived analytical outputs (risk scores, sentiment, churn signals, category) are persisted in Forge SQL.
• Deduplication hash. A SHA-256 hash of each processed text block is stored to prevent duplicate analysis of identical content. The hash is one-way and cannot be used to reconstruct the original text.
• Minimum identifiers. Only customer account ID and display name are stored as personal identifiers. Email addresses, phone numbers, and other contact details are not collected.
• KVS TTL. Panel cache entries have a 24-hour TTL and auto-expire via the Forge platform.

‍

7.4 Data minimisation (Org Intelligence)

‍

• No issue content. The App does not persist issue summaries, descriptions, comments, attachments, or any field value beyond what is needed at the moment of rule evaluation. Issue data is read live and discarded after the function returns.
• No additional PII beyond Jira. The display name, email, and accountId stored in the org chart are the same data already present in Jira's user directory.
• No credentials. The App stores zero secrets.

‍

7.5 Data retention

‍

• Analytical data (Support Intelligence) is retained for as long as the App remains installed.
• Org chart, rules, assignments, and audit entries (Org Intelligence) are retained until deleted through the App UI or until the App is uninstalled. Rule-engine audit events are auto-pruned to the most recent 1,000 entries to keep storage bounded.
• Upon uninstall, all data stored in Forge SQL and KVS/Storage is permanently deleted by the Atlassian platform within the Forge platform's standard deletion window (typically up to 30 days).

‍

8. Logging and Monitoring

‍

8.1 Audit log (Org Intelligence)

‍

Org Intelligence writes a structured audit log for every administrative and runtime event. Each entry contains: category, action, actor accountId, target reference, project key (if applicable), timestamp (UTC), and a small JSON detail blob. The audit log is viewable through the App's Audit Log page and exportable to CSV. Support Intelligence does not maintain a user-facing audit log; its equivalent is the analytical data itself and Forge platform logs.

‍

8.2 Operational logs

‍

• Both Apps emit structured log lines to Forge's standard output for diagnostic purposes. Logs include error and warning conditions, selected info events (e.g., queue entry, AI result summary, churn-risk changes), and HTTP status codes on failure.
• Operational logs are accessible only to Atlassian platform operators and to us (the App publisher) via the Forge developer console, and only when actively investigating a customer-reported issue.

‍

8.3 What we log carefully — and what we do not

‍

• We log issue keys, rule IDs, accountIds, and the type of action taken.
• We do not log ticket summaries, descriptions, comment text, attachments, or any free-text customer content.
• We do not log API tokens, session IDs, cookies, or any secret material — the Apps never see these in the first place.
• We do not log full HTTP request/response bodies. On error, we log the HTTP status code and a short summary.
• AI prompt logging (Support Intelligence): during development and in response to customer-reported AI-quality issues, the exact prompt sent to Anthropic and the raw model response may be recorded in Forge developer-console logs to assist debugging. These logs are accessed only by our engineers and only in the course of a reported issue.

8.4 No external monitoring

‍

Neither App sends telemetry, metrics, or error reports to any external monitoring service (no Sentry, Datadog, New Relic, Mixpanel, or similar). The only monitoring is what the Forge platform itself provides.

‍

9. Secure Development Practices

‍

• TypeScript with strict mode. Both Apps' backends are written in TypeScript with strict type checking enabled, reducing the risk of type-confusion and null-reference vulnerabilities.
• Parameterised SQL. All database queries use Forge SQL's prepared-statement API (bindParams()). String interpolation is never used in SQL queries, preventing SQL injection.
• No dynamic code execution. The Apps do not use eval(), Function(), or any dynamic code execution mechanism.
• Input validation. All resolver and action inputs are TypeScript-typed and validated at the boundary before processing.
• Dependency management. Dependencies are installed using npm ci (exact lockfile versions) for all builds. Frontend builds compile with TypeScript before bundling.
• Content Security Policy. Frontend resources are served by Atlassian Forge's CDN, which enforces CSP headers. The Apps do not override or weaken these headers.
• No sensitive data in frontend. React/Forge frontends communicate with the backend exclusively via Forge's invoke() bridge. No API keys, database queries, or internal logic are exposed to the browser.

‍

10. Error Handling

‍

The Apps handle errors with two principles: fail safely, and don't leak.

‍

10.1 Safe failure modes

‍

• Resolver errors are caught at the boundary and returned to the frontend as structured error objects. The frontend surfaces a user-friendly message; raw stack traces are never displayed.
• Rule-evaluation errors (Org Intelligence) are logged as audit events and the offending rule is skipped for that issue — one bad rule does not block the others.
• Audit-log writes are non-blocking. If the audit log fails for any reason, the user-facing operation still succeeds; the audit gap is acceptable in exchange for reliability.
• Malformed stored data (e.g. a corrupted approver chain JSON) is handled with safe parsing and fallback values, so a single bad row cannot crash rule loading for the entire tenant.

‍

10.2 No information leakage

‍

• Error messages describe what went wrong, not internal implementation details (no SQL, no file paths, no stack frames).
• Validation errors enumerate the fields at fault, not the underlying database constraints.
• Permission denials say “you need X permission” — not “internal authorisation check Y returned false at line Z.”

‍

11. Third-Party AI Provider Security (Support Intelligence)

‍

Support Intelligence relies on two third-party AI providers. Org Intelligence does not use any non-Atlassian AI provider — see Section 12 for the Rovo integration.

‍

11.1 Anthropic (Claude)

‍

• Data is transmitted over TLS 1.2 or above.
• Use of the Anthropic API is covered by Anthropic's Commercial Terms of Service and Data Processing Addendum.
• Under Anthropic's Commercial Terms, customer inputs and outputs submitted via the API are not used to train Anthropic's generally available models.
• Reference: anthropic.com/legal.

‍

11.2 OpenAI (GPT-4o mini)

‍

• Data is transmitted over TLS 1.2 or above.
• Use of the OpenAI API is covered by OpenAI's Business Terms and Data Processing Addendum.
• Under OpenAI's Business Terms, API inputs and outputs are not used to train OpenAI's generally available models by default (API customers are opted out of training by default; we have not opted in).
• Only short AI-generated text fragments (not the ticket summary, description, or reporter-authored comments) are sent to OpenAI.
• Reference: openai.com/policies/business-terms.

‍

12. Rovo Integration (Org Intelligence)

‍

Org Intelligence ships with a Rovo agent powered by Atlassian Intelligence. This is a first-party Atlassian capability — we do not integrate any external LLM provider for this App.

‍

12.1 What data flows to Rovo

‍

• The user's natural-language prompt (for example, “who is my manager?”).
• The conversation context maintained by Rovo itself.
• The structured response from the App's resolvers — typically a small JSON object containing the org chart entries or rule data needed to answer the question.

‍

12.2 What data does NOT flow to Rovo

‍

• We do not send issue summaries, descriptions, comments, or attachments to Rovo. The App's Rovo handlers return only org-chart and rule data.
• We do not send credentials, audit log entries, or other accounts' data unrelated to the question.
• We do not send any Rovo data to any non-Atlassian service.

‍

12.3 Authorisation for Rovo actions

‍

• Rule-management actions require the same admin permission checks as the regular UI.
• The license check runs first on every Rovo action; if the license is inactive, the action returns a clear error and performs no data operations.
• Read-only actions (get-manager, get-direct-reports, list-rules, explain-rule, etc.) inherit Jira's own user-data visibility.

‍

12.4 Safe defaults

‍

• Rovo never creates an active rule. Every rule created via the Rovo agent is created with active = false and must be enabled through the App's admin UI by a human admin.
• Rovo validates before creating — the agent checks JQL syntax, field existence, and project-key validity against your live Jira before invoking any create action.
• Rovo cannot exceed user permissions. The agent runs as the calling user and is subject to all the same authorisation checks as the regular UI.

‍

12.5 If Rovo is not enabled

‍

If your Atlassian Cloud subscription does not include Rovo, the agent is simply unavailable — no data is sent to Atlassian Intelligence in that case, and the App functions normally without it. Use of Rovo is governed by Atlassian's Atlassian Intelligence Trust documentation and the terms applicable to your Rovo subscription.

‍

13. Tenant Isolation

‍

• Each Jira site installation is fully isolated at the Forge SQL level — one tenant cannot query or access another tenant's data.
• The Forge platform enforces tenant isolation at the infrastructure level. The Apps do not implement any cross-tenant data access patterns.
• Internal queue items (Forge KVS) are scoped per installation and are not accessible across tenants.
• All Apps' data is scoped per installation. Forge guarantees that an App's data on one tenant cannot be read or written by the App on any other tenant.

‍

14. Vulnerability Management and Incident Response

‍

14.1 Reporting a vulnerability

‍

Please report security vulnerabilities privately — not through public GitHub issues, social media, or the Atlassian Marketplace reviews.

• Email: support@aiverylabs.com

Please include a description of the issue, reproduction steps, the affected App version (if known), and any proof-of-concept output. We commit not to pursue legal action against good-faith security researchers who follow responsible disclosure.

‍

14.2 Our response SLA

‍

• Acknowledgement — we will acknowledge receipt of the report within 2 business days.
• Triage — within 5 business days of acknowledgement, we will assess severity and confirm whether the issue is reproducible.
• Mitigation and disclosure — we will work to remediate and, where appropriate, coordinate disclosure with the reporter and affected customers.

‍

14.3 Patch process

‍

• Critical security patches are deployed as priority releases outside the normal release cadence.
• Non-critical security patches are included in the next scheduled release.
• All releases go through Atlassian's Marketplace review and signing pipeline before reaching customers.

‍

14.4 Customer notification of security incidents

‍

For incidents that affect customer data, we will notify affected customers without undue delay, and in any event within 72 hours of becoming aware of the breach, as aligned with GDPR Article 33 and the Australian Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth). Notifications are sent to the contact on file with Atlassian Marketplace and surfaced via the App's admin UI on next sign-in.

‍

14.5 Underlying platform incidents

‍

For incidents in the underlying Atlassian Cloud or Forge platform, refer to Atlassian's Statuspage and Atlassian's own incident-response procedures. We will coordinate with Atlassian as needed but cannot remediate platform-level incidents on Atlassian's behalf.

‍

14.6 No persistent attack surface

‍

Because both Apps run on Forge's serverless infrastructure with no persistent servers, open ports, or cross-tenant interfaces, the attack surface is limited to the Forge function invocation boundary, which is controlled by Atlassian.

‍

15. Shared Responsibility

‍

Security is a shared responsibility between Atlassian, us (the App publisher), and you (the customer). Each party owns a different part of the stack.

‍

‍

‍

‍

15.1 What you must do for the Apps to be secure

‍

• Manage Jira admin and project-admin grants carefully. Anyone with Administer Jira can read and modify the Apps' data. Anyone with Administer Projects for a specific project can manage App behaviour for that project.
• Keep your Jira user directory accurate. Org Intelligence relies on Jira's active/inactive flag for stale-approver detection. If deactivated employees are not deactivated in Jira, the App cannot detect them.
• Vet your CSV imports (Org Intelligence). The App stores what you import. If you import HR data that includes restricted-distribution information, that information lives in Forge storage until you delete it.
• Review the audit log periodically (Org Intelligence). The App provides the audit trail; reviewing it for anomalies is your responsibility.
• Understand what leaves Atlassian (Support Intelligence). If you install Support Intelligence, the ticket summary, description, and reporter-authored comments will be sent to Anthropic for analysis. Ensure this is acceptable under your own data-handling obligations.

‍

15.2 Limitations

‍

• The Apps can only enforce what Forge and Jira themselves allow them to enforce. If an underlying Atlassian platform vulnerability exists, the Apps cannot work around it.
• Forge SQL does not support multi-statement transactions (auto-commit only). Concurrent writes are guarded by dedup-before-insert at the repository level, which prevents duplicates but does not provide strict serialisable isolation.
• The Apps do not protect against insider threats from your own Jira admins — by design, an admin can read, modify, or delete the Apps' data.

‍

16. Compliance

‍

‍

‍

‍

We do not independently hold SOC 2, ISO 27001, or similar certifications. The Apps rely on Atlassian's Forge platform certifications for infrastructure-level controls and on this policy for App-level controls. Customers requiring additional contractual security commitments (for example, a signed Data Processing Addendum) may request them using the contact details in Section 18.

‍

17. Changes to This Policy

‍

This policy may evolve as the Apps' features change, as the Forge platform's capabilities change, or as new threats and best practices emerge.

• Material changes (e.g. a new external dependency, a change in stored data categories, a change in requested scopes) will be announced via the Apps' Atlassian Marketplace listings, a note on the Apps' documentation pages, and — for installed customers — a notification through the App admin UI on the next admin sign-in following the change.
• Non-material changes (clarifications, formatting, link updates) are reflected in the “Last Updated” date at the top of this document.

‍

18. Contact

‍

For security questions, vulnerability reports, or data processing enquiries:

• AIVERY LABS PTY LTD — ABN 89 696 967 209 / ACN 696 967 209, incorporated in Western Australia, Australia
• Email: support@aiverylabs.com
• Privacy questions: see the Aivery Labs Privacy Policy

This policy describes the Apps' security practices. It does not replace or modify Atlassian's own security commitments, which separately govern the underlying Jira Cloud and Forge platform. Where this policy and Atlassian's Trust Center descriptions disagree on platform-level controls, Atlassian's documentation is authoritative for the platform and this document is authoritative for the Apps.