AI agents can reason, use tools and adapt their actions to the data they encounter. That flexibility changes the security problem: protecting the model alone is not enough. NVIDIA’s guidance places controls across the code, data, identities, services and infrastructure surrounding the agent.
Start with a narrow identity and task boundary
Give each agent a traceable identity and credentials limited to the job it is meant to perform. Define the permitted actions before deployment, including which records it may update, which tools it may call and which destinations it may reach. NVIDIA’s example makes the distinction clear: permission to update a customer record does not automatically grant permission to export that customer’s data.
Requests for additional access must stay outside the agent’s authority. The agent may ask for more permission, but it must not approve its own request. Consequential actions and permission changes should remain subject to human approval. This adds a decision point to the workflow, while preventing a task-specific identity from becoming a general-purpose credential.
Keep runtime controls outside the agent’s reasoning
The execution environment should independently limit files, network destinations and processes. Those restrictions need to hold even when the agent produces an unsafe instruction or follows hostile content. In NVIDIA’s example, a malicious instruction hidden in an attached document leads the agent to attempt an export of customer data to an unauthorized destination.
A network policy should block that transfer at the runtime boundary. The agent should not be able to defeat the restriction by changing its reasoning or requesting a broader route. NVIDIA presents OpenShell as an open-source secure runtime that applies policies beyond the agent’s reach and provides sandboxed execution. The same source cites Cisco DefenseClaw for governance and JFrog for scanning and verifying skills, as well as controlling which skills are available.
Those examples represent different layers of the same model: enforcement must remain independent of the agent. If the component making a decision can also rewrite the control that limits it, the boundary is not a reliable deployment gate.
Treat documents, tools and skills as execution risks
An attached document is not merely context when an agent can use tools. It can contain instructions that redirect the workflow toward data export or another unauthorized action. Keep the agent’s data access, tool access and network access aligned with its declared task, and make every permission explicit.
Apply the same discipline to skills and workflows. Scan and verify skills before they become available to an agent, then restrict the accessible set to what the task requires. This reduces the number of paths an unexpected instruction can activate.
The compromise is less flexibility. A tightly scoped agent may need a human decision or a workflow change when its task genuinely expands. That interruption is preferable to allowing the agent to turn a new instruction into broader authority.
Make important decisions auditable
Protected logs should record the tool call, the authorization decision and the result. Logging only the final outcome leaves out the point at which a boundary was tested or crossed. In the malicious-document scenario described by NVIDIA, the records would show the attempted tool call, the blocked authorization and the resulting action.
Protect the logs from alteration and assign responsibility for reviewing them. The goal is not to collect a transcript for its own sake. The records should answer three operational questions: what the agent tried to do, which policy allowed or blocked it, and what happened afterward.
Test the boundary before production
Before deployment, test whether the agent can obtain credentials outside its scope, send sensitive data to an unauthorized destination, modify permissions or interfere with monitoring. These tests challenge the separation between the agent’s reasoning and the system that contains it.
- Attempt to obtain an out-of-scope credential and verify that the request is denied or routed for human approval.
- Provide a path toward an unauthorized data destination and verify that the network policy blocks the transfer.
- Attempt a permission change and confirm that the agent cannot approve or apply it by itself.
- Attempt to alter or bypass monitoring and confirm that protected logs still capture the call, decision and result.
Repeat these tests after major changes to the model, tools or workflows. NVIDIA also calls for a named owner who decides whether the agent can enter production and triggers remediation when a protection fails. Passing an earlier test does not establish that a changed agent remains inside the same risk boundary.
Governance pressure does not replace agent testing
IBM reported on June 8, 2026, that 77% of the 2,000 technology leaders surveyed said AI adoption was outpacing their organizations’ governance capabilities. The same study said 59% viewed security and compliance as major obstacles to deploying agents, while organizations that integrated control into their systems experienced 25% fewer incidents, according to IBM’s report.
These figures describe the wider governance pressure, but they do not replace testing an individual agent’s permissions and runtime. IBM also announced on April 15, 2026, a cybersecurity evaluation intended to expose security gaps, policy weaknesses, AI-specific exposures and exploitation paths. Its IBM Autonomous Security service is described as a multi-agent service that analyzes exposures and execution environments, applies policies, detects anomalies, contains threats and feeds governance and risk systems.
That announcement connects agent controls with broader security and governance processes. NVIDIA’s examples make the deployment decision more concrete: verify the identity, runtime, skills, approval gates and audit trail that govern the agent’s actual actions.
Decide what can change before release
The agent may adapt its actions to new data, but its identity, credentials, runtime limits, approval gates and audit trail should remain enforceable as those actions change. If a task requires broader access, stop and revise the policy or obtain the required human approval; do not let the agent expand its own authority.
Promote an agent only when its boundaries block the defined failure cases, its logs preserve the evidence and a named owner accepts the result. When a model, tool or workflow changes materially, run the boundary tests again before returning it to production.