Before You Let AI Agents Act, Know What They’re Running - Cybersecurity Insiders

An AI agent's capabilities expand with every skill, tool and MCP server added to its system. Each addition raises critical questions about what permissions the agent will have and what actions it can perform. Without proper assessment, organizations risk delegating work without understanding the access they've granted.

Much of the current discussion around agent security focuses on monitoring actions after deployment, such as unauthorized access, data exposure or attempts to escape execution environments. However, the conditions that enable these problematic actions are established much earlier in the build process through the implementation of skills, tools and MCP servers.

Component Assessment

Every component deserves thorough scrutiny. A skill can contain natural-language directions that shape an agent's approach to tasks, with potentially hidden execution methods not obvious in superficial reviews. Tools may expose operations with consequences far beyond their descriptions, containing overprivileged and exploitable properties. MCP servers can connect agents to sensitive systems and, through poor design, act as privilege escalation layers.

Consider a hypothetical document-processing skill that directs an agent to send files to an external service for conversion. While this behavior may be intentional and documented, a modified parameter could redirect requests to any resource, opening up unrestricted network fetch or server-side request forgery operations. Security decisions require understanding behavior, destinations and associated arguments—information a basic security scan would miss.

Evidence-Based Evaluation

A useful assessment must provide developers and security teams with sufficient information to make deployment decisions. This includes ownership and provenance, requested permissions, external connections, file access, and command execution capabilities. When concerns are identified, findings should explain relevant behaviors and exploitable conditions.

There's an important distinction between powerful capabilities and vulnerabilities. Tools executing privileged or destructive commands should be restricted in their use with agents. The same capability might require human-in-the-loop enforcement in different workflows. Tools and skills should be classified based on their capabilities to help teams understand potential impacts when automated.

Managing Change

Assessments must identify exactly what was reviewed, as approving a repository name is insufficient when its contents can change. Newer versions may introduce expanded permissions or behavioral changes in tooling or new dependencies. Teams need to record the latest assessed version, preserve findings, and initiate re-evaluations when changes occur.

Clear responsibility is essential—someone should own decisions to introduce components, accept exceptions, and respond when behavior changes. Otherwise, assessments become reports without accountability. Even thorough reviews cannot predict every action agents will take, as inputs change and tools interact. Components appropriate for one task may be inappropriate for another.

Runtime Enforcement

Assessments should inform how agents operate at runtime. If a workflow requires access to one directory, that should shape file permissions. If external communication is unnecessary, the execution environment should enforce that boundary. High-impact actions may require pre-approval. Teams also need visibility into agent actions and the ability to interrupt behavior exceeding authorized scope.

Security leaders should start by choosing an agent workflow, inventorying its components, assessing their capabilities, and comparing those capabilities with the task's actual requirements. Then they must enforce the resulting boundaries and review changes. Organizations cannot make credible decisions about delegating work to agents while leaving underlying components unexplored.