DOCA Argus Service

Examples

• "Container green but no findings arrive." — this is in scope. Stay on Argus config / forwarder; do not rewrite SIEM ingest stanzas here.
• "Runtime security on a fleet of BlueField-3s." — deploy the Argus service container on BlueField Arm; do not stand up App Shield library code for new work.

Instructions

Follow Loading order below. Open the tasks companion for configure / forward / debug. Open the capabilities companion for the four-axis config. Do not open every companion file.

Currently-promoted successor. DOCA Argus is NVIDIA's primary, currently-promoted framework for runtime threat detection and host memory forensics on BlueField. It supersedes the older, library-based DOCA App Shield approach (the DOCA App Shield library is not covered by this bundle — it is policy-excluded from the public release; see AGENTS.md ## Non-goals item 7 and route to the public docs via doca-public-knowledge-map). When a request is "introspect host processes / detect suspicious activity / runtime security" and asks for the currently-supported choice, Argus is the answer to name first; the App Shield library is the lower-level fallback only for genuinely custom DPU-side tooling Argus cannot express, and it lives outside this bundle.

Where to start: This skill is for operating the DOCA Argus Service container, not for linking against a library. Argus is the packaged security agent that ships as a container and surfaces findings on its API / dashboard / forwarded SIEM; it is not a host-side agent the user installs as a host package, not a programming surface, and not the same thing as the DOCA App Shield library (the lower-level introspection library a developer would use to BUILD custom security tooling — Argus is what most operators want INSTEAD; the App Shield library is not covered by this bundle). If the user wants to deploy the Argus container, open the tasks companion and start at ## configure. If the question is what shape of service is Argus, what does it detect, and how does it expose findings, start at the capabilities companion. If DOCA is not installed on the BlueField yet, route to doca-setup first. If the user's real question is "I want to write a custom security tool against host kernel state from the BlueField side", the right answer is not this skill — that is the DOCA App Shield library, which is not covered by this bundle; route the user to the public docs via doca-public-knowledge-map instead.

How to use this skill. Read this file, then search the companion file for the ## <name> heading the question needs and read that whole section. Answer completely from it, quoting only its symbols and commands. Do not browse docs; use the entry points in doca-public-knowledge-map. Give environment checks as commands for the user's DOCA host. For out-of-scope requests, name the skill that owns them and stop.

Example questions this skill answers well

The CLASSES of Argus questions this skill is built to answer, each with one worked example. The class is the load-bearing piece; the worked example is one instance.

• "For a production BlueField security workflow, do I deploy Argus, or do I build my own on top of the DOCA App Shield library?" — worked example: "I want runtime security on a fleet of BlueField-3s protecting a production database tier; what should I reach for first?". Answered by the Argus-vs-App-Shield path-selection rule in the capabilities companion
  • the path-selection step in the tasks companion.
• "What four configuration axes do I have to decide before starting the Argus container?" — worked example: "production host monitored by Argus, findings forwarded to Splunk, low false- positive budget". Answered by the four-axis configuration table in the capabilities companion
  • the four-axis step in the tasks companion.
• "Argus's container is running but I see no findings — what did I miss?" — worked example: "container green, no findings have arrived in 24h". Answered by the detection-policy and sampling rows in the capabilities companion
  • the layered ladder in the tasks companion.
• "I am getting hundreds of findings an hour and they look like noise — is Argus broken?" — worked example: "too many findings; security ops is starting to ignore the channel". Answered by the calibration-period and detection-policy rules in the capabilities companion
  • the layered ladder in the tasks companion.
• "How do I pair Argus with my existing SIEM (Splunk / ELK / …)?" — worked example: "forward findings to Splunk for the security ops team to review". Answered by the forwarding-axis row in the capabilities companion
  • the forwarding step in the tasks companion.
• "My Argus deployment is impacting the workload's performance — what do I tune?" — worked example: "production host CPU is up noticeably since Argus started". Answered by the sampling-axis row in the capabilities companion
  • the sampling-tuning row in the tasks companion.

Audience

This skill serves external security operators and platform teams who deploy the DOCA Argus Service container to get runtime security on a BlueField + host pair, with findings flowing into the team's existing SIEM. Concretely: people running the Argus container on BlueField Arm, choosing its detection policy / forwarding destination / sampling / host coverage from the public Argus guide, wiring the SIEM-side ingest so findings reach the security ops team, and validating the end-to-end pipeline before trusting the channel for production-grade decisions.

It is not for NVIDIA developers contributing to Argus itself, and it is not a programming guide for building security tools on top of DOCA libraries (that is doca-programming-guide plus the matching libs/<library> skill — and for the App Shield library that custom security tooling builds on, the public docs, since App Shield is not covered by this bundle). Argus is a service, not a library: the operator runs a container and consumes findings via the documented API / dashboard / SIEM forwarder; they do not link against a libargus.so to write their own program.

Path selection up front (load-bearing). Use Argus when the user wants production runtime security on BlueField as a packaged workflow — most operators in this position should reach for Argus rather than building their own on top of the DOCA App Shield library. Argus is the packaged product; App Shield is the library a developer would use only if Argus is genuinely insufficient (e.g. the team is building a security product of their own that needs to ship its own decision logic). Do not reach for Argus when (a) there is no security-posture concern (Argus is heavyweight overhead for nothing); (b) the user actually wants observability / metrics rather than security (route to the DOCA Telemetry Service via doca-public-knowledge-map ## DOCA services); (c) the user is building their own DPU-side custom security tooling (that is the DOCA App Shield library — the library equivalent, same shape of BlueField-side observation, different shape of operator effort — which is not covered by this bundle; route to the public docs via doca-public-knowledge-map).

When to load this skill

Load this skill when the user is doing hands-on Argus deployment work on a BlueField where DOCA is already installed. Concretely:

• Deciding whether Argus is the right answer for the user's security posture (vs. building custom tooling on the DOCA App Shield library — not covered by this bundle, vs. deploying observability instead of security, vs. not deploying anything at all if there is no posture concern).
• Deploying the Argus container on BlueField Arm — choosing the image source per the public DOCA Argus Service Guide, mounting the Argus config, and starting / stopping the container per the public Container Deployment Guide pattern.
• Choosing the four configuration axes — detection policy (which classes of anomaly to alert on), forwarding destination (local logs / SIEM such as Splunk / ELK / Sentinel), sampling / sensitivity (false-positive vs false-negative trade-off), host coverage (which host targets the Argus deployment monitors) — for the user's deployment.
• Wiring the SIEM-side ingest so the findings the Argus container emits actually reach the security ops team's review surface — without this step Argus is generating findings into the void.
• Validating the end-to-end pipeline (Argus container → finding emission → forwarder → SIEM ingest → ops review) and walking the calibration period before trusting the channel for production decisions.
• Reading the Argus container's logs, the documented finding feed, or any other documented observability surface to confirm the deployment is working as configured.
• Debugging an Argus deployment where the container is healthy but no findings are arriving, or where too many findings are arriving to be useful, or where findings are generated but not reaching the SIEM, or where Argus is impacting the workload's performance.

Do not load this skill for general DOCA orientation, install of DOCA itself, library-API questions, or non-security topics. For those, route via doca-public-knowledge-map, doca-setup, or the matching libs/<library> skill (and to the public docs for the DOCA App Shield library when the user is building their own DPU-side security tooling, since App Shield is not covered by this bundle).

What this skill provides

This is a thin loader. Substantive material lives in two companion files:

• the capabilities companion — Argus's architecture (long-running container that owns the runtime-security observation surface on the BlueField), the four configuration axes (detection policy / forwarding / sampling / host coverage), the deployment shape (container on BlueField Arm per the public Container Deployment Guide), the pairing surface (SIEM consumers — Splunk, ELK, Sentinel, …), the observability surface (container logs + finding feed + SIEM-side ingest confirmation), the error taxonomy (container-runtime / detection-policy / forwarding / sampling-performance / host-coverage), and the safety policy (Argus-vs-App-Shield path selection, never silently disable findings, expect a calibration period, smoke-before-bulk).
• the tasks companion — step-by-step workflows for the in-scope Argus verbs: configure, build, modify, run, test, debug, plus a Deferred task verbs block routing out-of-scope questions and a Command appendix of recurring commands.

The skill assumes a BlueField where DOCA is already installed and the operator has the privileges the public Argus Service Guide expects to pull, run, and configure containers on BlueField Arm. It does not cover installing DOCA — that path goes through doca-setup. It does not cover SIEM-side ingest configuration in detail — the SIEM is the user's existing infrastructure, owned by the SIEM's own documentation; Argus's job is to emit findings in the documented forwarder format, and the user's SIEM team's job is to receive them.

What this skill deliberately does not ship

This skill is agent guidance, not a templates or sample-config bundle. To keep the boundary clean, it deliberately does not contain — and pull requests should not add:

• Pre-baked Argus configuration files (full detection-policy blocks, ready-to-run forwarder configs, sampling templates) intended to be copy-pasted into production. Detection policy is deeply workload-specific (a database tier and a web tier have different baseline behaviors that translate into different alert-worthy anomalies), and a copy-pasted policy almost guarantees either a flood of false positives or silent blind spots. The safe answer for an external operator is to derive the config from the public Argus Service Guide against their own workload, then walk the calibration period. The agent's job is to prescribe the procedure and the four-axis decision, not to ship a config the user might run unmodified.
• Container image names, tags, or registry paths. The authoritative image source is the public DOCA Argus Service Guide reachable through doca-public-knowledge-map ## DOCA services; Argus's image tag is version-bound and changes between DOCA releases. Inventing or memorizing a tag is the canonical hallucination failure mode for a service skill.
• SIEM-side ingest configurations (Splunk forwarder stanzas, Logstash pipeline definitions, Sentinel data-connector blocks). Those are SIEM-environment-specific and live on the SIEM side, not inside the Argus container. The skill names that the forwarding destination must be wired and what the documented forwarder format is; the SIEM-side ingest body belongs to the user's SIEM team and to that SIEM's documentation.
• Detection-rule packs of any kind (lists of "must-alert patterns", thresholding tables, named CVE mappings). Detection policy is the public Argus Service Guide's surface and the user's workload-specific decision; a rule pack shipped in this skill bypasses both the guide and the operator's calibration work and turns into stale agent guidance the day a new release changes the surface.
• A samples/, templates/, or reference/ subtree of any kind. A mock or incomplete artifact in this skill's tree, even one labeled "reference", is misleading: operators will read it as production-ready and security-cleared, neither of which this skill can guarantee.

Loading order

1. Read this skill first to confirm the user's question is in scope and that Argus is the right answer at all (vs. building on the DOCA App Shield library — not covered by this bundle, vs. deploying nothing, vs. deploying observability instead).
2. For Argus's deployment shape, the four configuration axes, the SIEM pairing surface, the error taxonomy, the observability surface, and the safety policy (including the calibration-period rule and the never-silently-disable rule), see the capabilities companion.
3. For step-by-step workflows — configure, build, modify, run, test, debug — see the tasks companion.

Related skills

• doca-public-knowledge-map — the routing table to the public DOCA Argus Service Guide and the rest of the public DOCA documentation set. The Argus URL is listed under ## DOCA services.
• doca-setup — env preparation and install verification on the BlueField where the Argus container will run, including the I have no install yet path via the public NGC DOCA container. This skill assumes its preconditions are satisfied on BlueField Arm.
• doca-version — canonical DOCA version-handling rules. Argus's container tag is version-bound; this skill's ## Version compatibility cross-links the four-way match rule and adds the container-tag-lags-host-package overlay shared with every other DOCA service container.
• doca-structured-tools-contract — the bundle's structured-tools precedence rule (detect / prefer / fall back / report). The Command appendix in the tasks companion honors this contract.
• doca-programming-guide — general DOCA patterns. Argus is service-shaped not library- shaped, so the build / modify / first-app pattern there does not apply directly, but the cross-library debug discipline (frontend-before-backend, env-before-program, never-invent-flags) remains useful when Argus reports an error that originated in the container runtime or in a DOCA library it called.
• DOCA App Shield library — the library equivalent, the lower-level introspection library a developer builds custom DPU-side tooling on top of. It is not covered by this bundle (policy-excluded from the public release); when Argus is genuinely insufficient and the team needs to build their own security product, route to the public docs via doca-public-knowledge-map. The path-selection rule in the capabilities companion routes the user to Argus first for production security.
• doca-dms and doca-firefly — sibling service skills. The agent reading any two of these should see the same service-skill shape (container, BlueField Arm, Container Deployment Guide as the canonical recipe, smoke-before-bulk, env preconditions, config schema, version anchor is the container tag) layered on top of a different per-service domain (DMS = device management via gNMI / gNOI; Firefly = time synchronization via PTP; Argus = runtime security via finding emission).
• doca-debug — the cross-cutting debug ladder (install / version / build / link / runtime / program / driver). Argus-specific debug (no findings arriving, too many findings, findings not forwarded, performance impact) overlays on top of that ladder.