ArdSaor

AI Clearance for Jira Service Management

Audit-ready evidence for AI tool access decisions

AI Clearance turns JSM approvals into a defensible lifecycle record: who requested access to which AI tool, who approved it and under what policy, when it expires, when it was recertified, whether Okta or Microsoft Entra group membership still matches the approval, and whether the Governance Logs export can be checked for continuity.

Last updated: 2026-06-18

Install from Atlassian Marketplace See a sample evidence pack

Marketplace handles install, trial, billing, and current terms. Bring one workflow for a teardown if you want design-partner help.

The post-approval problem

Approvals are the easy part. Jira Service Management can route a request, notify approvers, and record a decision. That is table stakes for AI tool access.

The harder question arrives later: who still has access, was continued need recertified, did the grant expire, and does the identity-provider group still match the approval record?

Security and GRC teams feel that pressure during audits, vendor reviews, and AI governance reviews. The European Commission public timeline says the AI Act became broadly applicable on 2 August 2026 with exceptions, and current Commission pages also note later timelines for some high-risk rules. Treat that as compliance-pressure context, not legal advice.

Sample - synthetic data

Evidence pack: expired grant, group mismatch, verified audit continuity

This sample is built around the post-approval failure buyers actually ask about: an AI access approval expired, review-before-expiry did not confirm continued need, and the configured Okta group still observed the user as a member. Governance Logs continuity checks pass over the retained sample events, while the access-removal finding remains open.

Product output today Requests, request history CSV, Governance Logs, audit JSONL, policy evidence JSON, configured-group checks, and audit-chain verification metadata.
Sample synthetic data Every identity, request key, policy label, group ID, timestamp, and hash value in the public bundle is synthetic.
Design-partner deliverable CA$20k, 8 weeks, 3 slots: stand this up around one real AI access process and produce the buyer's evidence pack.
Download PDF Buyer-facing sample pack with honesty key, lifecycle finding, screenshots, and verification summary. Governance Logs JSONL sequence, action, prevHash, entryHash, entryMac, hashAlgorithm, keyId, integrityState. Request/grant CSV Request history export shape with requester, approver, grant status, expiry, lifecycle summary, and issue URL. Verification summary JSON Continuity pass, retained-event caveat, and open configured-group mismatch finding. Policy evidence JSON Current product evidence-pack export shape: catalog, lifecycleEvidence, attestations, and audit summary. Screenshots ZIP Watermarked product-surface screenshots using synthetic scenario data.
Preview of the AI Clearance sample evidence pack PDF cover showing an expired grant, configured group mismatch, and audit continuity summary.
The PDF is a buyer-facing sample built from current CSV, JSONL, JSON, request/history surfaces, and Governance Logs; a buyer-specific PDF narrative is a design-partner deliverable.
Scope limit: configured-group evidence only means Okta or Microsoft Entra group membership where connected mode is configured and the group controls the real app, license, role, or resource. AI Clearance does not inspect prompts, prove runtime AI usage, replace IAM/IGA, or independently notarize audit events.

Recertification and drift

Recertification reviews (review-before-expiry) ask whether the approved user still needs the AI tool before the grant expires or continues. Scheduled recertification checks create recert issues for active grants entering the review window.

Drift checks answer a different question: does Okta or Microsoft Entra configured-group membership still match the approval record? That check is useful because a ticket can be correct while the group membership has changed.

Important scope limit

AI Clearance checks the configured group boundary only. IdP and app admins must make that group control the real app, license, role, or resource.

Where native JSM ends and AI Clearance begins

Capability Native JSM AI Clearance
Intake and approval routing Handles well with request types, forms, approver fields, and workflow approval steps. Uses JSM intake and preserves the AI-specific lifecycle record after approval.
Requestable AI catalog Buildable with Assets or custom fields, but upkeep is on the admin team. Built-in approved AI tool catalog with risk, expiry defaults, guidance, and optional connector binding.
Duplicate-request blocking Possible with custom automation and JQL, but not turnkey. Blocks approval when a duplicate open grant exists for the same user and tool.
Timeboxed grants and expiry Possible with custom date fields and automation. Tracks grant duration, expiry labels, expiration jobs, extension limits, and revocation/deprovisioning state.
Recertification reviews Possible as custom recurring/review issues. Scheduled recertification checks can create review-before-expiry issues for grants entering the recertification window.
Evidence export as a pack Requires custom export design beyond ordinary ticket history. Exports request and grant data; Governance Logs include hash-chain integrity metadata such as prevHash and entryHash for export-verifiable audit continuity.
Okta/Entra reconciliation Not native; requires manual checks or custom integration. Optional connected mode can add, remove, or run drift checks for configured-group membership only.

Read the full AI Clearance vs native Jira Service Management comparison.

Security, privacy, and egress

  • Baseline app state is stored in Atlassian Forge storage.
  • Connected mode is optional and requires explicit admin configuration.
  • Connector credentials are stored through Forge secret storage.
  • Connected-mode requests to ArdSaor Core are scoped to connector testing, tenant binding, identity matching, and configured-group add, remove, or check actions.
  • IdP and app admins remain responsible for making the configured group control the real app, license, role, or resource.
  • Admins can review privacy, security, SLA, and support documentation before rollout.

Operational links

Design partner program

Three design-partner slots are available for teams that want to shape the hash-chained evidence-pack, recertification, and drift-check workflow before it hardens into the product.

The program is scoped to 8 weeks, includes direct access to the builder, and is offered at CA$20k for one real AI access process and buyer-specific evidence pack.

What the 8-week sprint includes

  • AI Clearance product access during the sprint.
  • Setup around one real JSM AI access workflow, including catalog, request, approval, policy, and expiry configuration.
  • Working sessions with the JSM, IAM, security/GRC, or enterprise-app owners who touch the workflow.
  • Okta or Microsoft Entra configured-group boundary mapping, or a manual evidence path when connected mode is not ready.
  • One controlled request, approval, grant, expiry, review-before-expiry, and evidence scenario.
  • Governance Logs export, continuity verification walkthrough, and buyer-specific evidence-pack handoff.

Best fit

JSM platform owners, GRC owners, or security teams that need verifiable audit-trail metadata, not screenshots, and have a concrete Okta or Entra configured-group boundary to test.

Scope limit

This is not a full IAM/IGA replacement, runtime AI monitor, or broad enterprise rollout. The sprint stays bounded to one AI access process and the evidence needed to prove it.

FAQ

What problem does AI Clearance solve?

AI Clearance focuses on lifecycle evidence after AI access is approved: active grants, expiry, recertification reviews, Okta or Entra match status, drift, and exportable access review proof.

Can native JSM handle intake and approval?

Yes. Native JSM can handle basic request intake and approval. AI Clearance is focused on the evidence layer after approval: recertification, expiry, identity-system match or mismatch, drift visibility, and audit exports.

Does AI Clearance change group membership automatically?

Only within the configured-group boundary. When Okta or Microsoft Entra connected mode is configured, AI Clearance can add, remove, or check the approved user in the configured group. IdP or app admins must make that group control the real app, license, role, or resource.

Does it monitor what users type into AI tools?

No. The product governs access requests, decisions, grants, expiry, and evidence. It does not inspect prompts, prove runtime AI usage, or replace IAM/IGA.

Where is app data stored?

Baseline app data is stored in Atlassian Forge storage. Optional connector operations use ArdSaor Core only when connected mode is explicitly configured.

Can native JSM plus Assets do this without an app?

Yes, for simple intake, approval, and a maintained catalog. The tradeoff is that your team owns the Assets schema, automation rules, recertification workflow, duplicate-open-grant checks, IdP reconciliation, and evidence export format.

What does an auditor actually receive?

The useful unit is an evidence pack: request context, approval decision, policy and risk context, grant duration and expiry, recertification review state, configured-group drift-check outcomes where connected mode is configured, and hash-chained Governance Logs with integrity metadata. The public sample evidence pack on this page uses fictional demo data to show the expected export-verifiable shape.

What happens at expiry?

Scheduled lifecycle automation expires overdue grants and creates review-before-expiry issues for grants entering the recertification window. Manual or connected deprovisioning follow-up depends on the configured fulfillment path.

Is this an IAM or IGA replacement?

No. AI Clearance is a JSM-centered evidence layer for AI access decisions. It does not replace IAM/IGA, does not prove runtime AI usage, and only checks configured Okta or Entra groups when connected mode is configured.

Buyer guides

AI Clearance vs native JSM AI access lifecycle evidence Prove AI tool access compliance AI access recertification Access drift explained

Review your AI access evidence path

Bring one current AI access workflow and one evidence request. The teardown maps whether hash-chained Governance Logs and the sample evidence pack cover the proof your GRC/security team asks for.

No public scheduler URL is configured yet. Email Andrew with the workflow context and he will reply with available times.

Install from Atlassian Marketplace Download sample evidence pack