One Service Identity per Agent: Credential Design for Postgres, Snowflake, and Databricks MCP Servers

Why a shared MCP service account breaks least privilege

Many MCP servers that front Postgres, Snowflake, or Databricks start with one broadly privileged account that every agent shares. It is easy to deploy, and it fails in four predictable ways.

Attribution is lost, because the database sees one principal and cannot say which agent issued a query. Least privilege cannot be applied per agent, because the grants belong to the account and must cover the most demanding agent. A single compromised or misbehaving agent can reach everything the shared credential can reach. Rotation and revocation are also all or nothing, so responding to one agent means interrupting all of them.

NIST guidance points the other way. Under SP 800-162, authentication happens through identity credentials, and the attributes in a credential should uniquely determine the subject. A shared account cannot meet that test. NIST also treats authentication and authorization as separate controls, so a unique identity is the precondition for scoped access, not a substitute for it.

Authenticate at each hop, and map one agent to one identity

Treat the path as two legs. The first runs from the agent to the MCP server. The second runs from the MCP server to the data platform. NIST SP 800-207A says services should authenticate the credential at each hop, and that each service should present a short-lived, cryptographically verifiable identity credential that is reauthenticated regularly. Applied here, the MCP server verifies who the agent is on the first leg, then connects downstream as the identity bound to that agent on the second.

Keep the mapping explicit and one to one. Maintain an inventory that lists each agent, its MCP server, its downstream identity, its accountable owner, and the access it was approved for. Do not reuse an identity across agents, even when two agents currently need the same grants. Grants drift apart over time, and a shared identity brings back every problem described above.

The MCP server should never accept a downstream identity name from the agent as a free-form parameter. The server holds the binding, so an agent cannot ask to run as someone else.

Platform-by-platform credential design

Each platform has a native identity construct for non-human workloads. The table summarizes the design choice for each. Confirm exact settings against current vendor documentation before rollout.

• Postgres: Identity: one LOGIN role per agent, inheriting from a group role that holds grants. Credential: client certificates or a managed-service IAM mechanism where available, rather than a shared password. Scope: SELECT on named schemas, read-only by default, row-level security keyed to the role. Attribution: the role name appears in connection and statement logs, including pgaudit where enabled.
• Snowflake: Identity: one service user per agent, with its own role. Credential: key-pair authentication or OAuth, not a password. Scope: a role granted only the needed warehouse, database, and schema privileges, plus row and column policies where data is sensitive. Attribution: the user name in query history, with a query tag for added context.
• Databricks: Identity: one service principal per agent. Credential: OAuth machine-to-machine, where the principal exchanges its client credentials for a short-lived access token. Avoid personal access tokens, which are long-lived and tied to a person. Scope: privileges on specific catalogs, schemas, and tables, plus access to a specific compute resource. Attribution: the principal appears in audit logs.

Scope grants, plan rotation, and preserve attribution

Start with grants. Create a role per agent, or a per-agent role that inherits from a small set of reviewed group roles. Default to read-only. Grant on named schemas or tables, not on whole databases, and avoid administrative privileges entirely. Where agents read sensitive tables, add row and column controls so that the agent's identity, not application code, determines what rows and fields are visible.

Next, choose credential lifetimes. Short-lived tokens, such as those issued through OAuth, reduce the value of a leaked secret and match the NIST recommendation to reauthenticate regularly. Where a platform requires a static secret or key, store it in a secrets manager scoped to that one agent's MCP server, and rotate it on a schedule. For key-pair authentication, rotate by adding the new public key before removing the old one so that the agent does not lose access mid-rotation.

Revocation should be tested before it is needed. For each identity, document how to disable the login or principal, invalidate its secrets, and end open sessions. A good result is that one agent loses access within minutes and no other agent notices.

Finally, make attribution deliberate. The unique identity does most of the work, because it appears in each platform's native audit records. Add session-level context, such as a query tag or application name set by the MCP server, to record the tool or task. Then verify with a test query from each agent and confirm the audit record names the correct identity.

What database controls cannot do, and where runtime enforcement fits

Database-native controls govern the identity's access. They decide whether a role can read a table. They do not evaluate the content or intent of an individual tool call. If an agent is permitted to read a customer table, the database will serve any query that role is allowed to run, including one an injected instruction produced. Nor does a database audit record show what the agent was asked to do or what happened to the result before it left the MCP server.

This is where policy enforcement in the execution path complements identity-level grants. NIST zero trust guidance describes external policy-based authorization engines that use contextual variables alongside service identities, and the two layers do different jobs. Trussed enforces policy on MCP server tool calls in the execution path, with decisions to allow, redact, or block at runtime rather than review after the fact. Each enforcement decision produces audit-ready evidence of what the agent attempted and what policy applied. That evidence sits next to the database's own records, with the per-agent identity as the shared key between them.

The two layers are not interchangeable. Scoped credentials limit the blast radius when enforcement is bypassed or misconfigured, and enforcement limits what an authorized identity can do with its access.