Using NVIDIA Nemotron 3 Ultra to check AI agent blast radius before execution

The challenge of agent blast radius

When a developer or enterprise deploys an autonomous AI agent, whether through Claude Code, Cursor, LangGraph, or custom agent frameworks, the primary operational risk is blast radius.

A human engineer reviewing a proposed database update or API payload can quickly assess intent:

• Is this query scoping its target to one patient ID or will it overwrite every row?
• Does this tool call require administrative permissions?
• Could this parameterized input contain a hidden prompt injection attack?

Autonomous agents moving at high speed do not naturally pause to assess their own blast radius. Traditional prompt firewalls evaluate only input strings, failing to recognize that a seemingly harmless query like UPDATE accounts SET balance = 0 lacks a WHERE filter and will wipe an entire table.⁴ Similarly, an agent attempting to reschedule a single medical appointment might issue a bulk cancellation across an entire provider clinic if its relational filter is slightly malformed.

To solve this, we brought live reasoning into our change check tool on deedglass.com using NVIDIA Nemotron 3 Ultra.²

Why reasoning models matter for agent safety

Evaluating agent blast radius requires multi-step deductive reasoning:

1. Syntactic parsing: Parsing the language (whether raw SQL, FHIR JSON, MCP tool schemas, or natural language prompts).
2. Impact projection: Tracing the causal blast radius (how many records could change, which tables or microservices are affected, and what cascade triggers might fire).
3. Double-check identification: Isolating the three specific facts an operational reviewer should verify before clicking approve.
4. Policy synthesis: Generating a Common Expression Language (CEL) policy rule ready to paste directly into Deedglass Console.

Smaller language models frequently hallucinate or generate invalid CEL syntax when asked to perform all four tasks in a single pass. NVIDIA Nemotron 3 Ultra (nvidia/nemotron-3-ultra-550b-a55b), running on NVIDIA NIM microservices, provides the deep reasoning capacity required to accurately categorize intent, detect subtle SQL privilege escalations, and format policy structures without deviation.¹ The model excels at identifying subtle syntactic traps, such as queries containing embedded comment characters, SQL termination semi-colons, or unescaped parameter values intended to alter query execution graphs.

How the Nemotron check pipeline works

When a developer pastes an intended action into deedglass.com/check/ai, the request flows through a streamlined, low-latency pipeline:

Code What the screen or file shows, copied as is.

[ Browser / Client ]
        │
        ▼ (POST /api/check with text & audience)
[ Cloudflare Edge Worker ] ──► (Validates CSRF, limits length to 8,000 chars)
        │
        ▼ (Zero-Retention NIM API call)
[ NVIDIA Nemotron 3 Ultra ] ──► (Deep reasoning across blast radius & CEL grammar)
        │
        ▼ (Structured JSON Response)
[ Interactive Browser UI ] ──► (Displays Risk Tier, Record Scope & CEL Rule)

The system prompts Nemotron with a strict JSON schema and Deedglass’s policy grammar. In under three seconds, the model evaluates the proposed action and returns:

• What changes: A clear summary tailored to the chosen audience (Clinician, Health IT, or Developer).
• Scope estimate: The estimated number of affected records and the syntactic reason why.
• Risk classification: Ranked into low, check_first, or high.
• Double-check checklist: Three concrete verification items for a human approver.
• Ready-to-use rule: A validated deedglass: policy/v1 block.

Because the system categorizes by audience, clinicians receive plain-language summaries explaining which appointment or medication is moving, while developers and health IT specialists receive precise relational breakdown details and CEL expression code.

Synthesizing CEL policy rules

One of the most valuable aspects of the check is that it does not merely offer advice; it writes the operational rule required to enforce safety.³

For example, when given a dangerous statement attempting to grant privileges:

Code A database command in SQL. The text around it says what it does.

GRANT ALL PRIVILEGES ON DATABASE clinical_db TO app_agent;

Nemotron flags the risk as high and immediately outputs the corresponding Deedglass rule:

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

deedglass: policy/v1
name: block-privilege-grants
description: "Block autonomous privilege escalation. All database role grants require manual admin approval."

defaults:
  decision: deny
  reason: "No rule allows autonomous privilege grants."

rules:
  - id: block-grant-statements
    match: { tool: "postgres.execute", connector_type: postgres }
    when: "sql.kind == 'grant' || sql.command.matches('(?i)GRANT|ALTER\\s+ROLE')"
    decision: require_approval
    reason: "Privilege escalation detected; an administrator must approve any change to database roles."
    approval: { approvers: [role:admin], required: 2, expires_in: 15m }

This bridges the gap between understanding a vulnerability and securing it in production. An engineer can copy the YAML block directly into their repository, commit it, and have Deedglass enforce the rule across every development and staging environment.

Zero-retention privacy architecture

When security teams evaluate developer tools, data privacy is non-negotiable.

The Deedglass AI change check enforces strict privacy protections:

1. Synthetic data first: The user interface encourages users to paste made-up IDs and sample queries rather than production patient or customer data.
2. Stateless edge execution: The Cloudflare Pages worker does not store request text in any database or disk log.
3. Zero-retention inference: Requests sent to NVIDIA’s enterprise NIM endpoints operate under zero-data-retention agreements; prompts are never retained or used for model retraining.
4. Verifiable offline: Once an organization adopts Deedglass, all enforcement rules and cryptographic record verification run locally on their own infrastructure without external network dependencies.²

Comparing preview inference with real state checks

It is critical to distinguish between an AI preview check and a cryptographic state check.

The AI change check on deedglass.com provides an intelligent preview of what a query or tool call appears to do based on its textual representation. It calculates risk and helps teams draft policies before deployment. However, once an agent connects to a real database in production, software must verify what the database actually committed.

In production, Deedglass does not guess blast radius with an LLM. It connects directly to PostgreSQL’s replication decoding stream (pgoutput), measuring the exact bytes and row IDs modified during the transaction. An AI preview informs policy authoring; cryptographic witnesses enforce runtime reality.

Testing it live and evaluating your setup

You can test the live change check right now at deedglass.com/check/ai with no sign-up or installation required.

To explore how these policies intercept real database writes and hold actions for human approval in a realistic sandbox, open the browser playground at /play. You can interact with a live PostgreSQL instance running in WebAssembly, see rules trigger in real time, and inspect sealed audit records.

To audit the permissions of your existing development environment, coding assistants, or local database connections, run the free scanner:

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

npx deedglass scan

The scan runs entirely on your local machine, inspects agent tools and permission boundaries, and assigns a security score. You can read what the security score means to identify permission gaps before autonomous agents interact with production data.

Written with AI assistance and checked against our claims register.