Connecting NVIDIA agents to a system of record.

A read-only architecture for bringing NeMo Helix identities, NIM services, and OpenShell evidence into an accountable business view.

CatProof editorial · October 30, 2026

CatProof has joined NVIDIA Inception. Our first technical question is practical: how should an agent built in NVIDIA’s ecosystem connect to a durable business record?

A platform identity helps locate an agent definition. A model endpoint tells an application where to send inference requests. A sandbox constrains execution. An accountable business record needs to connect those facts to a named owner, a purpose, and a review history.

Start with registered agents in NeMo Helix

NVIDIA documents that registering an agent in NeMo Helix creates an agent entity within a workspace. Registration can represent code, a container image, a remote endpoint, or an agent associated with traces. Registration alone therefore does not establish that an agent is currently running. See NVIDIA’s agent registration guide.

The first connector would read one explicitly configured workspace. The documented Entity Store collection route gives us a starting point:

GET /apis/entities/v2/workspaces/{workspace}/entities/{entity_type}

# Proposed discovery scope:
entity_type = agent

The Entity Store reference defines pagination and sorting. A prototype must verify the deployed version’s response schema, permissions, and identity behavior before we publish a supported connector contract.

Keep three kinds of identity separate

Our proposed mapping separates an agent’s business identity, its source identity, and the infrastructure it uses. A canonical record can have multiple explicitly linked source identities. A model service or sandbox remains a related asset.

Consider a fictional invoice-review agent registered separately in development and production. Similar names are a reason to investigate, not enough to merge them. The team might link both definitions to one business record, or keep them separate because their purpose and accountability differ.

A source observation could be normalized into the following envelope. These are proposed CatProof fields, not a NVIDIA API response:

{
  "source_type": "nvidia_nemo_helix",
  "workspace": "finance-production",
  "source_id": "<stable identity verified from source>",
  "source_name": "invoice-review",
  "observed_at": "2026-10-30T12:00:00Z",
  "canonical_agent_id": null
}

The null canonical ID represents an unresolved association. A registration principal or deployment service account is technical evidence; it does not automatically become the accountable business owner. Linking, ownership assignment, and review are separate decisions.

Treat NIM endpoints as dependencies

For NIM’s documented LLM and VLM serving interface, management reads include GET /v1/metadata, GET /v1/version, and GET /v1/health/ready. Readiness indicates that the model is available for inference at that instant. It does not establish the health or approval of every agent that uses it. Endpoint details must be checked against the deployed NIM version. NVIDIA’s NIM API reference.

The proposed CatProof representation is a model-service asset with separately timestamped metadata and readiness evidence. An agent-to-service link requires an explicit configuration reference or recorded association. Multiple agents can use one service without turning that service into another agent.

The inventory connector would not send prompts, generate completions, or run a workload to test discovery. Authentication for a deployed service must be verified independently; a credential used to download a container is not assumed to authorize its serving endpoint.

Use OpenShell evidence with its collection limits

OpenShell documents structured OCSF JSON event exports for machine consumption. Gateway-origin and sandbox-origin output have different collection paths, and collection is best-effort. Missing events cannot establish that nothing happened. NVIDIA’s OCSF export reference.

We would begin with selected sandbox identifiers, policy references, and relevant event metadata, with capture times and coverage visible. A sandbox can host changing workloads, so sandbox identity alone must not establish a permanent business-agent identity.

OpenShell would continue to enforce its configured runtime controls. CatProof’s proposed role is to associate that evidence with ownership and review decisions. Reading an event stream does not make CatProof the enforcement point or establish compliance.

Design synchronization around incomplete evidence

The difficult part of discovery is deciding what a partial scan means. Helix’s Entity Store documents offset pagination rather than a snapshot: concurrent writes can cause repeated or skipped rows. Sorting and deduplication help, but cannot make that scan transactional. Pagination behavior.

Our proposed synchronization rules are:

• Stage before applying. Validate scope, schemas, page bounds, and identities before changing the saved source inventory.
• Preserve evidence on failure. Authentication errors, malformed pages, and request limits should leave the previous evidence available, with a failed-refresh indicator.
• Make absence conservative. Do not retire a canonical business record because one scan misses its source identity. Absence handling needs a validated reconciliation policy; a paginated scan alone is insufficient.
• Keep decisions durable. New source metadata must not overwrite a business owner, lifecycle decision, or review history.

A useful prototype would test interrupted scans, duplicates, renamed records, concurrent changes, and credentials that can see only part of a workspace. Fixture success establishes parser behavior. An authorized deployment is still needed to validate actual permissions and completeness.

Collect inside private networks

Hosted CatProof currently restricts connector destinations to public HTTPS endpoints. Many NVIDIA deployments will sit inside a customer network. Our design would preserve that boundary through a customer-side collector or discovery bridge, or a self-hosted CatProof deployment. It would not open an internal control plane to the internet just to make discovery convenient.

The collector should send an allowlisted metadata envelope. Prompts, conversations, credentials, and arbitrary source configuration are outside the initial scope. Workspace access must be explicitly authorized; a token’s API scopes and its workspace role are separate checks in Helix’s authentication model.

Build against the current NVIDIA stack

NVIDIA’s documentation states that NeMo Agent Toolkit was deprecated in October 2026, with end of life planned for the end of 2026. Its migration guide points to NeMo Relay for observability and middleware, NeMo Fabric for agent execution interfaces, and NeMo Helix for evaluation, optimization, and hardening. Read NVIDIA’s migration guide.

That makes a workspace-scoped Helix inventory reader our first candidate. NIM dependency mapping and selected OpenShell evidence would follow after independent validation. Older toolkit configurations may be useful compatibility inputs, but should not define a new integration’s long-term contract.

What the first proof should demonstrate

A small, reproducible example is the next milestone: discover one registered Helix agent, preserve its source identity, associate it with a business record, and refresh the source without changing the recorded owner. Then introduce a failed or incomplete sync and show that existing evidence and decisions survive.

That would establish a foundation for richer relationships. It would not establish organization-wide discovery, runtime policy enforcement, or production readiness. We will distinguish documented API support, fixture coverage, and live validation as the work progresses.

For CatProof’s current capabilities and limitations, see the connector coverage page and system-of-record guide. Teams operating a NeMo Helix environment can contact us about a discovery pilot.