Skip to content

Build1 publisher2 min readPublished

Sentinel Vault's no-key Confluence AI review rests on a four-line Forge manifest

Sentinel Vault calls Claude for Confluence content review through Atlassian's Forge LLMs API, declared in a four-line manifest with no remotes and no API key. Atlassian says those egress controls do not stop misuse of access granted at install.

The Engineer · Build desk

Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

Illustration accompanying Sentinel Vault's no-key Confluence AI review rests on a four-line Forge manifest
Generated illustration

What happened

  • The post's authors read the code at commit e649d9f on 1 October 2026 and ran Atlassian's eligibility check against production, but their one live AI review ran on a development build.
  • Atlassian made the Forge LLMs API generally available to all developers on 29 July 2026.
  • Sentinel Vault's Marketplace listing shows the Runs on Atlassian badge on version 6.5.0, published 30 September 2026.
  • The post's author says the app falls short of its marketing line in four places and that those matter more to an approving admin than its strengths.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • cost Running the model on Atlassian's side means the admin no longer has to clear a second AI vendor or assign someone to own an API key for this feature.
  • constraint Admins vetting apps in bulk cannot pull the badge from the Marketplace REST API and have to read each listing page's metadata by hand.
  • exposure The read access to Confluence and JSM Assets that an admin grants at install is still open to misuse, because Atlassian's egress controls are not built to stop that.
  • decision An admin approving the production build has to assume it behaves like the development build, because that is the only build a live AI review was run on.

Forge LLMs is what lets a model call stay inside the Runs on Atlassian badge. Atlassian's announcement says apps using it "can qualify for Runs on Atlassian because app data stays contained within Atlassian cloud the entire time" [10]. The API reference says the same thing from the developer's side: "The app retains its Runs on Atlassian eligibility after the module is added." [11]

Sentinel Vault's declaration in manifest.yml names one module, `sentinel-vault-llm`, and one model family, `claude` [13]. The authors grepped the manifest for a `remotes` section and for an external permissions block. Both searches came back empty [13].

I think the strongest part of the design is who decides the badge. "The Runs on Atlassian badge is automatically applied to eligible apps on the Atlassian Marketplace," Atlassian's program page says, and the post notes that Atlassian makes that call from the deployed app [6]. A vendor cannot add the badge by editing its own listing.

The pitch says no external data egress is declared [1]. The program rule allows more than that: "Your app must not egress data, with the exception of egress for analytics purposes." [5] The requirements leave analytics and logs to admin controls [4]. So an admin reading the pitch should still check those controls.

Atlassian's program page also says where its guarantee stops: "While controls that limit external data egress are in place, these controls do not prevent misuse of access granted to the app during installation or abuse of the app runtime." [8] The post's author wrote: "The badge tells you where the data can go. It doesn't tell you the app uses its permissions well." [17]

For Sentinel Vault, that granted access is four things. It has Confluence scopes, a content-styles entry, read-only JSM Assets scopes used to import classification levels, and app storage [14]. None of them is an external fetch permission [14].

Requests to the model also go through Atlassian's own filter. They get the same moderation checks as Atlassian's first-party AI and Rovo features, and the filter blocks messages the Acceptable Use Policy rates high-risk [12].

Forge's `forge eligibility` command tells a developer whether a deployed version qualifies. The authors ran it against both environments on 1 October [15]. The record ends at that command. Its output is not there, and neither are the cost-ceiling explanation and the four weak points the post promises [19].

On where the data goes, I'd accept a manifest with no remotes plus a badge that Atlassian assigns itself. On how the app uses its access, Atlassian's caveat leaves the review with the admin [8].

What to watch

  • The forge eligibility output for Sentinel Vault's production build, if the authors publish it.
  • Whether the four weak points involve the read-only JSM Assets scopes or the analytics exception to the no-egress rule.
  • Whether Atlassian adds a Runs on Atlassian field to the Marketplace public REST API.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories