Developer
News and Updates
Get Support
Sign in
Get Support
Sign in
DOCUMENTATION
Cloud
Data Center
Resources
Sign in
Sign in
DOCUMENTATION
Cloud
Data Center
Resources
Sign in
Last updated Feb 19, 2026

Security requirements for Atlassian Government Cloud (AGC) apps

These security requirements will go live on March 31, 2026. Refer to the changelog for details.

These AGC specific requirements apply in addition to the Security requirements for cloud apps, and are not a replacement. Additionally, all requirements must be met during the app onboarding process.

For additional guidance on these requirements and security for Forge apps, see:

Atlassian Government Cloud (AGC) customers expect a very high level of trust and security. To meet this standard, we require all AGC-compatible app (including Connect-on-Forge apps) to adhere to the following set of trust and security requirements:

TYPE OF REQUIREMENTSECURITY REQUIREMENT
Authentication & Authorization
  1. Apps must use Forge's OAuth 2.0 for user authentication and authorization.
    • Unauthenticated access is not allowed on app resources, including web triggers and remote hosts, except for static content.
  2. When using asApp() or appSystemToken for authorization on any user-initiated action, apps must validate the user’s permissions.
  3. Apps must not collect, use, or store any Atlassian credentials that grant access to Atlassian accounts or resources, including (but not limited to):
    • API tokens
    • User or admin passwords
    • Org/Sys Admin API tokens
    • Access tokens (for example, Bitbucket Cloud access tokens)
    • OAuth credentials (client secrets)
Data Security
  1. Apps must ensure strict tenant isolation at runtime. Data or variables from one tenant must not be accessible to another tenant, including via runtime artifacts.
  2. Apps must not execute arbitrary code by spawning child processes or subprocesses. Any code execution must be securely sandboxed to prevent access to the runtime.
  3. Apps must not use wildcard (*) entries for egress domains in the external permissions of the Forge manifest.
    • All outbound (egress) domains must be explicitly listed to avoid unrestricted network access.
Application Security
  1. Apps should avoid using unsafe-inline or unsafe-eval in the script-src Content Security Policy (CSP) directive in the Forge manifest whenever possible, to reduce the risk of injection attacks.
Encryption
  1. All outbound connections (egress domains, remote hosts) must:
    • Use HTTPS only, and
    • Use TLS 1.2 or higher.
  2. Forge apps that send (egress) data must ensure that all data is encrypted at rest using strong encryption (for example, AES-256).
    • Storing sensitive data unencrypted is not allowed.
    • Key management and cryptographic controls that align with FedRAMP requirements are recommended.
  3. Apps must always use Forge encrypted storage for storing sensitive information such as:
    • Secrets
    • Personally Identifiable Information (PII)
Privacy
  1. Apps must follow the principle of least privilege when requesting scopes or API access. Only request the minimum permissions needed for the app’s functionality.
  2. Apps must clearly disclose data handling practices for any data that leaves (egresses from) the app, especially:
    • All third-party integrations, and
    • Data retention and deletion policies

    This information must be publicly available to customers via the Privacy & Security tab.

Supply Chain Security
  1. Apps must not use third-party dependencies or packages with known vulnerabilities, especially Critical or High severity vulnerabilities.

    Newly disclosed vulnerabilities with significant impact on security must be remediated as quickly as possible.

  2. Apps must not use:
Vulnerability Management
  1. Apps must undergo regular automated vulnerability scanning to identify security weaknesses in code and dependencies.

    At a minimum, scans must include:

    • Static Application Security Testing (SAST) for code, and
    • Software Composition Analysis (SCA) for third-party dependencies.
  2. You must identify at least one email as a security contact and have them create an account on ecosystem.atlassian.net so that they are notified about vulnerabilities in the app via Atlassian Marketplace Security (AMS) tickets. The Vulnerability review practices for Atlassian partners guide explains how to get access to AMS.

    Note: An admin can also be listed as a security contact.

Rate this page: