AI Agent Security on a Shoestring: 90 Days & a Small Budget Guide

If your organization has AI agents already operating in production and you've got roughly three months and a tight budget to secure them, your priorities are straightforward: inventory everything, shrink the blast radius, and then test relentlessly. That's the core takeaway from a deep dive with Prasad Tharippala, Field CISO at Versa, who laid out exactly what security teams should do when they can't afford fancy tools but can't afford a breach either.

The reality is that many companies are deploying AI agents faster than they're securing them. Tharippala's advice cuts through the noise with a three-step plan that prioritizes policy and configuration changes—things that cost time and attention, not capital expenditure—before anything else.

First: Know What You've Got

The first 30 days should be about visibility and inventory. This is the most fundamental security step, and it's also the cheapest. You need to know what agents exist, who owns them, what models they use, what data they can access, 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 shouldn't have, turn it off immediately. You cannot secure what you cannot see, and with a limited budget, this step and the next are mostly policy and configuration work. Neither one requires new capital spend, which is exactly why they come first.

Second: Shrink the Blast Radius

Once you know what's out there, the next priority is reducing what a compromised agent can actually do. Apply least privilege, isolate agents, restrict tool and data access, and put controls around high-impact actions.

One of the cheapest and fastest controls available is requiring human approval before an agent can take an irreversible action. It's often the one people forget. Tharippala emphasizes that this is where principles like Zero Trust Network Access and east-west traffic controls become particularly important. A properly implemented SASE architecture, along with data loss prevention and network segmentation, can provide continuous policy enforcement and traffic validation.

The objective should be clear: ensure that a compromised agent cannot automatically become a pathway into other systems or other agents.

Third: Test and Monitor Continuously

The final phase is red-teaming 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 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."

What Counts as a Failure in Red-Teaming?

Tharippala offers a nuanced take on what constitutes a failing result when red-teaming AI agents. It's not simply "the model produced a bad answer." The real failure is when an attacker can make the agent violate its defined security boundary—accessing data it shouldn't, invoking a tool it shouldn't use, bypassing authorization, disclosing sensitive information, or taking a consequential action without the required controls.

He adds 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.

Five Questions Buyers Should Ask Agent Platforms

For organizations evaluating agent platforms, Tharippala expands the typical "secure by design" check to five critical questions:

1. What happens when the agent is compromised? Security shouldn't depend on the model always behaving correctly. The platform should enforce permissions, isolation, and policy boundaries independently of the model.

2. Can I control exactly what the agent can access? Look for granular identity, authorization, tool controls, data access policies, and strong isolation between agents, users, and tenants. Every agent needs its own non-human identity and entitlements, managed like a privileged user account.

3. Can I prove what the agent did? There needs to be sufficient auditability into the agent's decisions, tool calls, data access, and actions. If you can't reconstruct what happened, it becomes extremely difficult to secure an agent in production.

4. 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. Ideally, that evidence is independently verifiable, such as ISO 42001 or a SOC 2 report.

5. What security responsibilities belong to me vs. the platform provider? Buyers need to understand what controls are built into the platform, what they're expected to implement themselves, and how capabilities like prompt validation, GenAI firewalls, data loss prevention, identity controls, and monitoring are handled.

The Hidden Costs of Running Open-Weight Models

Tharippala also addresses what organizations miss when they decide to run open-weight models in-house for security reasons. 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 licenses carry usage restrictions, and regulations like the EU AI Act add obligations for larger models.

There's also a significant 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, and identity and data governance.

"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."

What This Means for Your Team

The takeaway is that securing AI agents doesn't have to be expensive, but it does have to be intentional. The 90-day plan is a pragmatic starting point for teams that are already behind the curve. 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.

For organizations just starting this journey, the advice is clear: start with what you can see, limit what agents can do, and never stop testing. That's a security plan that works on any budget.