Letting coding agents into MongoDB: what the access controls actually control

Two things arrived close together this year and the coverage tends to blur them. The Atlas Managed MCP Server, with Atlas App Connections behind it, is an Atlas service: MongoDB runs the MCP server, and coding agents reach your clusters through it. InfoWorld dates its availability to 13 August. MongoDB 9.0 is a server release — 9.0.0 is dated 28 September 2026 — and neither depends on the other.

Both matter if an agent can query your data. This article covers what the access controls really govern, how to run the MCP server yourself so read-only stays read-only, and the 9.0 changes that affect the queries an agent writes.

Two ways in

The MongoDB MCP Server can reach Atlas through two access models. MongoDB's access models page is the source for this section.

User-delegated access is for a developer prompting Claude Code, Cursor or Codex interactively. It replaces the shared service account a team would otherwise pass around: the client uses OAuth and cannot exceed the permissions of the person who authorised it.

If you are building your own agent — a pipeline, a triage bot, anything without a person approving each step — user-delegated access is not an option, because it only works with clients MongoDB registers in advance. You need an MCP configuration instead.

What the organisation switch does, and what it doesn't

Enabling AI client access is an Organization Owner's decision, and the documented behaviour has edges worth knowing before you flip it:

• It is all or nothing across clients. Enablement applies to every registered AI client together; you cannot enable Claude Code and leave another client off.
• It is organisation-wide. You cannot restrict AI client access to specific projects. If production and staging live in the same organisation, both are reachable within each user's own roles.
• Read-only mode is the one narrowing tool. It can hold an AI client below the permissions of the user who authorised it. Nothing else does.
• Tool calls are not individually recorded. Atlas records an audit event only when a tool call causes one — creating a cluster, for example — and then names both the user and the AI client. A query an agent runs against your data does not appear as its own entry.

The last point is the one to be clear about when someone asks for an audit trail. "Every action attributable" holds for actions that already produce Atlas audit events. For reads, it doesn't.

Running the MCP server yourself: read-only is a tool list

Outside Atlas — Community Edition, Enterprise Advanced, a local cluster, or when you want the credentials under your own control — you run the open-source mongodb-mcp-server. It has a read-only option, and it is easy to misread what it does.

readOnly restricts the server to tools with "read" and "metadata" operation types, per the project's README. It changes which tools the agent is offered. It does not change what the database user in your connection string is allowed to do. If that user can write, a configuration change away from read-only is all that stands between the agent and your data.

Start with a database user that can only read one database. On a self-managed deployment:

db.getSiblingDB("admin").createUser({  user: "agent_ro",  pwd: passwordPrompt(),  roles: [{ role: "read", db: "shop" }],});

On Atlas, create the same user from the Database Access page with the built-in read role on that database. Then point the MCP server at it with read-only mode on as well. In Claude Code:

claude mcp add mongodb \  -e MDB_MCP_CONNECTION_STRING="mongodb://agent_ro:<password>@localhost:27017/shop?authSource=admin" \  -e MDB_MCP_READ_ONLY=true \  -- npx -y mongodb-mcp-server@latest

Before you trust the configuration, check what it actually exposes. The server's dry-run option prints its configuration and the list of enabled tools, then exits, as described in MongoDB's enable-or-disable-features page:

$ MDB_MCP_READ_ONLY=true MDB_MCP_DRY_RUN=true npx -y mongodb-mcp-server@latest

If any write tool appears in that list, the flag did not take. To trim further, MDB_MCP_DISABLED_TOOLS takes a comma-separated list of tool names or categories — atlas, for instance, if the agent has no business near cluster management.

What MongoDB 9.0 changes under an agent's queries

The 9.0 release notes include four changes that bear directly on agent-written queries. MongoDB is rolling 9.0 out to Atlas clusters on the "Latest Version With Auto Upgrades" option first, so some clusters get these before their owners have read about them.

A per-operation memory limit. A single query operation may now use at most 1 gigabyte or 20% of the server process's memory, whichever is greater. Operations over the limit fail with ExceededMemoryLimit or QueryExceededMemoryLimitNoDiskUseAllowed; in earlier versions there was no ceiling. For agents this is mostly good news — the unbounded $group over a whole collection now fails instead of starving the server. Handle those two errors in any tool that runs model-written aggregations, and return something the model can act on, rather than a stack trace.

Server-side JavaScript is back. $where, $function and $accumulator were deprecated in 8.0. In 9.0 they are no longer deprecated and run on a WebAssembly-based engine with stronger sandboxing. That matters here because all three can appear in a read: a read-only role and a read-only MCP server both still allow a find with $where. If your own agent tools pass model-written filters to the driver, keep an operator allowlist rather than a blocklist, and see MongoDB's server-side JavaScript page for your options at the server level.

Null comparisons on dotted paths changed. A dotted path that doesn't resolve to a non-null value now evaluates as null, including where a field holds an empty array or an array of scalars. Queries that compare such a path to null can return different results after the upgrade. An agent-written query that was checked against 8.x output is not checked against 9.0 output.

Per-shape maxTimeMS. You can now set a time limit for a single query shape with setQuerySettings, which needs feature compatibility version 9.0. If one agent-generated query shape keeps timing out your dashboards, this caps that shape without touching the rest.

The compatibility changes page has the full list; read it before you let auto-upgrade take a production cluster.

Agent Skills are guidance, not enforcement

MongoDB also publishes Agent Skills: instructions on schema design, indexing and similar topics that a coding agent loads as context. The MCP server's setup utility can download them alongside the server configuration, according to its release notes:

$ npx mongodb-mcp-server@latest setup

They improve what an agent proposes. They do not constrain what it can do. A skill that says "use compound indexes" is advice to the model; a database role that says "read only" is a rule the server enforces. Treat skills as the first kind of thing and never as a substitute for the second.

Before an agent touches production data

• You know which access model each agent uses, and home-built agents use MCP configurations, not someone's personal login.
• Your organisation's AI client access setting is one you chose, not the sign-up default.
• Anything self-hosted connects as a database user with the read role, and read-only mode is on as well.
• A dry run shows no write tools.
• Your agent tools handle the 9.0 memory-limit errors and allowlist query operators.
• You have read the 9.0 compatibility changes before auto-upgrade reaches a cluster an agent queries.