Testing an AI assistant inside a Jira app

Imagine an assistant that summarises a Jira project and offers to create follow-up tasks. In a demo, it reads the issues, writes a helpful summary, and creates a task when asked. Everything appears to work.

Now give the same assistant to someone who can see only part of that project. Which issues enter the summary? Does the assistant’s cached answer contain information the person cannot read? If it creates a task, whose permissions does it use?

These questions are worth answering before spending the whole test session on hostile prompts.

Trace one summary request

Start at retrieval. Identify the user asking the question and the identity used to fetch issues or documents. Atlassian’s cloud app security requirements apply to the app’s authentication and authorisation decisions; adding a model doesn’t move those decisions into the prompt.

Check the retrieved records before they reach the model. If a restricted issue is included, telling the assistant not to disclose confidential information leaves the access-control problem in place.

Then follow the answer into caches, logs, exports, and conversation history. A permission check at retrieval time won’t necessarily protect a summary that is later served from a shared cache.

Set up a test you can observe

Use synthetic issues and documents in an authorised test environment. Create two roles with different access and, where the app supports it, two separate tenant installations. Put a distinctive, harmless marker in each restricted record.

Ask for a summary as the less-privileged user. Inspect the retrieval results, the material sent to the model, the generated answer, and any stored copy. The marker helps establish whether restricted content travelled further than it should have.

Next, remove a permission and repeat the request. Check the existing conversation as well as a fresh one. Cached summaries and older retrieval indexes deserve attention because they can preserve access after the underlying permission has changed.

Separate reading from acting

An assistant that proposes a task has different privileges from one that creates it. Decide which behaviour the product needs and expose only the corresponding tool operations.

The tool handler should check the target resource, the caller’s permission, and the submitted arguments. A prompt instruction such as “only change issues the user can edit” is not an authorisation check.

For a consequential action, show the user the proposed target and content before confirmation. If the assistant changes either after approval, that approval no longer describes the action being taken. This is especially relevant when a conversation moves between several projects or issues.

Then test untrusted content

The OWASP Top 10 for LLM applications includes prompt injection, sensitive information disclosure, improper output handling, and excessive agency. Those categories point to different parts of this example.

Place a benign instruction in a test issue description and check whether it redirects the assistant away from the user’s task. Watch the tool calls and resulting changes, not only the chat reply. An assistant could refuse an instruction in its response after a tool has already acted on it.

Also inspect how generated content is rendered. Model output that becomes HTML, a link, or a tool argument needs handling appropriate to that destination. Test failures and repeated calls with bounded budgets so the test itself doesn’t create uncontrolled processing.

Keep the failure as a regression case

For each issue, save the permission state, the relevant synthetic input, the requested action, and the observed result. Repeat the case after changes to retrieval, tool permissions, prompts, or the model. For variable behaviour, record how many attempts were made rather than describing one successful run as a general guarantee.

The OWASP testing guidance is useful when planning this wider assessment. The aim is to understand what the whole application can disclose or change, including the ordinary access-control defects an impressive AI demo can make easy to overlook.

References

• Atlassian cloud app security requirements
• OWASP Top 10 for LLM applications
• OWASP AI/LLM testing guidance

Reviewed 10 November 2026. The assistant is a worked example.