NVIDIANVIDIA-Certified Professional: Agentic AI2026-109.1 Design and enforce system security and audit trails.
Make action and approval records verifiable
Completed by the knowledge check
Learning objective
Record tamper-evident audit trails of agent actions and approval decisions.
Core idea
An audit trail must let an independent reviewer reconstruct who authorized an action, what was attempted, and what actually happened. Tamper evidence adds a separate property: the reviewer can detect unauthorized changes to the retained records.
Separate event production, durable acceptance, retention, and verification. NVIDIA OpenShell produces structured security events, but its OCSF export documentation explicitly describes collection as best-effort. Build the application’s audit requirements around that boundary instead of treating a JSON export switch as a complete audit system.
See 8.2.1 for log and trace correlation and 10.4.1 for deciding which actions require human approval. Here the concern is retaining an attributable, verifiable record of the decision and its resulting action, including denials, failures, and uncertain outcomes.
How it works
Record the decision and the consequence separately
For an agent action, include an event identifier, authenticated actor, tenant, workflow run, action identifier, tool and target, policy revision, decision, time, and execution outcome. Store approved argument digests or a protected argument reference where raw content would expose sensitive information. Define these fields in your application audit schema; preserve native OCSF identifiers separately.
An approval record needs its own identifier and verified reviewer identity, plus the exact action and argument digest approved, decision, decision time, and applicable policy revision. The action record references that approval identifier. An approval to send one document to one recipient must not become authorization to send changed content elsewhere. Record denied and expired decisions too, so a missing execution is distinguishable from a missing request.
Record at least proposal, authorization outcome, execution attempt, and terminal result as distinct events sharing the action identifier. A successful authorization is not proof that the write occurred. If a tool times out after sending a request, retain an uncertain outcome and reconcile it with the downstream system’s operation identifier. Do not manufacture a successful completion event merely because the agent narrates success.
OWASP places authorization in downstream systems and recommends approval for high-impact actions. On the toolkit side, implement an audit emitter as function middleware: define it under middleware, then attach it through functions.<name>.middleware: [...] or a function group’s middleware list. Middleware wraps ainvoke or astream with preprocessing, call_next, and postprocessing; emit the proposal and attempt before dispatch and the returned result afterward. The resource server supplies the authoritative operation outcome. Middleware runs inside the agent process, so keep the audit receiver and integrity key outside that process’s authority.
The middleware emits the proposal and the attempt before dispatch and the returned result afterward.
Collect enforcement events without confusing their identities
For OpenShell sandbox supervisors, enable ocsf_json_enabled, globally or for a selected sandbox. NVIDIA documents openshell settings set --global --key ocsf_json_enabled --value true. Supervisors emit complete JSON records after the OCSF-JSON marker on stderr; collect those lines rather than ingesting both the shorthand and JSON copies as separate events.
Use native metadata.uid to deduplicate the same event across serialization or collection paths. Use container.uid to associate an event with its sandbox. Retain the native record alongside the application-owned action association rather than overwriting its identifiers with a trace ID.
Gateway-origin events have a separate output configured under [openshell.gateway.ocsf_log] in gateway.toml. Enabling sandbox JSON export does not enable that sink. The gateway JSONL sink also does not archive full supervisor records pushed through the gateway log stream. Collect the sources needed for your threat model, including gateway policy activity and supervisor enforcement outcomes.
OpenShell documents a bounded console queue of 1,024 complete lines shared by diagnostics, shorthand, and JSON. It drops new lines when full instead of blocking enforcement. Supervisor JSONL files are also temporary local retention: Docker and Podman use tmpfs, and Kubernetes uses the supervisor Pod’s emptyDir. Arrange external collection before rotation or teardown. More verbose diagnostic logging can compete for the same bounded console capacity.
Protect records after durable acceptance
Place the audit receiver and integrity keys outside the agent’s administrative authority. Give the agent a path to submit events without permission to rewrite retained history. Retain original bytes or a versioned deterministic encoding so a verifier can reproduce exactly what was authenticated.
One application design is a keyed chain: the receiver assigns a per-stream sequence and computes a hash-based message authentication code (HMAC) over a length-delimited encoding of the stream identity, sequence, prior authenticator, and event bytes. Python’s hmac.new(key, msg, digestmod="sha256") supplies the keyed authenticator; hmac.compare_digest() supports verification without ordinary equality’s timing exposure. The receiver, rather than the agent, owns the key and assigns ordering.
Implement chain verification in the external receiver. Keep independently protected checkpoints containing the stream identity, accepted sequence, and authenticator. A chain stored only beside the records cannot reveal deletion of its entire suffix without an external expected endpoint. Checkpoints and receiver acknowledgments establish what was accepted; they do not prove that a compromised producer emitted every required event.
HMAC provides shared-key integrity, not public non-repudiation: anyone holding the key can create authenticators. Restrict key access, record key versions for verification after rotation, and separate archive administration from integrity-key administration. Corrections should append an event referring to the original rather than rewriting the authenticated record.
Key distinctions and trade-offs
Choose each mechanism for the property it actually supplies:
| Property | Mechanism | What it establishes | Cost or limitation |
|---|---|---|---|
| Correlation | Action and approval identifiers joined to native event IDs | Which records describe the same proposed operation | Does not authenticate the records |
| Durability | External receiver acknowledgment and retained archive | The receiver accepted the specified event | Adds latency and storage; producer omissions remain possible |
| Tamper evidence | Keyed chain, sequence checks, and independently protected checkpoints | Changes or gaps relative to authenticated accepted history | Requires key custody and verification; does not prevent every deletion |
| Completeness monitoring | Expected lifecycle transitions and receiver progress checks | Missing expected records or stalled collection | Requires reconciliation; best-effort source logs can still lose events |
Architecture / decision scenario
A legal-services meeting assistant prepares document-sharing actions. The organization requires a reviewer for external recipients and retains each action history for a company-defined 180 days. The application handles 60 actions per second; a small share target external recipients and wait for review. Four lifecycle records per action produce 240 records per second before sandbox security events. Its action deadline is three seconds.
The team proposes relying on container logs and a nightly file checksum. The security owner rejects that option: local files can disappear with the workload, best-effort queues can drop records, and a checksum stored with the same mutable file offers no independently trusted endpoint.
The application owner instead sends the proposed action and approval outcome to an external audit receiver. Before the send tool executes, it requires durable acknowledgment of the exact approved action digest. An unavailable receiver leaves the external send pending under this organization’s policy; the three-second deadline returns a deferred result. The receiver maintains the keyed sequence chain and independent checkpoints, and the archive owner enforces the chosen retention period.
The platform owner collects OpenShell supervisor JSON and gateway events separately. A collector load test checks 240 application records per second plus measured security-event volume, then forces a collector outage and workload teardown. Recovery must distinguish accepted records from missing ones. A separate verification exercise changes a record, removes an interior record, and truncates a suffix; the verifier must detect each relative to the protected checkpoints. The team accepts added acknowledgment latency because external sharing without reconstructable authorization violates its requirement.
Common exam traps
- A trace is an audit trail: Correlation does not establish durable capture or integrity.
- Structured JSON is tamper-evident: Integrity requires protected verification material outside the record writer’s authority.
- Approval implies completion: Preserve authorization, attempt, and actual result separately.
- A hash chain proves completeness: It needs a trusted endpoint for suffix deletion, and cannot prove producer honesty.
- Enabling OCSF guarantees capture: OpenShell explicitly documents best-effort delivery and bounded queues.
What to remember
Join exact approvals to action attempts and outcomes, collect enforcement events durably, and verify retained history using independently protected integrity material. Account for lost events as well as modified ones. Audit policy must define what happens when durable capture fails, because a best-effort log stream cannot make that decision for the application.
Knowledge check
A reviewer approves an agent’s request to share contract-v3.pdf with one external counsel address. Before the send executes, the agent revises the document. An investigator must later be able to show whether the executed send matched what was approved. Which part of the approval record makes that comparison possible?
An agent’s create_refund tool sends a request to the payment service and then times out before any response arrives. The agent tells the user that the refund was issued. What should the audit trail record as this action’s outcome?
A platform team enables ocsf_json_enabled globally and collects every OpenShell supervisor’s OCSF-JSON lines into the audit archive. An investigator then finds no record of gateway-origin events, such as gateway policy activity. What must the team add?
ocsf_json_enabled setting applied to each running sandbox[openshell.gateway.ocsf_log] sink configured in gateway.tomlgateway.toml ; enabling supervisor JSON export does not enable it, and the supervisor stream carries the sandbox’s events, not the gateway’s. A per-sandbox setting duplicates the global one, more diagnostic logging competes for the supervisor’s bounded console queue, and the shorthand lines are a projection of the same supervisor events.An external-sharing assistant must retain the exact approved action before sending a document. Its only collector currently follows OpenShell supervisor JSON logs, whose console queue drops new lines when full. Which design meets the requirement even when that queue fills?
An audit receiver keeps a keyed HMAC chain over each event stream, stored in the same archive as the records. An administrator with archive access deletes the newest 500 records, and the verifier recomputes the remaining chain without error. What would have let verification detect the deletion?
hmac.compare_digest() instead of ordinary equality during verificationcompare_digest() removes a timing side channel without changing what is detected.References
- NVIDIA, OCSF JSON Export
- OWASP, LLM06 Excessive Agency
- Python Software Foundation, hmac — Keyed-Hashing for Message Authentication
- NVIDIA, Middleware