Vijil CEO Vin Sharma: AI Agents Need Trust Infrastructure Before Autonomy

Vijil has raised $23 million across two rounds — a $6 million seed and a $17 million Series A — on the argument that most enterprise AI agents will never reach production because nobody can prove they behave as intended. Vin Sharma, the company's co-founder and CEO, spent more than 30 years in cybersecurity, open source, cloud computing, and AI infrastructure before starting the firm, including leading deep-learning engineering for Amazon SageMaker and Amazon Bedrock at AWS, building data-center infrastructure at Intel, and holding product and engineering roles at Hewlett-Packard. His career began in 1995 with automated red-team testing for trusted UNIX systems.

In an interview with Unite.AI, Sharma laid out a case that is easy to state and hard to refute: the AI industry is pouring resources into agent capability while starving the oversight layer. The claim deserves scrutiny — Vijil sells that oversight layer — but the underlying funding and deployment numbers give the argument weight. The stakes are straightforward. If enterprises cannot verify agent behavior, adoption stalls; if they deploy anyway, the failure modes land on regulated professionals and their clients.

What is the problem Vijil is selling?

Sharma frames the core gap with a financial metaphor. "Without these metrics and mechanisms tailored to the needs of specific organizations, the initial wave of exuberant adoption will die out on the sandbars of risk and ROI because businesses will not be able to prove that their agents are working in their best interests," he said.

The company sells what it calls trust infrastructure for enterprise AI agents: software that evaluates agent behavior, enforces controls, and improves resilience across the agent lifecycle. The pitch combines testing, security, and continuous feedback so that agent behavior aligns with an organization's intended purpose and policies. That is a broad remit, and Sharma's definition of the bottleneck is correspondingly broad.

"The bottleneck to deploying more agents with increasing autonomy is whether organizations can specify the intended behavior of their agents and verify that the agents are behaving as they intended," he said. "Not only that — they have to be able to do it at a scale and speed at which agents operate."

His prescription: agents measuring and modifying the behavior of other agents. He identifies two specific gaps:

• Knowing what to measure — what "good" means for an agent in a given organization.
• Knowing what to modify — which component to tune when behavior drifts: the model and its parameters, the system prompt, the user instructions, the agent harness, or the graph of a multi-agent system.

The takeaway: Sharma is arguing the problem is not detection but specification, and specification at machine speed.

How does Vijil define trust — and can it be measured?

Sharma offers a definition that reads like an expected-value calculation. "We define trust as the expected benefit of delegation to an autonomous agent discounted by the risk of its betrayal of our intent," he said.

That decomposes into three measurable pillars, in his telling:

• Reliability: the agent performs as expected under diverse conditions.
• Security: it performs as expected under hostile conditions.
• Safety: it minimizes business, legal, and technical risks.

An agent earns trust, he argues, when it behaves correctly under normal, noisy, and hostile conditions — and when it fails, it minimizes the blast radius. The definition is crisp. What Sharma does not specify in the interview is who validates the measurements: the vendor selling the trust layer, the enterprise buying it, or an independent third party. That question remains open, and it matters for any buyer.

Why does conventional testing fail for agents?

Sharma's most concrete technical claim is that traditional testing categories simply do not reach the new failure surface. Traditional software fails in well-understood ways, he said: malformed inputs, weak logic and system design, implementation bugs, hidden attack vulnerabilities, and unintended side effects of outputs. Testing for those failures is "appropriately predictable."

Agents break that model. "Agents vastly expand the surface area of failure," Sharma said. "To a point where the surface area is categorically inaccessible to model evaluation, unit tests, integration tests, application security tests, pen tests, and compliance checks."

That is a strong claim — categorically inaccessible — and it conveniently rules out every incumbent testing discipline. But it has a defensible core: agents combine models, tools, data sources, memory, and external systems, and their behavior depends on context in ways unit tests cannot enumerate. New metrics, he argues, must evaluate agent behavior against the purpose specified by its principal (the party delegating authority), the personas of its users, and the policies of the organization, industry, and region where it operates.

The takeaway: Sharma is not saying old tests are wrong, only that they cover a shrinking fraction of what can go wrong.

What did AWS teach him about finding failures early?

Sharma credits his SageMaker and Bedrock years with one formative lesson: catching problems early beats catching them late. "Finding failures in the reliability, security, and compliance of services early in the development cycle was far more effective and efficient than finding them on the eve of launch, which was traditional, or worse after the service was in production, which meant waking up to phone calls about a failing service," he said.

That lesson drives Vijil's scope. The company tests agents before deployment, defends them in production, and continuously improves them — three distinct products bundled into one lifecycle pitch. The pre-deployment and production phases cannot be collapsed, Sharma argues, because some risks only surface against real users, data, and systems.

"The real world has an infinite capacity to surprise us," he said. "And a surprised agent is an error-prone agent."

His examples are pointed. An agent generating a meme that misfires is nobody's problem. An agent assisting or replacing "a financial advisor, a paralegal, an attorney, a nurse, a doctor, a patient, or any professional in an industry that has to show proof of fiduciary behavior" cannot function at all unless tolerance levels are tightly scoped, carefully monitored, and behavior quickly restored after failure. The framing is useful for readers weighing deployment decisions: risk tolerance is use-case specific, and the fiduciary professions have the least room for error.

Do permissions and identity still work when agents take actions?

Asked whether traditional security concepts — permissions, identity, access control — suffice for agents that act rather than just respond, Sharma answered flatly: "No."

His replacement model has four requirements:

• Agents get unique, verifiable identities as actors in the organization.
• Roles bind both behavior and functional components — tools with access permissions over resources — under mandatory access control policies.
• Continuous monitoring detects drift from intended purpose.
• Steering keeps agents resilient under attack.

This positions agents as first-class security principals, closer to employees or service accounts than to software artifacts. It also implies a governance burden most enterprises have not staffed for. Sharma does not dwell on that cost, which is worth noting when evaluating the pitch.

How do you red-team something that adapts?

Sharma's red-teaming pedigree goes back three decades, and he draws a sharp line between scripted exercises and what agents require. Historically, red teaming tested an organization's defenses against coordinated attack under controlled conditions. "The general principles hold," he said. "We still need coordination of attacks under controlled conditions to probe for the weaknesses of the organization under test."

But the scripted middle period is over, in his view, because agents are not deterministic software. "They are designed to adapt to their environment so the same attack cannot be replayed predictably," he said. An attack that worked yesterday may fail today against the same agent.

His proposed frame: treat agents like corporations. Red teaming an agent then means adapting to its purpose, probing its drift from user intent, and testing "its willingness and ability to evade the policies of its environment." That last phrase is telling — it treats policy evasion as an expected property to be probed, not an anomaly.

How did a $23 million company reach $1 million in revenue?

Vijil's commercial numbers are modest relative to its ambition: roughly 20 people on the founding team and $1 million in annual recurring revenue after a $6 million seed and a $17 million Series A. Sharma attributes the trajectory to one early structural decision.

"We chose early on to build a layer of trust that integrates with the customer's platform of choice but anticipated that enterprises would increasingly seek greater customization, more granular control, and lower cost over multi-agent systems using open models," he said.

He calls it the long game: a platform layer rather than a point product. He concedes the cost of that choice. Building a platform "creates challenging conditions where matching with enterprises that are ready for governance over agents at scale is not as easy as selling a lift-and-shift service." In plain terms, the product requires buyers who already know they need agent governance — a small pool today.

Will behavior verification become a deployment prerequisite?

Sharma's forecast for the industry divides current practice into three silos: builders evaluate agents for capability, red teams test resistance to prompt injections and jailbreaks, and GRC (governance, risk, and compliance) teams have just started testing for regulatory compliance. What almost nobody does, he said, is run "a regime of behavior verification that runs continuously in the background throughout the lifecycle of the agent as models, tools, resources, workflows, and the target environment change."

That continuous regime is where Sharma claims Vijil is unique — tracing an agent's actual production behavior back to its specification in a feedback loop that improves the agent. "The agents that survive attacks are those that adapt to stay resilient," he said.

Whether that capability is genuinely differentiated or simply early is not settled by the interview; no customer evidence or benchmark results appear in it. What is settled is the direction of the argument. If regulated industries adopt autonomous agents at scale, some form of continuous behavior verification becomes a procurement requirement rather than a differentiator — and the vendors who can prove it works, with evidence, will set the standard.