AgentArmorHQ
Sign in
Permissions and access

Create read-only database roles instead of trusting MCP read-only flags

AgentArmorHQ team2 min read

You will give the agent its own database login that can only read the tables it needs, so a flaw in an MCP server cannot change or delete data. The limit lives in the database, not in the tool.

  1. Agent sends queryMCP server forwards the request
  2. Connection uses agent loginCredential comes from the secrets manager
  3. Database checks the roleOnly SELECT on listed objects is granted
  4. Write attempt is refusedPermission error, no data changes

Why it matters

An MCP server runs with the access you give it, and its own checks can fail. In mcp-atlassian, the token verifier accepted any non-empty string in HTTP deployments, so unauthenticated callers could reach server-side credentials (GHSA-wrhw-j3f9-8vc6 (opens external site)). A separate flaw let the upload tool read arbitrary host files without the path check (GHSA-93xw-j965-9mx3 (opens external site)). When a tool's own gatekeeping fails, the database's permissions are the limit that still applies, so I set it there.

Steps

  1. Decide which schemas and tables the agent actually needs to read, and write that list down before you touch anything.
  2. Create a dedicated database role for the agent. Do not reuse your admin user, your app user, or any role that can write.
  3. Grant that role only SELECT (or the equivalent read privilege) on the listed objects. Do not grant it on the whole database by default.
  4. Revoke any inherited write, DDL, or superuser privileges from that role, including through group memberships.
  5. Create a separate login for the agent that maps to this role, and store its credential in your secrets manager rather than in plain config files.
  6. Test the connection by attempting an INSERT, UPDATE, and DROP. Each should fail with a permission error. Then confirm a SELECT on an allowed table still works.
  7. Keep the MCP server patched. If you run mcp-atlassian, upgrade to 0.22.0 or later (GHSA-93xw-j965-9mx3 (opens external site)).

Common mistakes

  • Trusting the MCP server's own checks and never verifying what the database role can actually do.
  • Giving the agent the same credential your application uses, so it inherits write access.
  • Granting read access on the whole database when the agent only needs two tables.
  • Running an old MCP server version. Both mcp-atlassian advisories were fixed in 0.22.0 (GHSA-wrhw-j3f9-8vc6 (opens external site)).

Checklist

0 of 8 done

Sources

  1. GitHub Advisory Database: GHSA-wrhw-j3f9-8vc6 (CVE-2026-77244)
  2. GitHub Advisory Database: GHSA-93xw-j965-9mx3 (CVE-2026-77258)
Was this guide useful?