Security

Intake Standards for Jira Service Management is a Forge app by Sientus Solutions. Its code, its storage and the model it uses, Atlassian-hosted AI (Forge LLMs), all run on Atlassian. What is stored, where and for how long is on Your data.

In short:

• The app declares no egress, no remote backend and no external model key.
• Every settings request is checked with Jira for Administer Projects, as the person making it.
• A pass counts only when it matches a passed run in the app's own log.
• Log lines never carry the requester's text, and tests fail if they do.
• A model fault never blocks a requester; the request arrives labelled for review.

Built to run on Atlassian

Intake Standards is built to the rules of Atlassian's Runs on Atlassian programme:

• No egress. The manifest declares no external permissions, and the app calls nothing outside Atlassian.
• No external model keys. Forge LLMs is the only way the app reaches a model.
• No remote backends. Every function runs on Forge, and the app declares no web trigger. Data is kept in Forge hosted storage for your installation and on the work item.

What the app asks for

Beside the scopes, the manifest declares the Intake details field, the Intake standards page under Project settings, a trigger on work item creation and the llm module for Forge LLMs. A release that adds a scope waits until a site admin accepts it.

Who can do what

Project admins. The Intake standards page appears under Project settings only for people with Administer Projects on that project, but that only hides it. The control is on the server: every request the page makes is checked with Jira, as the person making it, for Administer Projects on that project, and refused without it or when the check itself fails. The page's address is no use without the permission. The project comes from the context Forge attaches to each request; a project id sent by the browser is ignored.

Requesters. The field declares unlicensedAccess for customer and unlicensed accounts, the Forge setting that opens a field to portal-only customers. Its calls run as the app, read the standard for the form's own project and work type and write at most one run log row per check. Project and work type come from the Forge context, not the browser. The settings functions are bound to the settings page alone, so the field cannot reach them.

The app. Every other Jira call runs as the app. The permission check is the one call made as the user, because a check made as the app would answer yes for everyone.

How the requester's text is handled

• The text reaches the model as data, wrapped apart from the instructions, with a rule never to follow instructions inside it. Typing the wrapper's marker does not end the data early.
• Met-when rules are written by project admins and treated as trusted configuration. Each is one line of 10 to 400 characters. None is sent to the requester's browser, which gets each check's label and hint, the word minimum, the skip rule and the box wording.
• The model answers through a fixed tool call: a verdict, an evidence quote and a hint for each check. The answer has no field for a label, so the model cannot rename a check, and a hint you wrote wins over the model's.
• The pass rule is code, not the model: a text passes only when every check is met.
• Log lines never carry the text: tests plant a marker phrase in the text and fail if it reaches a log line. Your data lists what log lines do carry and when we can read them.

Every pass is checked again

When a work item is created, the app accepts a pass in Intake details only when:

• the stored hash matches the text;
• the standard named in the value belongs to the work item's project and work type;
• the run log holds that run, passed, with the same hash and not claimed by another work item.

A pass written straight through the REST API, or cloned at creation from another work item, fails one of these. The work item then gets the label intake-unverified and an internal note naming the reason, without the requester's text. A Not checked value on a work type that has an enabled standard is flagged the same way. A request sent under a skip rule is labelled too; its note names the bypass only when the stored version carries a skip rule, and quotes the rule from storage, never from the browser.

Failing open

A model error, or a timeout on both attempts, never blocks a requester: the request is sent as Unverified, labelled and noted for reviewers. A form that cannot load its standard is treated the same way, and so is a check refused because the month's run budget is used up. A screen the app does not recognise is treated as one that blocks. Advisory mode, the incident switch for every installation at once, is set by us with a deploy. When the check cannot run covers both. A project admin can stop checking one work type without us and without a deploy; see Disabling a standard.

Questions security reviewers ask

Does requester text leave Atlassian?

No. The code runs on Forge, the model is Atlassian-hosted, the data stays in hosted storage and on the work item, and the app declares no egress.

Can Sientus Solutions read our requests?

The app gives us no way to. The text is kept in your installation's hosted storage and on your work items. The app has no web trigger or other way in from outside your site, and it sends nothing to us. What reaches us is the app's log lines, which carry ids, codes, timings and counts, never the text, and only while your site admin leaves app-log access enabled.

What personal data does the app keep?

The requester's text, up to 10,000 characters, and their Atlassian account id, in run log rows that expire after 30 days and are deleted within about 48 hours. The account ids of the admins who saved or enabled each version, kept until you uninstall and for 28 days after. Names are looked up when shown and never stored. The text in Intake details and Description follows your work item's own permissions and retention. The full list is on Your data.

Who processes the text?

Atlassian. The app's code, its storage and the model run on Atlassian's Forge platform, and the model is reached only through Forge LLMs. Sientus Solutions builds and supports the app and has no access to the text.

Who can change a standard or read the run log?

Only people with Administer Projects on that project. The server checks every settings request as the person making it.

Can a pass be forged?

A pass counts only when the hash, the project and work type, and a matching run log row agree. Any other pass is labelled intake-unverified and noted for reviewers.

Can the requester's text steer the model?

The text is given as data with a rule never to follow instructions inside it. The model returns only verdicts, quotes and hints; it cannot rename a check or change a rule, and code applies the pass rule. Every run, text and verdicts included, is in the run log for project admins to review.

What happens when the model is unavailable?

Nothing blocks. The request goes through as Unverified, labelled and noted, and reviewers find it with labels = intake-unverified.

A question this page does not answer goes to Support; a security report is acknowledged within 1 business day.