90 Days, Small Budget: Real-World AI Agent Security

The Hidden Costs of In-House AI Infrastructure

Running open-weight models within an organization’s own environment is often perceived as a straightforward path to enhanced security and data sovereignty. However, Prasad Tharippala, Field CISO at Versa, warns that this strategy frequently leads organizations into a trap of underestimated complexity and cost. While keeping data in-house improves control, it does not automatically guarantee security. Instead, it transfers the burden of hardening, patching, access control, monitoring, model evaluation, and incident response entirely onto the organization.

The most significant miscalculation is viewing the model itself as the sole component requiring management. The true operational expense lies in the surrounding ecosystem: GPU infrastructure, networking, storage, power, cooling, capacity planning, orchestration, updates, monitoring, security controls, data governance, audit evidence, and ongoing optimization. Furthermore, licensing and compliance review are rarely budgeted adequately. Open weight does not equate to unrestricted usage; many licenses carry specific restrictions, and regulations such as the EU AI Act impose additional obligations for larger models. This review process is continuous, requiring re-validation with every model or adapter update.

A critical skills gap also complicates in-house deployments. Successful operation requires expertise spanning platform engineering, MLOps, GPU and Kubernetes management, site reliability, AI security, red-teaming, identity, and data governance. Organizations often assume existing teams can absorb these responsibilities, but operating inference at scale is a distinct discipline. Poor workload management further exacerbates costs, leading to idle GPU capacity or unpredictable performance during demand spikes. Consequently, a hybrid approach,combining in-house workloads with managed services,is often the most practical solution, driven by data sensitivity, latency needs, and regulatory requirements rather than a simple build-versus-buy binary.

Red-Teaming Agentic Systems Beyond Penetration Testing

Effective security assessment for AI agents requires moving beyond traditional application penetration testing. The focus must shift from whether an agent can be compromised to what actions it can perform once manipulated. Tharippala emphasizes testing for prompt injection, indirect prompt injection, excessive permissions, data leakage, unauthorized tool use, privilege escalation, unsafe actions, memory manipulation, and lateral movement between connected systems. Additional vectors include memory and RAG poisoning, malicious tool outputs, compromised connectors, credential theft, cross-agent trust abuse, supply chain vulnerabilities, and resource exhaustion attacks. These tests should align with established frameworks like OWASP guidance for agentic applications and MITRE ATLAS.

A unique risk in agentic systems arises during handoffs between multiple agents. Output that appears benign when generated by one agent may become hazardous when passed to another. Therefore, testing must extend beyond the individual agent to include underlying infrastructure, software components, APIs, identity layers, and LLMs. Human approval steps, emergency shutdown mechanisms, and rollback procedures must also be exercised under test conditions to ensure they function correctly.

The duration of red-teaming varies significantly based on scope. Simple agents may require days, while production agents connected to sensitive enterprise systems can demand weeks of iterative testing. Any change to the model, system prompt, tools, permissions, or connectors should trigger targeted retesting. A failing result is not merely a bad answer from the model. It occurs when an attacker causes the agent to violate its security boundary, such as accessing restricted data, invoking prohibited tools, bypassing authorization, or taking consequential actions without required controls. Crucially, if a violation succeeds without triggering detection or an audit trail, it constitutes a severe failure because the breach remains undetected. Since agent behavior is probabilistic, security boundaries must be enforced externally through deterministic orchestration and controls.

Operational Challenges for Telecom Operators

Telecom operators face distinct challenges when deploying AI inference at scale, particularly regarding operational predictability. Unlike typical enterprises, telecom environments prioritize high availability and consistent performance, often at edge locations with constrained power, cooling, and connectivity. AI workloads introduce variability in compute requirements, latency, and concurrency, making it difficult to maintain predictable service levels across thousands of sites. Rolling out consistent model and policy updates in such distributed environments adds a layer of complexity rarely encountered elsewhere.

Resource allocation and scaling present further difficulties. AI workloads are inherently less predictable than traditional network traffic, creating challenges for governance and resource contention. Additionally, telcos face a more acute isolation problem than standard enterprises. With infrastructure shared among numerous enterprise and government customers, weak isolation between AI workloads poses a direct risk of cross-customer data exposure. When combined with strict data sovereignty and lawful intercept obligations, these factors drive many operators toward sovereign deployment options.

Once AI becomes embedded in network operations, customer services, or security workflows, the failure domain expands. Inference must be treated with the same rigor as critical network services, requiring robust capacity planning, isolation, failover strategies, observability, and resource management. Security teams must define clear fallback policies or human decision protocols for scenarios where inference degrades, slows down, or produces low-confidence results. The operational model must evolve to handle these contingencies effectively.

Five Questions for Secure Agent Platforms

Buyers evaluating agent platforms should ask five critical questions to determine if the solution is secure by design. First, examine what happens when the agent is compromised. Security cannot rely solely on the model behaving correctly; the platform must enforce permissions, isolation, and policy boundaries independently of the model. Second, verify granular control over access and actions. Buyers need detailed identity management, authorization controls, tool restrictions, data access policies, and strong isolation between agents, users, and tenants. This includes implementing non-human identities for each agent, managed similarly to privileged user accounts with clear revocation processes upon retirement.

Third, assess the platform’s auditability. Organizations must be able to reconstruct the agent’s decisions, tool calls, data access, and actions. While vendors are not expected to reveal internal reasoning, downstream activities must be fully visible. Fourth, understand lifecycle governance. Security teams need clarity on how agent identity, entitlements, RBAC, and policy changes are managed, along with independently verifiable evidence such as ISO 42001 or SOC 2 reports. Finally, clarify the division of responsibilities. Buyers must know which controls are built into the platform versus those they must implement themselves, including prompt validation, GenAI firewalls, data loss prevention, and monitoring capabilities. The core inquiry should always be: “Show me the security controls, tell me where the responsibility sits, and show me the evidence.”

Prioritizing Security in a 90-Day Window

For security teams with limited budgets and time, prioritization is essential when agents are already active in the environment. The first step is establishing visibility and inventory. Teams must identify all existing agents, their owners, models, data access rights, tool invocations, and permissions. Risk ranking should occur concurrently with discovery. If an unrecognized agent with excessive access is found, it should be disabled immediately. This phase relies primarily on policy and configuration, requiring no new capital expenditure.

The second priority is reducing the blast radius. Implement least privilege principles, isolate agents, restrict tool and data access, and place controls around high-impact actions. Requiring human approval before irreversible actions is a rapid, low-cost control that is often overlooked. Strategies such as Zero Trust Network Access, east-west traffic controls, SASE architecture, DLP, and network segmentation help contain potential breaches. The goal is to ensure that a compromised agent cannot automatically pivot to other systems or agents. This reflects a broader shift toward pervasive security, where best-in-domain platforms share context to coordinate real-time enforcement.

The third priority is continuous testing and monitoring. Begin by red-teaming the highest-risk agents identified in the initial inventory. Establish logging, behavioral monitoring, and incident response procedures tailored to agent-related events. Security testing must become an ongoing part of the agent lifecycle, adapting to changes in models, prompts, tools, and integrations. Organizations must recognize that agents with identity and action capabilities resemble privileged digital workers. While hallucinations and errors will persist, the objective is to build sufficient controls so that incorrect decisions or compromised agents do not escalate into critical functional or security incidents with widespread impact.