How to govern NVIDIA Nemotron database agents

NVIDIA Nemotron 3 Ultra models excel at complex reasoning and tool use. Here is how Deedglass enforces pre-execution SQL rules, gates sensitive database writes, and verifies committed changes.

The short answer

NVIDIA Nemotron 3 Ultra (nvidia/nemotron-3-ultra-550b-a55b) provides state-of-the-art multi-step reasoning and function calling capabilities via NVIDIA NIM microservices. When granting Nemotron database tools, place Deedglass between the model’s tool calls and your PostgreSQL instance.

Deedglass serves standardized database tools over the Model Context Protocol (MCP), checks every query AST against declarative CEL policies before execution3, pauses sensitive mutations for human confirmation in Slack or the Console3, and captures PostgreSQL change data capture (CDC) deltas to check what rows actually changed3.

Deedglass reads what Postgres actually committed, not what the agent reported. In our demo a hidden trigger turned 1 row into 301; a person countersigned the undo and all 301 rows came back.

Why Nemotron agents need database boundaries

Reasoning models like Nemotron 3 Ultra analyze complex prompts by generating multi-stage execution plans and iterative SQL queries. While this enables autonomous analytical workflows, direct database connections carry real operational risks:

  1. Unconstrained data mutations: A reasoning step intending to patch a single tenant record can emit an UPDATE statement without an exact primary key filter or omit the WHERE clause entirely.
  2. DDL and privilege escalations: Autonomous agents may attempt to solve performance bottlenecks or schema mismatches by executing CREATE INDEX, ALTER TABLE, or TRUNCATE.
  3. Misalignment between model output and database reality: An agent’s chat completion might report that a single customer balance was incremented, even while an unhandled trigger or cascade touched hundreds of additional rows3.
  4. Lack of audit trails: Standard API gateways record prompt and completion token counts, but provide no cryptographic evidence linking an agent’s reasoning intent to the exact database transaction that committed.

The MCP specification states that applications should present confirmation prompts and maintain human oversight over tool invocations1. Deedglass provides this oversight without requiring modifications to the underlying model weights or host frameworks.

Connecting Nemotron to MCP tools

To connect a Python application using NVIDIA NIM and OpenAI-compatible client libraries to Deedglass, configure the agent to call Deedglass’s local MCP gateway:

Code Program code, for developers. The text around it says what it does.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://integrate.api.nvidia.com/v1",
    api_key=os.environ["NVIDIA_API_KEY"],
)

# Deedglass MCP server exposes safe database tools
tools = [
    {
        "type": "function",
        "function": {
            "name": "postgres_query",
            "description": "Execute a safe SQL read or write query through Deedglass governance",
            "parameters": {
                "type": "object",
                "properties": {
                    "sql": {"type": "string", "description": "The PostgreSQL statement to execute"},
                    "reason": {"type": "string", "description": "Agent reasoning for this database operation"}
                },
                "required": ["sql", "reason"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="nvidia/nemotron-3-ultra-550b-a55b",
    messages=[
        {"role": "system", "content": "You are an operations assistant. Always query before mutating."},
        {"role": "user", "content": "Update the billing status of organization org_981 to active."}
    ],
    tools=tools,
    temperature=0.2,
)

When Nemotron emits a tool_calls payload, your execution loop routes the call to Deedglass via standard MCP JSON-RPC or the Deedglass SDK.

Enforcing SQLguard and CEL policies

Before any SQL statement reaches PostgreSQL, Deedglass parses the SQL AST using its internal SQLguard engine and evaluates the tool invocation against your active policy3.

Here is an example policy configuration (policy.yaml):

Code A settings file: the rules a tool reads before it acts.

version: "policy/v1"
rules:
  - id: "allow-select-queries"
    description: "Allow analytical read-only queries immediately"
    match:
      tool: "postgres_query"
      cel: "sql.is_read_only == true"
    action: allow

  - id: "require-approval-for-billing-updates"
    description: "Require human confirmation when modifying billing rows"
    match:
      tool: "postgres_query"
      cel: "sql.table == 'organizations' && sql.operation in ['UPDATE', 'DELETE']"
    action: require_approval
    approval:
      channel: "slack-finance"
      timeout: "30m"

  - id: "block-unbounded-mutations"
    description: "Never allow updates or deletes without a WHERE filter"
    match:
      tool: "postgres_query"
      cel: "sql.operation in ['UPDATE', 'DELETE'] && !sql.has_where"
    action: deny
    reason: "Mutations without an explicit WHERE clause are forbidden"

If Nemotron attempts an unconstrained UPDATE organizations SET status = 'active', Deedglass halts the call immediately and returns a policy rejection message to the agent runtime.

Handling human-in-the-loop approvals

When Nemotron attempts a permitted write query that requires human authorization, Deedglass pauses the execution thread:

  1. Deedglass generates an approval request containing the model’s reasoning, the exact SQL statement, and the estimated execution cost.
  2. An interactive approval card is dispatched to your configured Slack channel, email, or the local Deedglass Console3.
  3. The human reviewer can inspect the exact statement before clicking Approve or Deny.
  4. If approved, Deedglass dispatches the query to PostgreSQL; if denied or timed out, Deedglass returns a clear rejection to the agent, allowing Nemotron to adapt its plan safely.

This satisfies the MCP recommendation that sensitive tools remain under human control without breaking the autonomous loop1.

When a reviewer responds, the action unblocks:

  • If approved, the statement executes under an isolated transaction.
  • If rejected, Deedglass writes a rejection record to the ledger and delivers an explanation to the model’s context window.

Verifying row-level ground truth

Traditional model monitoring relies solely on the LLM’s own self-reported output. If an agent states "Updated 1 record in organizations", ordinary observability platforms record that string verbatim.

However, real databases have foreign keys, cascades, and procedural triggers. In Deedglass’s test scenarios, an agent reported changing 1 row while PostgreSQL triggers actually mutated 301 rows3.

Deedglass connects directly to PostgreSQL’s replication stream (CDC) to capture the exact row deltas emitted by the transaction:

  • Expected delta: Computed from the agent’s approved SQL AST.
  • Observed delta: Read directly from the PostgreSQL WAL / logical replication stream.
  • Verdict: If the observed delta matches the expected delta, Deedglass marks the action as Matches. If unanticipated rows or unwatched tables were touched, it flags a Doesn’t match verdict.

Offline verification with Ed25519 records

Every approved and executed action produces an immutable audit record. Each record is sealed with an Ed25519 digital signature over its canonical RFC 8785 representation and chained into an org-specific tamper-evident log3.

Security teams and external auditors can verify these records entirely offline using the Deedglass CLI:

Code Commands typed in a terminal. The text around it says what happens.

deedglass verify ./audit-records.json --public-keys ./keys.json

The verification command checks cryptographic signatures, hash links, and row deltas without requiring database credentials or network access3. By coupling NVIDIA Nemotron’s reasoning capabilities with Deedglass’s pre-execution gates and post-execution verification, teams can deploy autonomous database agents with confidence.

For similar governance patterns across other orchestration tools, see LlamaIndex agent approvals, OpenAI Agents SDK approvals, and Postgres MCP server read-only bypass analysis; the human-in-the-loop approval entry details the protocol design. To see what the agents configured on your machine can change, paste the config into the check page or run npx deedglass scan (how the grade works); to try approval rules in your browser, open the playground.

Written with AI assistance and checked against our claims register.

The takeaway

Nemotron agents reason over data with MCP tools; Deedglass enforces SQLguard policies before queries run and verifies actual PostgreSQL row deltas.

Read nextHow to govern LlamaIndex database agent tool calls Try it: install in 7 s

Related on this site

More posts

Sources

  1. 1Model Context Protocol Tools Specification · modelcontextprotocol.io · checked 30 October 2026
  2. 2NVIDIA NIM: Nemotron 3 Ultra Model Catalog · build.nvidia.com · checked 30 October 2026
  3. 3Deedglass docs: Model Context Protocol gateway · docs.deedglass.com · checked 30 October 2026

Published 30 October 2026, sources last checked 30 October 2026. If something here is out of date, write to hello@deedglass.com.

Try it on your own setup

npx deedglass scan

Grades only your own setup. Nothing is uploaded.

Pricing