Where should AI tool access approvals and audit evidence live: JSM, IAM, or Security/GRC?

[Andrew]

Hi all,

I’m trying to understand how Atlassian/JSM teams are handling employee access to AI tools like ChatGPT, Claude, Copilot, Rovo, Perplexity, etc.

For organizations using Jira Service Management internally, where does this workflow usually belong?

- JSM request type + approvals
- JSM Assets/service catalog
- IAM/IGA / Okta / Entra
- Security/GRC
- Procurement/legal
- Some mix of the above

The specific lifecycle I’m curious about is:

1. employee requests access to an AI tool
2. someone approves or denies it
3. access has an expiry/recertification date
4. evidence is kept for audit/security review
5. access is actually removed or renewed later

For teams that have dealt with this: is native JSM usually enough, or does the workflow break down once expiry, recertification, evidence, and identity-provider access get involved?

I’m an Atlassian Marketplace developer, but I’m not looking to pitch anything here. I’m trying to understand the real operating pattern from Jira/JSM, IAM, and security teams.

[Jonas Nilsson _ Unitlane]

I would separate the system of action from the system of evidence.

For AI tool access, JSM can work well as the front door and review surface, while IAM/IGA remains the enforcement source for provisioning, deprovisioning, and recertification.

The part I would be careful not to lose is the evidence handoff between those systems:

- what was requested
- who approved it
- what evidence was available at review time
- what could not be verified from the collected sources
- whether the reviewer accepted any limitation before renewal/removal

That distinction matters because a closed JSM ticket can show that work happened, but not always what the review could actually prove later.

Disclosure: I work on Request Evidence Control for JSM, so I am close to this problem. The app is not an IAM/IGA replacement; it is for the JSM evidence-handoff layer when teams need source status, visible caveats, and an exportable review pack. Sharing only because it matches the evidence-retention part of the question:

https://marketplace.atlassian.com/apps/3851208244/request-evidence-control-for-jsm?hosting=cloud&tab=overview

[Dr Valeri Colon _Connect Centric_]

@Andrew welcome to the community! In my experience, this is usually a shared process rather than something owned entirely by JSM. JSM often serves as the front door for requests, approvals, and audit records, while IAM/IGA platforms handle provisioning, deprovisioning, recertification, and enforcement. Security, Legal, Procurement, and Data Governance may also be involved depending on the AI tool and data sensitivity.

For simple access requests, native JSM can be sufficient. Once you introduce expiration dates, periodic access reviews, proof of removal, segregation of duties, and compliance requirements, most organizations rely on integrations with Entra, Okta, SailPoint, or similar identity governance platforms rather than JSM alone.

[Andrew]

Thanks Jean, that’s helpful.

Quick follow-up: in your view, would native JSM still be enough once expiry, recertification, and proof of removal are required?

Or is that where IAM/security usually needs to own more of the workflow?

[Jean Horn]

Hello @Andrew ,

For this case, I see that the flow you presented is already within the scope of native JSM, as you mentioned.

Regarding access, I see that it can be implemented through automation flows with a trigger when the request is approved. Since some identity providers like Azure have integration with Jira Automation.

This would be my view based on your comment. I hope it helps you.

Best Regards,

Jean Horn