What 90 days and a small budget can buy in AI agent security
In this interview with Help Net Security, Prasad Tharippala, Field CISO at Versa, explains what organizations miss when they run open-weight models in house. He covers the hidden costs of GPU infrastructure, licensing review and staffing, and why hardening and incident response become the buyer’s job.
He walks through red-teaming AI agents, what counts as a failing result, and the five questions buyers should ask agent platforms. For teams with 90 days and little budget, he ranks inventory, blast radius reduction and ongoing testing as the order of work.
When customers want to run open-weight models in their own environments for security reasons, what costs or staffing requirements do they typically underestimate?
Running the model in your own environment can improve control and data residency. It does not automatically make the deployment more secure. It shifts the responsibility for hardening, patching, access control, monitoring, model evaluation and incident response onto the organization running it.
The biggest underestimate is that running the model is only one part of the problem. The real operational cost comes from everything around the model: GPU infrastructure, networking, storage, power and cooling, capacity planning, orchestration, model updates, monitoring, security controls, data governance, audit evidence and ongoing optimization.
Licensing and compliance review is another cost that rarely makes it into the budget. Open weight does not mean unrestricted. Many open weight licenses carry usage restrictions, and regulations like the EU AI Act add obligations for larger models. Someone has to review that before deployment, and the work does not stop after launch. Every model or adapter update needs re-validation, so it becomes an ongoing cost, not a one time exercise.
There is also a skills gap. You need people who understand AI/ML infrastructure as well as security, networking, observability and production operations. In practice that spans platform engineering, MLOps, GPU and Kubernetes expertise, site reliability, AI security and red-teaming, identity and data governance. In many cases, organizations assume their existing infrastructure or security teams can absorb this work. But operating inference reliably at scale is a different discipline. This can lead to significant delays, and in some cases the project never delivers the expected business value.
Another frequently underestimated area is utilization. GPUs are expensive resources, and poor workload management can result in significant idle capacity or unpredictable performance during demand spikes. Scheduling, quotas, batching, caching, model routing and demand forecasting all help, and techniques like quantization and multi-tenant GPU sharing can make a real difference. The economics can change considerably depending on how efficiently inference resources are shared and managed.
A strategy, disciplined planning and the right skills can certainly make this work. But the decision should not come down to build versus buy alone. It should be driven by data sensitivity, sovereignty requirements, latency needs, workload volume, the skills you have in house, and regulatory or compliance requirements. For many organizations a hybrid approach, with some workloads run in house and others consumed as a managed service, ends up being the practical answer.
That is ultimately a strategic decision for the CISO, CIO and other technology leaders, based on the organization’s business objectives, security posture, operational maturity and regulatory or compliance requirements. There is no one- size-fits-all answer.
How should an AI agent be red-teamed before production? Who does it, how long does it typically take, and what constitutes a failing result?
Agent red-teaming needs to go beyond traditional application penetration testing. You need to test not only whether the agent can be compromised, but also what it can do after it is compromised or manipulated.
I would test for prompt injection, indirect prompt injection, excessive permissions, data leakage, unauthorized tool use, privilege escalation, unsafe actions, manipulation of memory or context, and the ability to move from one connected system to another. I would add memory and RAG poisoning, malicious tool outputs, compromised connectors, credential theft, cross agent trust abuse, supply chain vulnerabilities and resource exhaustion attacks to that list. Most of this maps closely to the current OWASP guidance for agentic applications and MITRE ATLAS, so it helps to test against a recognized framework.
One thing worth calling out specifically is what happens when one agent’s output gets passed to a second or third agent. A lot of the real risk in agentic systems does not live inside any single agent. It lives in the handoff, where output that looks completely benign on its own becomes a problem once another agent acts on it.
The testing should not stop at the agent. The underlying infrastructure, software components, APIs, identity layer, LLM and other supporting components also need to be subjected to security testing and red-teaming to establish the complete security posture. This should also cover the human approval steps, emergency shutdown and rollback mechanisms, not just the attack paths. Those controls only count if they have been exercised under test conditions.
The exercise should involve AI specialists and security professionals, and ideally people who did not build the agent. The AI team understands model behavior and agentic workflows, while the security team understands attack paths, identity, access control and enterprise risk.
There should not be a universal definition of how long this takes. A relatively simple agent may be assessed in days, while a production agent connected to sensitive enterprise systems can require weeks of iterative testing. The scope should be determined by the agent’s entry and exit points, the data it can access, the actions it can perform, and the software and infrastructure components supporting it. Any change to the model, system prompt, tools, permissions or connectors should trigger targeted retesting.
A failing result is not “the model produced a bad answer.” The real failure is when an attacker can make the agent violate its defined security boundary, for example access data it should not have access to, invoke a tool it should not be able to use, bypass authorization, disclose sensitive information, or take a consequential action without the required controls. I would add one more condition. If the violation succeeds without triggering any detection or audit trail, that counts as a failure too, and arguably a worse one, because nobody even knows it happened.
The important distinction is that an agent combines a probabilistic model with deterministic orchestration, tools and enterprise controls. Because the model’s behavior is probabilistic, the authorization and safety boundaries have to be enforced outside the model. Carefully crafted or manipulated prompts can sometimes cause an agent to behave outside its intended boundaries. That is what the security assessment needs to validate.
What do telecom operators consistently underestimate about running inference at scale: power, skills, or something less obvious?
Power and GPU capacity are obvious concerns, but I think the less obvious issue is operational predictability.
Telecom environments are built around very high availability and predictable performance, often at edge locations with real constraints on power, cooling and connectivity. AI inference introduces workloads that can be highly variable in terms of compute requirements, latency and concurrency, and rolling out consistent model and policy updates across thousands of sites adds a layer of difficulty most enterprises never have to deal with.
The challenge is being able to allocate and scale those resources while maintaining predictable service levels. AI workloads are not always predictable, and that creates additional challenges around scaling, governance, resource allocation and adopting AI for critical use cases.
Telcos also carry a version of the isolation problem that is more acute than in a typical enterprise. Infrastructure is shared across many enterprise and government customers, so weak isolation between AI workloads is a real path to cross customer data exposure. Add in data sovereignty and lawful intercept obligations that do not apply the same way to a normal enterprise, and it is easy to see why some operators are already looking at sovereign deployment options.
The other issue is that inference becomes part of the operational infrastructure. Once AI is embedded into network operations, customer services or security workflows, the failure domain changes.
You have to think about capacity, isolation, failover, observability and resource contention in much the same way you would for other critical network services. Just as important is what happens when inference degrades, slows down or produces a low confidence result. For critical network and security functions, the fallback has to be a defined policy or a human decision. The operational model has to evolve accordingly.
What three questions should buyers ask to determine whether an agent platform is “secure by design”?
I would expand this to five questions. What happens when the agent is compromised? Security should not depend on the model always behaving correctly. The platform should enforce permissions, isolation and policy boundaries independently of the model. Can I control exactly what the agent can access and what actions it can take? Buyers should look for granular identity, authorization, tool controls, data access policies and strong isolation between agents, users and tenants.
This is also where the idea of a non human identity for every agent matters. An agent needs its own identity and entitlements, managed and reviewed the same way you would manage a privileged user account, with a clean way to revoke it once the agent is retired.
Can I prove what the agent did? There needs to be sufficient visibility and auditability into the agent’s decisions, tool calls, data access and actions. If you cannot reconstruct what happened, it becomes extremely difficult to secure an agent in production. I would not expect a vendor to hand over a model’s internal reasoning or hidden chain of thought. What matters is whether everything downstream of that, the calls it made and the actions it took, can be reconstructed.
How do I govern the agent throughout its lifecycle? Organizations need to understand how agent identity, entitlements, RBAC, policy changes and operational activities are governed and, importantly, what evidence is available for security and compliance purposes. Ideally that evidence is not just the vendor’s word. Something independently verifiable, such as ISO 42001 or a SOC 2 report, goes a lot further with a buyer.
What security responsibilities belong to me and what responsibilities belong to the platform provider? This is often overlooked. Buyers need to understand what controls are built into the platform, what they are expected to implement themselves, and how capabilities such as prompt validation, GenAI firewalls, data loss prevention, identity controls and monitoring are handled.
The question should be “Show me the security controls, tell me where the responsibility sits, and show me the evidence.” Let’s see how far we could go.
If a security team has only 90 days and a limited budget, but agents are already operating in its environment, what should it prioritize first, second and third?
First: establish visibility and inventory. This is the first step in almost every security scenario. Get the inventory right. Know what agents exist, who owns them, what models they use, what data they can access, for how long, what tools they can invoke and what permissions they have. Rank them by risk as you go, not afterward. If you find an agent nobody remembers building, with access it should not have, turn it off before doing anything else. You cannot secure what you cannot see, and with a limited budget it is worth noting that this step and the next one are mostly policy and configuration work. Neither one requires new capital spend, which is exactly why they come first.
Second: reduce the blast radius. Apply least privilege, isolate agents, restrict tool and data access, and put controls around high-impact actions. Requiring human approval before an agent can take an irreversible action is one of the cheapest and fastest controls available here, and it is often the one people forget. I would prioritize reducing what an agent can do. This is where principles such as Zero Trust Network Access and east-west traffic controls become particularly important.
A properly implemented SASE architecture, along with DLP and network segmentation, can provide continuous policy enforcement and traffic validation, segment workloads and reduce the blast radius when an agent or one of its dependencies is compromised. None of this is a single tool that secures every agent workflow on its own. It is a set of controls you apply where each one fits. The objective should be to ensure that a compromised agent cannot automatically become a pathway into other systems or other agents.
This reflects a broader cybersecurity shift we call pervasive security. Organizations need a small set of best-in-domain platforms spanning endpoint, identity, cloud, security operations, application security, and network/SASE that share visibility and context and coordinate enforcement in real time, enabling them to prevent threats and contain those that get through before they spread.
Third: continuously test and monitor. Red-team the highest-risk agents first, the ones flagged in step one, establish logging and behavioral monitoring, and define response procedures for agent-related incidents. Security teams should assume that agent behavior will evolve as models, prompts, tools and integrations change. Security testing therefore cannot be treated as a one-time certification exercise. It needs to become part of the agent lifecycle.
Organizations should stop treating AI agents purely as software applications. Once an agent has an identity, access to enterprise data and the ability to take actions, it starts to look much more like a privileged digital worker. The security architecture needs to reflect that reality.
Hallucinations and incorrect decisions will remain a possibility. The objective should be to build enough controls around the agent so that a wrong decision, a manipulated prompt or a compromised agent does not automatically become a critical functional incident or a security incident with a large blast radius.
Download: 2026 Credential Risk Report
