In a recent Economic Times interview, Olga Lagunova — CTO of GoTo, a company with roughly $1bn in annual revenue — makes an argument that deserves more attention than the usual enterprise-AI commentary.
Her framing: AI agents remain more promise than reality for most enterprises, and the obstacle isn't model capability. It's trust. In her words, "AI has to earn our trust."
The line that matters most for anyone shipping agents is the one about direction of travel: as these systems become more autonomous, governance and security become more important, not less — and enterprises can't treat governance as an afterthought if they want AI to move past pilots into production value.
That's exactly right. I want to take it one step further, because "earn our trust" is a testable proposition, and most organisations are not yet treating it like one.
Trust in security is a measurement, not a posture
Every other part of enterprise software learned this lesson already.
You don't trust a payments system because the vendor says it's secure. You trust it because it's been pen-tested, the findings were graded, the criticals were fixed, and someone re-tested to confirm the fix held. Trust is the output of an adversarial process, not an input to it.
AI agents haven't caught up to that standard. The typical assurance story today is some combination of "we use a frontier model," "we have guardrails," and "we ran a prompt-injection eval." That's a posture. It isn't evidence.
The gap matters more for agents than for ordinary software, for a reason Lagunova gestures at when she distinguishes greenfield from brownfield work. Agents wired into legacy enterprise systems — the CRM, the ticketing system, the database that predates everyone on the team — don't just answer questions. They take actions, through tools, against systems with real blast radius. An agent that can be talked into misusing a tool is not a content-moderation problem. It's a privilege-escalation problem wearing a chat interface.
What "earning trust" concretely requires
If you wanted to actually earn trust in an agent you shipped, rather than assert it, here's the shape of the work:
- Test the agent itself, not just the app it lives in. Your web-app pen test doesn't cover the model, its tools, or its conversation. Those are separate attack surfaces — I mapped them here: chat jailbreaks, MCP servers at the JSON-RPC layer, GraphQL-fronted agents, multi-turn manipulation, and confused-deputy tool abuse.
- Test the surfaces that carry consequences, not just the famous one. Prompt injection is the well-covered case. The ones that turn into incidents are the tool and protocol layers, because that's where an agent stops talking and starts doing.
- Score findings by deployment context, not just by severity. The same jailbreak is a footnote on a sandboxed demo and a serious problem on a multi-user agent touching regulated data. Reproducibility, blast radius, and regulatory exposure are what turn a finding into a decision.
- Measure, don't assert. If an attack succeeded once in ten attempts, say so. A finding that reproduces 90% of the time and one that reproduces 5% of the time warrant completely different responses — and a report that can't tell you which one you have isn't giving you evidence, it's giving you an anecdote.
- Re-test. An agent's security posture changes when someone edits the system prompt. A point-in-time audit is a snapshot of a system that has already moved.
There's now a published standard to hold vendors to — including us
This is the part most teams don't know yet. In January 2026, OWASP's GenAI Security Project published Vendor Evaluation Criteria for AI Red Teaming Providers & Tooling — a neutral, vendor-agnostic buyer's checklist for exactly this problem.
It's genuinely useful, and refreshingly specific. It says evaluation must be reproducible. It says metrics must account for multiple attempts of the same attack rather than single-shot results, and names pass@k as a metric buyers should expect. It lists red flags — including reliance on static lists of single-turn attack prompts.
If you're evaluating anyone's agent-security testing, that document is a better starting point than any vendor's website, mine included. Print it, and make every vendor in your process — us too — walk it line by line and show their evidence.
This market moves fast enough that feature claims decay in weeks. I've had to retire a few of my own after checking them properly. A published buyer standard is the thing that doesn't rot.
I'll be direct about why I'm pointing you at a standard rather than a feature list: it's a much better basis for a decision than whoever writes the boldest homepage.
The adoption-to-assurance gap
One more point from the interview worth sitting with. Lagunova observes that India is ahead of the global average in enterprise AI adoption, and frames the next challenge as converting that lead into measurable business outcomes.
I'd add a corollary: adoption leads assurance, and the gap between them is where incidents live. If agents are being deployed faster than they're being tested — and in most organisations I've seen, they are — then the security-testing question isn't a compliance chore to schedule later. It's the thing standing between a promising pilot and a production system anyone is willing to be accountable for.
Lagunova's own point about scrutiny scaling with risk is the practical version of this: not every agent needs the same depth of testing, but the ones touching critical systems need considerably more than a prompt-injection eval.
So: has anyone tried to break yours?
If the blocker for enterprise AI really is trust — and I think that's the correct diagnosis — then the work is to make agent security legible: tested against the surfaces that matter, scored in a way that survives scrutiny, and re-tested when things change.
That's what AAPT does: adversarial probe suites across chat, MCP, GraphQL, multi-turn and tool-misuse surfaces, with findings scored by reproducibility, blast radius and regulatory exposure, and mapped to OWASP LLM Top 10 and MITRE ATLAS.