Without tool-call governance, security teams lose visibility into what the agent actually received, not just what it was allowed to request. Bulk SELECTs can move regulated data into the model context in one response, audit evidence is incomplete, and existing network or SaaS DLP controls do not inspect the SQL result path. The result is a compliance and breach investigation blind spot.
Why Tool-Call Governance Is the Control Boundary for Postgres MCP
Postgres access through MCP is not just another database integration. The risk appears when an autonomous agent can issue a tool call that returns live rows, then immediately place that output into model context for reasoning, summarisation, or follow-on actions. At that point, the security question is no longer only “who could query the database?” but “what data was actually delivered into the agent loop?” That distinction is central to OWASP Agentic AI Top 10 and NHIMG’s analysis of OWASP Agentic Applications Top 10, because the agent’s tool layer becomes the true enforcement point.
NHIMG research on The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which helps explain why this failure mode is so common. Without tool-call governance, bulk reads can bypass the scrutiny normally applied to application queries, and the resulting exposure is harder to reconstruct after the fact. In practice, many security teams discover the issue only after regulated data has already been streamed into the model context, rather than through intentional review of MCP tool permissions.
How It Breaks at the MCP Tool Layer
Tool-call governance is the layer that decides whether an agent may invoke a specific action, under what context, and with what limits on result size, table scope, and data sensitivity. For Postgres MCP, that means governing the tool call itself, not just the network path to the database. A static allowlist of database connectivity is insufficient when the agent can generate different SQL each time based on prompt context, prior tool outputs, or changing goals.
Current guidance suggests treating the tool invocation as the security event. That usually means tying policy to the requested operation, the agent identity, the request context, and the intended data domain. In practice, controls often include:
- Per-tool authorization so the agent can query only approved datasets.
- Result-size and row-limit enforcement to reduce bulk extraction risk.
- Field-level redaction or masking before output reaches model context.
- Short-lived, task-bound credentials rather than durable database secrets.
- Logging that captures the SQL request, policy decision, and returned result metadata.
This is where NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls remain useful, but they need to be applied to the agent tool path rather than only to the database perimeter. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a practical reference for aligning identity, audit, and lifecycle controls around non-human workloads. These controls tend to break down when a single agent can chain multiple tool calls across schemas, because each individual call looks permissible while the combined sequence produces sensitive data extraction.
Where the Gaps Show Up in Real Deployments
Tighter tool-call governance often increases engineering overhead, requiring organisations to balance data minimisation against developer speed and operational flexibility. The tradeoff is most visible in teams that want agents to work broadly across production Postgres while still preserving auditability and least privilege.
The hardest edge cases usually involve exploratory agents, analyst assistants, and multi-step workflows. Best practice is evolving, but there is no universal standard yet for how much result content an agent may receive before it is considered an exposure event. That matters because once a query result is in the model context, network DLP and SaaS DLP are often already too late to help. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs are useful when defining who owns the agent credential lifecycle, but the governance question here is narrower: can the tool call itself be constrained, inspected, and revoked in real time?
Organisations with strong database IAM but weak MCP policy often assume the danger is SQL injection or stolen credentials. In reality, the bigger gap is authorised misuse by an autonomous actor that can read, summarise, and forward data at machine speed. The SailPoint findings on AI agents show how quickly scope drift becomes operational, and that is exactly why Postgres MCP needs explicit tool-layer controls rather than inherited trust from the database layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agent tool abuse and overbroad output handling are core risks in Postgres MCP workflows. |
| CSA MAESTRO | MA-03 | MAESTRO addresses governance for autonomous agents interacting with external tools and data. |
| NIST AI RMF | AI RMF covers governance and monitoring of harmful or unintended agent behaviour. | |
| OWASP Non-Human Identity Top 10 | NHI-04 | Postgres MCP depends on protecting non-human identities and their credentials. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access control are directly impacted by tool-call governance failures. |
Constrain each agent tool call with runtime policy, output limits, and explicit approval boundaries.
