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
A database change, checked and put back
-
1The agent’s change
Change order 42
UPDATE orders … WHERE id = 42
The agent: “1 row updated” -
2What the database really did
301 rows
A hidden trigger changed 300 more
Doesn’t match -
3Put back
301 rows restored
Signed off by a person
Matches
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:
- Unconstrained data mutations: A reasoning step intending to patch a single tenant record can emit an
UPDATEstatement without an exact primary key filter or omit theWHEREclause entirely. - DDL and privilege escalations: Autonomous agents may attempt to solve performance bottlenecks or schema mismatches by executing
CREATE INDEX,ALTER TABLE, orTRUNCATE. - 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.
- 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:
- Deedglass generates an approval request containing the model’s reasoning, the exact SQL statement, and the estimated execution cost.
- An interactive approval card is dispatched to your configured Slack channel, email, or the local Deedglass Console3.
- The human reviewer can inspect the exact statement before clicking Approve or Deny.
- 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.