Atlassian's documentation says Forge apps run in an isolated runtime, cannot call the internet except through egress domains declared in the manifest, cannot read users' login credentials or sessions, and cannot gain new scopes or egress domains in an update without site admin reapproval. That is a stronger default than a plain plugin, but it still needs a review.
What Forge is, in one paragraph
Forge is Atlassian's hosted app platform. Atlassian's security page describes a shared responsibility model: Atlassian runs the platform and enforces what apps can and cannot do, and the app developer is responsible for the rest. The page describes the function runtime as running apps in AWS as Lambda functions, with per-app isolation, an outbound proxy for external requests, and separate AWS accounts from other Atlassian services.
What the documentation says apps cannot do
| Limit | What it means for you |
|---|---|
| Cannot increase scopes, permissions or egress domains in a new version without site admin reapproval | A quiet update cannot widen access on its own |
| Cannot make internet requests beyond manifest egress permissions | You can read the declared domains to see where data may go |
| Cannot interfere with or modify other running apps | One app does not reach into another |
| Cannot access users' Atlassian login credentials or sessions | Passwords and session tokens are out of reach |
| Cannot call Atlassian APIs without granted scopes | Scopes define the data boundary |
| Cannot change identity properties such as user permissions or passwords | Privilege escalation through the app is blocked at the platform level |
The same page says an app may impersonate a user within its declared scopes while that user is active. Some scopes covering personal data require the user to grant permission first. Apps can also be set to use offline impersonation for a subset of scopes, with restrictions.
What apps can still do
Apps can run on a schedule or in response to product events, can be invoked by a web trigger, and can read and write user generated content depending on the scopes granted. That means a scope such as reading page content really does give the app your page content.
How to use this in a review
- Read the scopes. Compare them with the app's stated purpose. Anything broader needs a reason.
- Read the egress list. Each declared domain is a place data can go. Check each belongs to the vendor or a named subprocessor.
- Ask about the vendor's own backend. If the app sends data to a service the vendor runs, that service appears as an egress domain, and its security sits outside what the platform page describes. Ask how it is secured.
- Set a re-review rule. Because scope increases need admin reapproval, treat that prompt as a trigger for a fresh review, not a click through.
What the platform cannot tell you
A hosted runtime limits technical reach. It does not tell you whether the vendor is financially stable, how it handles data it copies out through approved egress, or whether its own employees can see your content. Those remain contractual and procedural questions. Our post on how to answer how you manage third-party integrations gives a structure for them.
Compare this with ecosystems that have little isolation, such as the ones in sandbox, permissions or review: three plugin protections compared.
Safeguard does not review Atlassian apps. For the software you ship, it offers dependency scanning, reachability analysis and policy gates, which pair well with a review habit like this one.
Quick check
Can a Forge app talk to any website?
No. The documentation says outbound requests go through a proxy that enforces egress controls from the app manifest, so only declared destinations are allowed.
Does a new version of a Forge app auto-gain more permissions?
No. According to the documentation, scopes, permissions and egress domains cannot be increased in a new version of an installed app without reapproval by the site admin.
Sources
Last reviewed: 19 October 2026.
