How JAMEs enforces security

Written by Ben Friedman, Atlassian expert & builder of JAMEs, the AI Jira administrator · Published 12 August 2026

Most security questions about AI tools get answered with a policy, “we promise to handle your data carefully”. A promise is not a mechanism. When a tool can write to your Jira configuration, you want cold hard constraints that hold regardless of anything.

JAMEs enforces security structurally, in four layers. Nothing runs without a plan you approved. Access is bounded by your own API token, so JAMEs cannot exceed the permissions you decided to give it. Delete tools do not exist in it at all. And the data it keeps is small: conversation history for 30 days, plus your automation rules and API key only if you choose, stored in the EU and never used for training.

Below we cover each layer, which AI models process your data, what stays auditable afterwards, and what happens to your data when you leave.

What enforces the approval gate?

The write path itself enforces it: every change JAMEs can make starts from a plan, and a plan only reaches execution after you accept it. There is no side channel where a quick edit skips review, because the plan is the only way anything gets written.

Rejection needs no justification. Turn a plan down and your configuration stays exactly as it was. The full loop, from request through planning to verified execution, is covered in how JAMEs works safely.

How is JAMEs’ access to your Jira bounded?

By the account you connect. JAMEs signs into the Jira REST API with that user’s API token and inherits every permission limit the account carries. If the account cannot administer a project, neither can JAMEs. There is no privileged access of its own, and no route into your site that Atlassian does not already offer to any integration.

That turns the connecting account into your main security control. Hand JAMEs a narrowly scoped account and the boundary is set before the first request; widen the account later if you want the tool to reach further. You are deciding the reach, in Jira’s own permission model, with the tools your admins already know.

Why can JAMEs never delete anything?

Because the capability does not exist in its toolset. JAMEs carries tools that create and update Jira objects; there is no delete tool for a plan to call, so no request, however it is phrased, can make anything disappear from your site. The worst case of a wrong change is a wrong value, and a wrong value can be corrected.

Deleting is sometimes the right admin move: retiring a field, clearing out a dead project. JAMEs will not do it. That cleanup stays manual work for a person with delete rights, and we would rather hand you that inconvenience than the risk.

What data does JAMEs keep, and where?

JAMEs keeps its data in the EU, and the inventory is short. Conversation history is stored for 30 days; Premium keeps it longer. Your automation rules are saved only if you choose to let JAMEs keep them. Your API key follows the same rule, with a stricter option: JAMEs can operate without saving the key at all, and when you do save it, it is encrypted at rest with AES-256-GCM, a current industry-standard cipher.

Two of the three items are yours to switch off, which is the pattern worth noticing: you decide most of what JAMEs is allowed to keep.

Which AI models process your data?

Anthropic’s. When JAMEs analyzes your site or plans a change, your Jira configuration and the structure of your automation rules pass through Anthropic models, which do the reasoning behind the plan. Jira’s actual ticket data is never accessible to JAMEs: as an AI admin agent, its tools are limited to configuration-related APIs only and include no ticket-related calls.

Two commitments govern that data. JAMEs never uses it for training. And Anthropic’s own commercial terms bar it from training models on customer content. Whoever you evaluate for this kind of work, ask them to name their model provider; it is the question that decides where your configuration actually travels.

What record does JAMEs leave behind?

A 30-day history of every event, there for you to audit. Whatever JAMEs planned and carried out on your site can be reviewed after the fact, which is the record a security review wants to see before granting a tool write access.

The Premium tier adds search over that history, across users and conversations, so a specific change can be traced back to the request behind it. On a site with several admins, that trace is usually the fastest answer to who changed this, and why.

How do you recover when a change goes wrong?

Two mechanisms, depending on what wrong means. A step that fails during execution leaves your site unchanged by that step, and JAMEs flags the failure clearly, so you know immediately whether to step in.

A change that succeeded but turned out to be a mistake is undone the way it was made: hand JAMEs the previous state, and it proposes the restoration for you to review and approve before it runs. Premium adds automated rollback where possible; rollback is never guaranteed, on any tier. And because delete tools do not exist, a wrong change is never lost data.

What happens when you offboard from JAMEs?

Your data is fully removed from JAMEs. Offboarding deletes the account and everything attached to it: the users you invited, your connection information, your conversation history, and any automation rules you chose to let JAMEs keep.

What offboarding cannot reach is your Jira. The work JAMEs carried out lives in your site, under your own account, and JAMEs has no delete tools to take any of it back. The inventory JAMEs kept empties; the configuration you built stays.

Frequently asked questions

If handing an AI write access to Jira is the step your security review will not clear, send the reviewer this page, and send us whatever questions remain: hello@viter.io. The beta is open, and JAMEs covers how to join.