Securing AI Agents Requires Controls Across Models, Tools and Runtime
AI agent security depends on enforceable permissions, isolated execution, repeatable testing and evidence that controls work across the full stack.

AI agent security depends on engineering controls that remain effective when an agent behaves unexpectedly. That means limiting what it can access and change, enforcing those limits outside the model, and keeping evidence of what happened. The practical challenge is to apply these controls across the entire system: models, tools, data, identities, services and the environment where actions run.
Agents add capabilities such as reasoning, tool use and adapting actions to information they encounter. Those capabilities change how software acts, but established security responsibilities still apply: identify each actor, restrict access, limit exposure and verify protections. Organizations are adopting AI while practices for securing these systems are still taking shape, which makes clear ownership and testable requirements especially useful.
Follow the action through the full stack
An agent deployment is a system of connected parts. Models supply capabilities; harnesses manage context, tools and workflows; and runtime environments provide the infrastructure where actions execute. Data and instructions flow through those parts, while tools can turn an agent’s decisions into changes in other systems. A weakness at any point can affect the security of the whole workflow.
Consider an agent that can update customer records. It encounters malicious instructions in an attached document and tries to send customer data to an unauthorized destination. The system should not rely on the agent to recognize the instructions as unsafe. Network rules should block the transfer independently, while protected logs record the attempted tool call, the authorization decision and the result. That evidence can help a team identify which tool was involved and where the agent tried to send data.
Access also needs to match the task. Permission to edit a record should not automatically grant permission to export it. An agent can request additional access, but it must not be able to grant that access to itself. This distinction matters wherever one workflow combines actions with different consequences.
Make limits independent of the model
Instructions can guide an agent’s behavior, but they cannot serve as the only security boundary. The environment running the agent should constrain file access, network destinations and available processes independently of the agent’s reasoning. If the agent makes a bad decision, these controls still need to hold.
Each agent should have a traceable identity and credentials scoped to its assigned work. Organizations also need policies that specify which data an agent may read, which systems it may change and which actions need human approval. High impact actions and changes to permissions warrant a review within those boundaries.
Security responsibilities extend to the components an agent uses. Teams need ways to check the origin and integrity of tools, skills and dependencies, and to restrict which components an agent can access. If an incident occurs, records of tool calls, access decisions and outcomes can help reconstruct the sequence of events. Procedures for revoking credentials and containing the problem turn those records into a basis for action.
NVIDIA OpenShell is an open source runtime that provides sandboxed execution and enforces policies governing agents’ access to data, networks and system resources. The Open Secure AI Alliance includes partners building on OpenShell. Cisco’s DefenseClaw adds a governance layer, while JFrog integrates with OpenShell to scan and verify agent skills and enforce policies on which skills agents can use.
Test controls before and after deployment
Teams need evidence that controls block attempts to obtain credentials beyond an agent’s scope or send sensitive information to unauthorized destinations. Testing should also examine whether an agent can alter its permissions or interfere with monitoring. Because changes to a model, tool or workflow can change how a system behaves, teams should repeat relevant checks after material updates.
A named owner should review the results and decide whether the system is ready to deploy. When a test fails, the team needs to reproduce the issue, investigate it and make a correction. Turning each finding into a repeatable test helps establish whether the fix continues to work in later releases.
Tools can support this work through repeated attack simulations and ongoing testing. CrowdStrike’s SafeMind is described as a system for testing and strengthening defenses through attack simulations. Palo Alto Networks’ Prisma AIRS is described as supporting continuous red teaming as models and applications change. In either case, the useful measure is whether testing reveals actionable weaknesses and whether fixes can be checked again.
Choose defensive tools for the evidence they need
Open and closed models offer different options for security work. Closed models can provide managed capabilities and services. Open models give defenders more ability to inspect relevant components, adapt methods and run work on infrastructure they control. During an incident, that control can help a team reproduce a failure and test a fix against its own systems while keeping sensitive evidence within its environment.
AI can assist with finding vulnerabilities, checking fixes and investigating attacks. Its value should be judged through reproducible findings, verifiable corrections and faster response, rather than capability claims alone. Examples include Capital One’s VulnHunter for code security and ReversingLabs’ Spectra Assure for analyzing software packages for malware and tampering.
Sharing what failed, which controls worked and how fixes were verified can help other teams improve their own systems. NVIDIA’s security research and the Open Secure AI Alliance support exchange of research, tools and expertise. For teams deploying agents, the operational standard is concrete: enforce limits beyond the model, assign an accountable owner and keep evidence that protections work. Repeatable testing and shared findings can help that standard keep pace as agent capabilities change.
Learn more about NVIDIA’s security research and the Open Secure AI Alliance.