# Weekly MongoDB Atlas security audit with Linear tickets

> Every Monday, review each database project for risky access rules and over-permissioned accounts, then get a ranked Slack summary and tickets.

- Workflow type: agent
- Services: MongoDB Atlas, Slack Bot, Linear
- Categories: Engineering, Operations
- Published: 2026-08-07

## What it does

- Walks every database project you have access to each Monday morning and pulls its network access rules and database accounts
- Flags the risky ones: access open to the entire internet, overly broad address ranges, rules with no explanation of why they exist, temporary rules that should have expired already, and accounts holding admin level permissions
- Posts a single ranked summary to your security channel so the worst issues are at the top
- Files a ticket for each serious finding naming the project, the exact rule or account, why it is a problem, and the suggested fix
- Never changes anything on its own, so an audit can never lock your applications out of the database

## What you'll need

- A MongoDB Atlas account with an API key that can read projects, network access rules, and database accounts
- A Slack workspace and a channel for the weekly summary, such as #security
- A Linear account and the team where remediation tickets should be filed

## Prompt

Every Monday at 7am, audit the security posture of all of our MongoDB Atlas projects and file remediation tickets for the serious problems. This is a review only workflow: it reports and files tickets, and it never changes anything in Atlas.

Start by discovering the full estate rather than working from a hardcoded list. Use MongoDB Atlas List Organizations to get every organization the API key can reach, then use List Projects in Organization for each one to build the complete set of projects. For every project, pull List IP Access List Entries and List Database Users.

Review the access list entries for each project and flag anything risky. Treat an entry of 0.0.0.0/0, which exposes the project to the entire internet, as the most severe finding. Also flag CIDR ranges that are unusually wide for a single office or server, meaning anything broader than a /24, with progressively higher severity as the range widens. Flag entries with no comment, since the comment is the only record of why an entry exists and an unexplained rule is one nobody can safely remove later. Flag temporary entries whose expiry date has already passed but which are still present on the list.

Then review the database users. Flag any user holding broad roles such as atlasAdmin, readWriteAnyDatabase, or dbAdminAnyDatabase, and note which databases each role actually spans. Flag users that look stale or cannot be attributed to a specific person or service, for example generic names like test, temp, demo, backup, or admin, and any user whose name gives no clue who owns it. The user listing does not include last login activity, so base attribution judgements on the username, the authentication method, and the roles and scopes visible in the listing, and say plainly when a user is suspicious rather than provably unused.

Assign each finding a severity of high, medium, or low based on how much access it grants and how exposed it leaves the data. Then post one ranked summary to the #security channel using Slack Bot Send a Message, worst first, grouped by project. Include the total number of projects audited, a count of findings by severity, and for each finding the project name, the specific entry or user, and a one line reason it is risky. If a week comes back clean, still post the summary confirming the audit ran and nothing was flagged, so silence is never ambiguous.

For each high severity finding, create a ticket with Linear Create Issue. Give it a title that names the project and the specific entry or user so repeat findings are easy to recognize week over week, and a description that states the project, the exact access list entry or database user, why it is risky, and the concrete suggested fix, such as narrowing the range to the known application servers, adding a comment describing the purpose, removing an entry that expired on a given date, or replacing a broad role with a scoped one. Medium and low severity findings belong in the Slack summary only and should not generate tickets.

Under no circumstances should this workflow delete or modify an access list entry or a database user. Do not call Delete IP Access List Entry or any operation that edits users or network access, even when a finding looks obviously wrong. Auto revoking network access can lock production applications out of the database, so the deliverable here is the reviewed ticket and a human makes the final call.

## How to customize

- Change the timing, for example run it daily during a compliance push or move it to Friday afternoon
- Adjust what counts as risky, such as how wide an address range has to be before it gets flagged, or which permission levels are acceptable in your setup
- Point the summary at a different channel, and choose which Linear team and priority the tickets land on
- Limit the audit to production projects only, or skip projects used for development and testing

## FAQ

### Will this change or delete anything in my database?

No. The audit is deliberately read only. It looks at your access rules and accounts and reports what it finds, but it never removes or edits them. Automatically revoking access can take a live application offline, so a human always makes the final call from the ticket.

### What does it actually consider risky?

Access rules that let in the entire internet, address ranges far wider than a single office or server needs, rules with no comment explaining their purpose, and temporary rules whose expiry date has already passed. On the account side it flags admin level permissions and accounts that cannot be tied back to a person or a service.

### Why does a missing comment matter?

MongoDB recommends describing the purpose of each access rule so it can be audited later. A rule with no explanation is one nobody can confidently remove, which is how stale access piles up over the years.

### Does it cover all of my projects automatically?

Yes. It discovers every project your API key can reach rather than relying on a list you maintain by hand, so newly created projects are included in the very next audit.

### What happens on a week when nothing is wrong?

You still get the summary confirming the audit ran and everything looked clean, and no tickets are created. That way silence never leaves you guessing whether it actually ran.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-mongodb-atlas-security-audit-with-linear-tickets