NVIDIANVIDIA-Certified Professional: Agentic AI2026-109.1 Design and enforce system security and audit trails.
Constrain tool authority and isolate credentials
Completed by the knowledge check
Learning objective
Apply least privilege, tool allowlists, and credential isolation.
Core idea
An agent’s effective authority depends on three different decisions: which tools it can select, which operations the downstream identity can perform, and which credentials the execution environment exposes. Constrain all three. A short tool list does not make a powerful shared credential safe, and a read-only credential does not make its disclosure acceptable.
OWASP’s excessive-agency guidance distinguishes excessive functionality, permissions, and autonomy. Apply that distinction to the executable path, rather than asking a model to respect a policy paragraph. A prompt can describe desired behavior; the tool service and resource server must enforce permitted behavior on each request.
See 1.2.2 for ReAct loop controls and 9.1.2 for the execution boundary. Here the decision is which authority reaches each tool invocation, including when the model proposes an otherwise valid call with an unauthorized target.
How it works
Limit the operations the agent can select
In NeMo Agent Toolkit, workflow._type: react_agent selects the ReAct agent, and workflow.tool_names lists the configured functions or function groups it can call. The agent requires the nvidia-nat[langchain] plugin. Define narrowly scoped tools under functions, then expose the subset needed by that workflow. Listing a broad function group deserves the same security review as listing its members individually.
For a group, function_groups.<name>.include: [...] is an allowlist: only listed functions become agent tools. exclude: [...] is a denylist; the two keys are mutually exclusive, and omitting both exposes all available functions in the group as agent tools. These filters control agent exposure; functions remain programmatically accessible through the group object.
For example, an application-defined lookup_invoice tool is easier to constrain than a general execute_sql tool. The former can accept an invoice identifier and check ownership; the latter exposes query construction and a much larger operation space. Implement these application tools with the ownership checks their names imply.
Treat tool_names as an exposure control. If the permitted tool accepts arbitrary URLs, table names, or shell commands, the list still exposes those capabilities through that one tool. OWASP recommends avoiding open-ended extensions and implementing only the required functionality. Reducing the number of names without reducing their authority changes little.
Enforce permissions at the resource server
Use the downstream system’s permission mechanism for the identity that actually connects. OWASP gives the example of restricting an agent’s database identity to reading the required table. A tool that promises to issue only read queries but connects with a write-capable administrator identity leaves the resource boundary too broad.
For actions on behalf of a person, use that person’s authorized context and minimum required scope. The tool service must derive the caller from verified execution context, then check access to the requested resource. Do not accept a model-generated user or tenant identifier as the authority to cross accounts. Input validation establishes argument shape; authorization establishes whether this caller can act on this object.
NeMo Agent Toolkit’s identity resolver assigns user_id values to incoming credentials, but its documentation explicitly distinguishes resolution from authentication. JWTs are decoded with verify_signature=False. Put a validating reverse proxy or authentication middleware before the toolkit, as NVIDIA directs. Otherwise, an attacker can supply a credential claiming another identity and reach that user’s workflow state. A deterministic identifier is useful only after the identity assertion has been verified.
Keep secrets in the trusted tool path
The toolkit’s Authentication Provider API defines named providers under authentication. Its oauth2_auth_code_flow provider includes scopes, client_id, and client_secret; the documentation demonstrates environment substitution with ${NAT_OAUTH_CLIENT_SECRET}. A tool configuration uses AuthenticationRef to identify its provider, and the implementation retrieves it through the workflow builder. Keep the credential in this runtime integration rather than placing it in tool arguments, prompts, or returned observations.
The model proposes the call and its tool arguments, but the caller comes from verified execution context and the credential stays in the trusted tool path.
Environment substitution avoids embedding the secret value in the YAML file. It does not establish isolation from arbitrary code running in the same credential-bearing process. If the agent can execute generated code, separate that execution from the trusted integration that possesses credentials; see 9.1.2. Credential isolation is a process and access decision as well as a configuration decision.
For a sandboxed workload, OpenShell providers isolate credentials through profile endpoint binding and proxy substitution. Keep real secrets in provider records; the agent receives an opaque placeholder that resolves only for hosts, ports, and paths authorized by the provider profile. Avoid placing real credentials in workload environment configuration. tls: skip disables placeholder rewriting for that endpoint.
The Authentication Provider API is experimental. Its deployment support also differs by method: API keys work across configurations, while the documented OAuth consent UI has full frontend support in WebSocket mode. Choose an interaction path that can actually complete the required consent flow. A failed redirect is an integration defect to repair, not a reason to substitute an administrator key.
Key distinctions and trade-offs
Use these controls together because each constrains a different part of the call:
| Control | Deciding condition | Mechanism | Cost and boundary |
|---|---|---|---|
| Tool allowlist | The workflow needs only specific operations | workflow.tool_names, narrow functions, and group include/exclude | More tool interfaces to maintain; arguments still require authorization |
| Least privilege | A permitted tool can reach more data or operations than the task needs | Downstream grants and OAuth scopes | More identities and permission policies; the resource server owns enforcement |
| Credential isolation | Model-visible data or generated code could disclose a secret | Named authentication provider and AuthenticationRef; OpenShell provider records and endpoint-bound proxy substitution | More integration boundaries; environment variables alone do not isolate hostile code |
| Verified caller identity | Per-user state or delegated resource access depends on the person | Authenticating reverse proxy or middleware before identity resolution | Authentication latency and operational ownership; user_id alone is insufficient |
Per-user delegation improves attribution and limits cross-user access, but adds consent and token lifecycle work. A service identity can suit a genuinely shared read-only catalog. Choose it because the task has shared authority, not because sharing an unrestricted key avoids integration work.
Architecture / decision scenario
A wholesale distributor deploys a customer invoice assistant for 240 buyers. Its service target is a two-second response, and every buyer may read only their own invoices. The prototype exposes one SQL tool connected as a billing administrator. The team proposes retaining it and adding a prompt that forbids writes to preserve delivery speed.
The security owner rejects that design: one tool name still reaches every buyer and can modify billing data. The application team instead exposes an application-defined lookup_invoice through tool_names, binds the verified buyer context outside model arguments, and uses a downstream identity whose grants cannot modify invoices. The tool rejects another buyer’s invoice even when its identifier is syntactically valid.
For delegated access, the integration owner configures the named OAuth provider with only the required scopes and a consent-capable frontend. The gateway owner validates caller tokens before toolkit identity resolution. Secrets remain in the trusted tool integration and never enter the model’s observations. The performance owner measures this path against two seconds; missing that target leads to optimizing the authorized lookup, rather than broadening credentials.
Before release, attempt an unlisted tool, another buyer’s invoice, a forged caller token, and credential disclosure through tool output. Each test exercises a different boundary. A successful refusal to one prompt-injection attempt cannot substitute for those checks.
Common exam traps
- One tool means little authority: A general SQL or shell tool can expose more authority than several narrow tools.
- Identity resolution authenticates the caller: Toolkit JWT decoding does not verify the signature; upstream authentication is required.
- Environment substitution isolates the secret: It keeps a literal out of YAML, but code in the credential-bearing process can still threaten it.
- A denied call needs a stronger fallback key: Repair missing scope or incorrect identity through the owning integration; do not bypass a valid denial.
What to remember
Constrain tool selection with tool_names, enforce resource access through downstream permissions, and keep credentials in a trusted integration outside model-visible data. Verify the caller before relying on user_id. Review the toolkit authentication API’s experimental status and consent support before selecting the deployment path.
Knowledge check
A procurement workflow lists the function group erp_tools in workflow.tool_names. The group defines 14 functions, and this workflow needs only get_po_status and list_open_pos. The platform team adds functions to the group every quarter, and a new function must not reach this agent until someone has reviewed it. Which group configuration meets the requirement?
exclude listing the 12 functions the workflow does not needinclude listing the two functions the workflow needsinclude listing the two needed functions and exclude listing the restinclude is an allowlist: only the listed functions become agent tools, so a function added later stays unexposed until someone adds it to the list. exclude is a denylist, so anything not on it, including next quarter’s additions, becomes a tool; with no filter every available function is exposed whatever the prompt says, and the two keys are mutually exclusive.A customer invoice assistant exposes only lookup_invoice(invoice_id), which connects through a database identity that can read invoices but not modify them. In testing, a buyer asks for an invoice number that belongs to another buyer; the identifier is syntactically valid, and the tool returns that invoice. Which change closes the gap?
invoice_id against the invoice-number format before the query runsbuyer_id argument that the model fills from the conversation for the tool to checkbuyer_id is just another argument the model can get wrong, a prompt rule is not enforcement, and the read-only grant limits writes, not which buyer’s rows are read.A NeMo Agent Toolkit server resolves user_id from the bearer JSON Web Token (JWT) on each request and keys per-user conversation history by it. A penetration tester, without the signing key, edits a token’s subject claim to another employee’s identifier and receives that employee’s history. What should the team add?
user_id valueuser_id ; it decodes JWTs with verify_signature=False and does not authenticate anyone, so NVIDIA directs placing signature validation upstream. Hashing a forged claim yields a stable identifier for the forged identity, per-user state is keyed by that same unverified value, and an expiry claim in an unverified token can be forged as easily as the subject.An analysis agent executes model-generated Python inside the same process as a reporting tool. The tool’s OAuth client secret reaches that process through ${NAT_OAUTH_CLIENT_SECRET} substitution in the workflow YAML, and the security review requires that generated code cannot read the secret. What addresses the requirement?
.env file instead of substitution.env file, keeps the literal value out of the YAML, but code running in the process that holds the secret can still reach it; isolation here is a process boundary. A prompt rule asks the model to behave rather than constraining the code, and rotation shortens how long a stolen secret is useful without preventing the read.Analysts reach a NeMo Agent Toolkit workflow through its front-end UI against nat serve. Each analyst must authorize read-only CRM access through the oauth2_auth_code_flow provider, but the UI talks to the server over plain HTTP requests and the consent prompt never completes. Which change keeps per-analyst, read-only access?