# Audit your CircleCI contexts and shared build secrets

> See every CircleCI context on one screen, with the secrets inside, which projects can use them, and which ones are risky enough to fix today.

- Workflow type: app
- Services: CircleCI, Linear
- Categories: Engineering, Operations
- Published: 2026-08-16

## What it does

- Lists every context in your CircleCI organization on a single screen, with how many secrets each one holds and which projects are allowed to use it
- Flags the risky ones for you: contexts any project can use, secret names that look like production credentials, and secrets nobody has rotated in over a year
- Shows secret names, dates, and access rules only. The stored values are never fetched or displayed, so the screen is safe to share in a review meeting
- Lets you fix problems in place: replace a secret, remove one, lock a context down to specific projects, or delete a context nobody uses, each behind a typed confirmation
- Files a remediation ticket in Linear for anything you would rather hand off, pre-filled with the context name and why it was flagged

## What you'll need

- A CircleCI account with organization admin access. Context information is admin only, so a regular member account will see a permission message instead of a list
- The name of the CircleCI organization you want to audit
- A Linear workspace, if you want the hand-off button that files remediation tickets

## Prompt

Build me an internal app my platform team opens once a month to audit our CircleCI contexts and the shared build secrets inside them. Right now that audit means clicking through organization settings one context at a time, and there is no single place that shows what secrets exist, who is allowed to use them, and which ones have gone stale. I want that one place.

The main view is a table of every context in the organization, loaded with List contexts. For each context, call List environment variables to get the variable names and their created and updated timestamps, and Get context restrictions to get the projects and groups allowed to use it. Use Get a context for the created date and any other basic detail. Columns: context name, number of secrets it holds, allowed projects (or a clear "unrestricted" marker when there are none), the date of the oldest secret update, and risk badges. Sort the riskiest contexts to the top by default, and put summary counters above the table for total contexts, total secrets, unrestricted contexts, and stale secrets.

Important: List environment variables deliberately does not return the values of the secrets, only their names. That is exactly what I want, because this screen gets shared in review meetings. Never try to fetch or display a stored secret value anywhere in the app, and say plainly in the interface that values are never retrieved.

Flag risky contexts automatically with three rules, and show which rule fired on each row. First, a context with no project restriction at all, meaning any project in the organization can use its secrets. Second, variable names that look like production credentials, matching words like PROD, PRODUCTION, LIVE, RELEASE, DEPLOY, ROOT, or ADMIN, especially when combined with SECRET, TOKEN, KEY, PASSWORD, or CREDENTIAL. Third, secrets whose updated timestamp is more than a year old, which almost always means nobody has rotated them. Make the stale threshold and the production word list adjustable in a settings area rather than hardcoded.

Clicking a context opens a detail view showing every secret name in it with its created and updated dates and its own stale flag, plus the full list of project and group restrictions. This is where the fixes happen.

Let me fix things in place from that detail view. Add or update an environment variable to rotate or replace a secret, taking the name and the new value as input and making it clear the value is written and never read back. Remove an environment variable to drop one. Create context restriction to lock a context down to a specific project. Delete context restriction to remove one. And Delete a context for ones nobody uses. Put every destructive action behind a typed confirmation where I have to type the exact context or variable name before the button becomes active. The delete context dialog must state that deleting a context also deletes every environment variable inside it and that any job depending on it will start failing. Refresh the affected row after each action so the table always reflects reality.

For anything I would rather hand off than fix on the spot, give me a button that files a remediation ticket in Linear with Create Issue. Pre-fill the title with the context name and the problem, and the description with why it was flagged, the secret names involved, the current project restrictions, and the date of the audit. Let me choose which Linear team it goes to, populated from List Teams, and remember that choice. Store the filed issue identifier and URL against the context so next month the row shows that a ticket already exists and links to it instead of offering to file a duplicate. Keep a light audit history too: context, what was flagged, whether it was fixed or ticketed, and when, so each monthly review starts from what was left open last time.

Explain the permission requirement up front, in a banner at the top of the app. Context endpoints in CircleCI require organization admin membership, and a token without it comes back as a permission error, sometimes disguised as a not found response. If the context list fails that way, show a clear message saying the connected account needs organization admin access, rather than rendering an empty table that looks like the organization has no contexts.

One more thing on design: the app handlers run with the connection of whoever set it up, so do not build per viewer permission tiers or role checks. The typed confirmation dialogs are the safety mechanism for the destructive actions.

## How to customize

- Change how old a secret has to be before it counts as stale. One year is the default
- Adjust the words that mark a secret name as production looking, such as PROD, LIVE, DEPLOY, or ROOT
- Choose which Linear team remediation tickets are filed against, and what the ticket title looks like

## FAQ

### Can this app see the actual values of our secrets?

No. CircleCI does not return the stored value of a context secret, so the app can only ever show names, dates, and access rules. That is the point: you can put this screen on a shared display or in a review meeting without leaking anything.

### Why do I see a permission message instead of my contexts?

Context information in CircleCI is restricted to organization admins. If the account you connected is a regular member, CircleCI refuses the request, and sometimes reports it as if nothing exists at all. The app tells you this directly rather than showing an empty list. Ask an owner of your organization to give the account admin access.

### What makes a context get flagged as risky?

Three checks run automatically. A context with no project restriction at all, meaning any project in the organization can use its secrets. Secret names that read like production credentials. And secrets that have not been updated in more than a year, which usually means nobody has rotated them.

### Will deleting a context break my builds?

It can. Deleting a context also deletes every secret inside it, and any job that depends on that context will start failing. That is why deletion asks you to type the context name before it will go through, and why the app is happy to file a ticket instead if you would rather have someone check first.

### Does everyone who opens the app need their own CircleCI access?

No. The app works through the connection of whoever set it up, so everyone sees the same information. Share it with people you trust to make changes, since the typed confirmations are what stand between a click and a deleted secret.

Use this prompt in General Input: https://www.generalinput.com/prompts/audit-your-circleci-contexts-and-shared-build-secrets