Agent Ledger for Jira

Privacy Policy

Version 1.3 · Effective November 6, 2026

This policy explains what data Agent Ledger for Jira (the "App") uses, where it is kept, and how it is removed. The App is made by Arch Badger 500, LLC ("we", "us"), an Indiana company, and is sold through the Atlassian Marketplace.

1. The short version

  • The App runs entirely on Atlassian's cloud, on Atlassian Forge.
  • It keeps its data in Forge storage, inside your Atlassian site. It also saves a short outcome summary on agent-handled work items in your Jira site (see section 3).
  • It makes no calls to servers outside Atlassian. We run no servers of our own.
  • It stores metadata, not content. It does not store work-item descriptions, comment text, attachments, or source code.
  • We cannot read the data the App stores in your site.
  • We do not sell data, and we do not use it for advertising.
  • The optional Agent Access Log (off by default) keeps credential-use metadata in Forge storage for a set period (90 days by default). See section 7.

2. What the App reads

When a Jira admin installs the App, Atlassian asks them to approve these permissions:

  • read:jira-work: work items and their change history
  • read:jira-user: user details, so the App can tell app accounts (such as AI coding agents) from people
  • storage:app: the App's own storage
  • write:issue.property:jira: used only to save the App's own ab500.ledger.v1 summary on a work item (see section 3). This permission can only write work item properties. The App never uses it to edit fields, descriptions, comments, or any other app's data, and it never deletes anything with it
  • report:personal-data: Atlassian's personal data reporting (see section 7)
  • read:graph:issue:jira, read:graph:pull-request:external, read:graph:commit:external, read:graph:repository:external, read:graph:user:atlassian: development data linked to work items through Atlassian's Teamwork Graph

When a work item is created or changed, the App reads that work item so it can refresh its summary right away. It reads the same details it uses for its nightly reports and stores nothing new from them beyond what section 3 lists.

The App asks for no permission to call servers outside Atlassian.

3. What the App stores

The App stores only what it needs to build its reports:

  • Work-item metadata: key, project, type, created date, labels, status category, and status changes with their dates.
  • People on work items: for the assignee, the people who changed a status, and comment authors, it keeps the Atlassian account ID, display name, and account type. For comments, it keeps only the author and the date, never the text.
  • Pull requests linked to work items: repository and number, title, link, state (including whether it is a draft), dates, merge commit ID, author name or GitHub login, branch, labels, and review results with their dates. From a pull-request description, it keeps at most a short marker phrase that shows an AI tool wrote it, such as "Generated with Claude Code". It does not keep the rest of the description.
  • Commits (optional GitHub webhook only): commit ID, date, repository, branch, the first line of the message, and trailer lines such as "Co-authored-by" or "This reverts commit".
  • Reports: computed results per work item and monthly summaries. To avoid rewriting work item summaries that have not changed, it also keeps a fingerprint of the last summary it saved on each work item, and a cached list of your site's status categories.
  • Open sprint work: for work items not yet done that are in a sprint, the work item key, project, sprint, and whether it is agent work, so the sprint view can show open work. It keeps at most 5,000 of these and no personal data.
  • Settings: the projects to include, the attribution threshold, and any AI tool costs an admin uploads (tool, month, amount).
  • Work item summary (ab500.ledger.v1): on work items that an AI coding agent worked on, or that have linked pull requests, the App saves a small summary as a Jira work item property, so you can search it with JQL (for example ab500LedgerAgent = "copilot"). It holds only:
  • the AI tool's name (such as "copilot"), or "none" if it is not agent work
  • whether it is agent work, and how confident the App is (none, low, medium, or high)
  • the outcome (no pull request, not merged, merged, reworked, or reverted) and the pull request state (none, draft, open, approved, declined, merged, or reverted)
  • whether it needed rework, and whether it was reverted
  • the number of linked pull requests and of change-request rounds
  • the GitHub repository of the most relevant pull request, with the owner stored as a scrambled code and the repository name in plain text
  • whether and when the work item was done, and its cycle time in hours
  • the App's name and version, the summary format version, and when the summary was updated

It holds no costs, no tokens or secrets, no pull request titles or links, no branch names, and no names or Atlassian account IDs. The owner part of the repository (the GitHub account or organization) is stored as a scrambled code, not as its name. The summary is kept in your Jira site, not in Forge storage, and it is limited to 2 KB. - Webhook secret: if an admin sets up the GitHub webhook, the secret is kept in Forge's secret store. The App never shows it again or writes it to logs.

The App does not store work-item descriptions, comment text, attachments, pull-request descriptions (apart from the marker phrase above), or source code.

4. Where the data is kept

The data in section 3 is kept in Forge storage on Atlassian's cloud, in your site's data residency location, except the ab500.ledger.v1 work item summary, which is kept on the work item in your Jira site. Atlassian hosts and protects both. Atlassian's own privacy policy and Forge data protection documentation apply to that hosting.

Nothing the App stores leaves Atlassian, except as described under Rovo and AI tools in section 6, when your admin and your users choose to connect an outside AI tool.

Platform logs. The App writes operational logs to Atlassian's Forge platform. They hold counts, timings, the App's version number, and error names and messages, but not work-item content. The App does not write work item keys or Atlassian account IDs to these logs itself, but an error message passed on from Jira or Forge can include an identifier such as a work item key. We can view these logs only to run and fix the App. Atlassian keeps these logs under its own retention policy. They are separate from the Agent Access Log in section 7, which is kept in Forge storage.

5. Data that comes in from GitHub

This applies only if a Jira admin chooses to set up the optional GitHub webhook.

GitHub sends pull-request, review, and push events into the App. The App checks each event's signature against the secret the admin set. It rejects events that don't match. It keeps only the metadata listed in section 3. Nothing is sent back to GitHub.

6. Who can see the data

  • People on your Jira site who can open the App's pages can see its reports.
  • Linked pull requests are read through Teamwork Graph as the person viewing the page.
  • Work item summaries (ab500.ledger.v1) can be read by anyone who can see that work item, including through JQL search and Jira's REST API, and by other apps installed on your site that can read work items, including other Arch Badger 500 apps. When someone opens a work item, the App can update its summary from the pull requests that person can see, so the repository name and pull request counts become visible to everyone who can see the work item. The summary contains no names, account IDs, costs, or secrets.
  • Rovo and AI tools. The App offers three read-only tools to Rovo, Atlassian's AI: one shows a single work item's summary, one lists work items that AI agents worked on in a project (at most 50, with each work item's key, title, and summary), and one gives the site's monthly numbers, the same ones the App's page shows, without any costs or list of work items. The tools run as the person using them, so the first two only return work items that person can see. A site admin can also choose to let outside AI tools that support the Model Context Protocol (MCP) use these tools through Atlassian's MCP service. This is off unless an admin turns it on. If it is on, the results go to the AI tool the person connected, and that tool's own terms apply. The App itself still makes no calls outside Atlassian.
  • We cannot see it. The App sends nothing to us, and Forge does not give us access to the data it stores in your site.
  • App logs. The App's logs record counts, timings, and error messages. They do not record work-item content, people's names, or secrets. Atlassian controls whether we can see these logs for your site.

7. How long data is kept and how it is removed

The App keeps most of its data while it is installed on your site and has no fixed retention period for work-item facts, monthly reports, or work item summaries. The App keeps each work item summary up to date while it is installed, but it never deletes one. The Agent Access Log (below) is the one exception with a fixed retention period.

Agent Access Log (optional)

The Agent Access Log is off by default. A site admin turns it on only when they choose to (on the development environment, by setting the Forge variable AL_ACCESS_LOG to on). When it is off, the App does not accept Access Log events, does not show Access Log data on work items or in Rovo, and does not run Access Log purge jobs. Existing Access Log records, if any, stay in Forge storage until an admin turns the feature on again (so purge can run) or uninstalls the App.

When the Access Log is on and a Jira admin connects a credential broker or agent runtime to the Access Log webhook, the App stores metadata only for each reported credential use: the credential's label and type, the scope and action, the work item key (when provided), the agent's name, the Atlassian account ID of the user who invoked the agent (when reported), the time, and, when the broker sends them, the decision (allowed or denied), the source system, and an event ID. The App never receives or stores the credential itself, its secret value, or any token. Payloads that look like they carry a secret are refused and not stored. The App adds no new network egress for this feature: brokers POST into a Forge static web trigger; the App does not call password managers or other outside services.

Access Log records are kept only in Forge storage for your site (not in work item properties, except a non-sensitive accessLogged: true flag on ab500.ledger.v1). The App deletes Access Log records once they are older than the retention period a Jira admin sets on the Agent Access Log page. That period is 90 days by default and can be set from 90 to 1,825 days. Deletion runs once a day when the feature is on. A weekly CSV snapshot of the previous 7 days is replaced each week in Forge storage for admins to download; the App does not email it or send it outside Atlassian.

By default, only Jira admins and admins of the work item's project can see Access Log records on a work item. A Jira admin can widen this to everyone who can see the work item, or turn the on-item view off. The site-wide Access Log report and CSV export are available only to Jira admins.

Account IDs in Access Log records are covered by the Personal Data Reporting process below. When Atlassian indicates that an account has been closed, the App erases that account ID from Access Log records. If a broker reports the invoking user as something other than an Atlassian account ID (for example an email address or the broker's own user name), that value cannot be matched through Atlassian's API and is removed when the record reaches the end of its retention period.

Personal data reporting and uninstall

Agent Ledger stores Atlassian account IDs, and the display names associated with them, only to attribute activity within the app. As required by Atlassian's user privacy guidelines for Forge apps, Agent Ledger reports the account IDs it stores to Atlassian's Personal Data Reporting API at least every 7 days. When Atlassian indicates that an account has been closed, Agent Ledger erases that account's ID and display name from its storage. When Atlassian indicates that an account's personal data has been updated, Agent Ledger refreshes its stored copy. Work item summaries contain no account IDs or display names, so this does not change them.

When a Jira admin uninstalls the App, Atlassian's Forge platform marks the App's stored data for your site as deleted (including Access Log records and the Access Log webhook secret), and the App can no longer read it. Atlassian then permanently deletes it under its standard process. A reinstall starts fresh.

The ab500.ledger.v1 work item summaries are saved in Jira itself, not in Forge storage, so they can remain on work items after an uninstall. A Jira admin can remove them with Jira's REST API (DELETE /rest/api/3/issue/{issueKey}/properties/ab500.ledger.v1), or ask us at support@archbadger500.com for a script that does it.

If you set up the GitHub webhook or the Access Log webhook, also delete those webhooks in the systems that call them.

Because we cannot access your site's stored data, uninstalling the App, and removing the work item summaries as above, is how you remove it.

8. When you contact us

If you email support@archbadger500.com, we receive your message and anything you attach. Our support mail is routed by Cloudflare and delivered to a Google mailbox. We use it only to answer you and fix problems. Please don't send secrets, passwords, or real customer data.

9. Our website

Our website, archbadger500.com, uses Cloudflare Web Analytics to count visits. This is separate from the App.

10. Security

The App relies on Atlassian's Forge platform for hosting, storage, encryption, and access control. If we learn of a security incident in the App that affects your data, we will tell affected customers, as set out in our Service Level Agreement.

To report a security issue, email support@archbadger500.com with SECURITY in the subject line.

11. Changes to this policy

If we change this policy, we will post the new version on this page with a new version number and effective date.

Changes in 1.3 (effective November 6, 2026): added the Agent Access Log to section 7 (metadata only, Forge storage, 90-day default retention with admin range 90–1,825 days, off-by-default switch, uninstall deletion, no new egress).

Changes in 1.1 (effective November 1, 2026): added the ab500.ledger.v1 work item summary (sections 1, 3, 4, 6, and 7), the write:issue.property:jira and report:personal-data permissions (section 2), the App's read-only Rovo tools and optional outside AI tool access (sections 4 and 6), and the refresh when a work item is created or changed (section 2).

12. Contact

Arch Badger 500, LLC (Indiana, USA). Email support@archbadger500.com

This policy is governed by the laws of the State of Indiana, USA.