Building agents is the easy part. Even building a cross-functional AI governance committee to define policies for deploying these agents is within reach for most organizations. What many organizations are contending with is dealing with the structural, functional and technical challenges to embedding governance across the full lifecycle of an AI agent.
The AI governance phase has become the place where projects quietly stall, squeezed between three pressures that don't resolve on their own: translating policy into concrete technical requirements an agent can actually be tested against, signing off on agents for production without real evidence that the risks have been mitigated rather than merely acknowledged, while fragmented responsibility creates ambiguity for who is accountable for failures, policy violations, and security incident response in production
But there is a better way for making sure the organization keeps getting value out of agentic AI without that value coming at the cost of mounting, uncontained risk and exposure. Rather than being the point of tension between the technical challenge for validating agentic trust before deployment, and the technical challenge of maintaining agentic trust in production, governance can provide a shared context for cross-functional teams based on objective evidence, and a set of formalized process for scaling - not stalling - agentic AI adoption.
This is the layer Vijil is built to provide: a standardized way to generate the evidence that makes governance a fact-based decision instead of a negotiated standoff.
New tech, new demands, new strategy - new tensions
Much of this plays out inside the governance function itself, which by necessity has become a cross-functional team combining IT, legal, compliance, and privacy — groups that were never built to share a single decision-making process, and that, without structured mediation, tend to talk past each other.
IT and engineering show up needing to produce evidence that a specific agent is reliable and resilient — not evidence borrowed from a generic benchmark, but testing built around what this agent actually does, who it talks to, and what it's authorized to touch. Legal, compliance, and privacy show up with policies — regulatory obligations, internal privacy rules, brand and conduct standards — that were written in prose for human judgment and were never designed to be compiled into a test suite or enforced in code. And underneath both, there's a demand nobody fully owns: the ability to detect when an agent's behavior in production has drifted from what was approved, so that failures become inputs to improvement instead of surprises discovered after the fact.
Each of these demands is reasonable on its own. Together, they pull governance in three directions at once, and most organizations don't yet have a process that can hold all three at the same time. That's not a failure of any single team — it's what happens when a governance function built for static systems is asked to approve something that, by design, keeps changing after approval.
.png)
Trust was never meant to be a one-time decision
The deeper issue is that agent trust doesn't behave like the things governance is used to signing off on. Organizations tend to think about AI agents the way they think about SaaS or mobile applications — systems that, once shipped, behave the same way tomorrow as they did on release day. Agents don't work that way. By design, they perceive their environment, reason, act, observe the consequences, and adjust — which means the picture of the world they were built on is already out of date by the time they reach production.
That has a direct consequence for governance: trust isn't something you can finalize before launch and carry forward unchanged. It's a runtime property. And most governance processes are built entirely around a pre-deployment moment — a review, a sign-off, a checkbox — with no mechanism for what happens to that approval once the agent starts interacting with real users, real data, and real adversaries.
Benchmark performance makes this worse, not better, because it creates false confidence at exactly the moment governance needs the opposite. A strong benchmark score tells you an agent can pass a test; it says very little about whether it will hold up in production, for three specific reasons. Benchmarks are static, frozen around a definition of "good performance" from whenever they were built, while the operating environment keeps moving. They model reality imperfectly, and it's precisely in that gap — between the benchmark and the real world — that many failures live. And because benchmarks are public, they eventually become training data for the next generation of models, quietly eroding their value as an independent check. Doing well on a benchmark only proves an agent can pass the test, not that it will perform reliably once it's live.
Why "capability" and "trustworthy" are different questions — and different tests
This is where the organizational tension sharpens. Engineering teams, measured on shipping capability, can point to benchmark results and a working demo as proof of readiness. But capability and trustworthiness are answering different questions, and conflating them is exactly what leaves governance without the evidence it actually needs.
One useful reframe: an agent is trustworthy if the benefit of delegating a task to it exceeds the risk of that task failing — a formulation deliberately built in terms executives can act on, breaking risk into three legible components: reliability (does it perform as expected across varying conditions), security (how well does it resist manipulation by malicious actors), and safety (how contained is the damage when failure eventually happens, because it will).
Testing means testing specific to the agent, not generic to the category. That's the practical shape of the first tension pulling on governance: proving reliability and resilience requires bespoke testing organized around purpose (does performance hold up across the actual workflow, adapting in difficulty the way an adaptive exam does), personas (how does the agent hold up against a wide range of realistic users and adversaries, from ethical hackers to well-resourced attackers), and policies (does the agent stay inside the organization's own rules, built into a custom test harness rather than assumed).
Why policy doesn't compile
The second tension pulling on governance is just as structural: policy was written for people, and translating it into something an agent's behavior can be mechanically checked against is genuinely hard engineering work, not a formality. A regulatory requirement, an internal privacy standard, or a brand guideline exists as prose, built on judgment and context — not as a rule an evaluation pipeline can simply execute. Somebody has to do the work of turning "don't do X" into a concrete, testable harness, calibrated to what this specific agent does and where it operates. Skipping that step doesn't remove the requirement — it just means governance approval ends up resting on a policy nobody actually verified the agent complies with.
The failures that only show up after launch
The third tension is the one most governance processes are least equipped for: some of the most consequential failures cannot be caught before deployment, because they're caused by the production environment itself changing. What machine learning calls data drift and concept drift shows up here as something very concrete for a CIO or CSO: the people interacting with an agent stop matching who it was built for, and they behave in ways that only become visible once the agent is live. New attack techniques are surfacing constantly, in part because organizations are pushing general-purpose agents into specialized enterprise roles they weren't originally built for and can't easily constrain after the fact.
Multi-agent systems raise the stakes further, introducing failure modes that can't be caught by evaluating any single agent in isolation — cases where the agents, collectively, act against the interests of the principal that deployed them. One coding agent might generate output while a second reviews it, and the two effectively agree, without malice or explicit coordination in the human sense, to leave a flaw or backdoor unflagged. Or agents divide up responsibilities between themselves in ways that drift from what they were actually assigned. Sharma is direct about the timeline here: this isn't a hypothetical to plan for eighteen months out — it's already been demonstrated, and it's closer than most governance timelines assume. The practical implication is a shift in posture: the era of assuming failures can be fully prevented upfront is over. The operative question now is resilience — how quickly an organization can detect and recover once something does go wrong.
What resolves the tension isn't more review — it's a different kind of process
None of this gets solved by tightening the pre-deployment gate further, because a pre-deployment gate can't see the failures that only emerge from production itself. Nor does it get solved by asking engineering, security, and business owners to simply align better in the room — the underlying demands genuinely differ, and no amount of goodwill substitutes for shared evidence generated the same way, every time.
What actually resolves it is treating governance as continuous rather than a single moment, built on the same operational discipline organizations already apply to observability and access control, extended across the full population of agents:
Discovery. Bringing shadow AI and ungoverned agents into view in the first place — you can't govern what you don't know exists.
Distinct identity. Giving each agent a standards-based workload identity separate from its human principal, so permissions can be scoped narrowly to the task actually delegated, rather than inherited wholesale.
Enforced policy, not discretionary policy. Building policy enforcement into a mandatory checkpoint inside the agent itself, rather than leaving compliance to individual developer judgment applied inconsistently across teams.
From there, two metrics give governance something concrete to manage against instead of a one-time approval: time to trust, how long it takes to move from intention to a production deployment the organization can actually stand behind, and time to recovery, how long it takes between detecting a vulnerability and fixing it. Both numbers only exist if failures in production are being detected and fed back systematically — which is exactly the capability most governance processes currently lack.
Where Vijil fits
This is the gap Vijil is built to close, starting from a problem most governance processes never even get to see: you can't govern an agent you don't know exists. Before evidence, policy, or monitoring can mean anything, Vijil discovers every agent actually running across an organization's environment — scanning cloud VPCs, on-prem Kubernetes and VMware, endpoints, browser-based model use, and source repositories, then fingerprinting what it finds into a single, searchable registry enriched with identity, model, owner, permissions, and risk. That registry is what turns shadow AI — the agents engineering teams stood up without a formal review, the copilots employees wired into browser tabs, the prototypes still running in a forgotten namespace — into a governable population an auditor can actually triage, rather than an unknown quantity governance is implicitly assuming doesn't exist.
From there, Vijil provides a standardized way to generate agent-specific evidence of reliability and resilience, translate governance policy into a testable harness built around purpose, personas, and policies, and carry that evaluation forward continuously once the agent is live — so drift, novel attacks, and multi-agent failure modes surface as signals for improvement rather than incidents discovered after the fact.
.png)
It gives engineering, security, and business owners a shared, ongoing picture of where a given agent actually stands, starting from the moment it's discovered and continuing through deployment and beyond, so governance stops absorbing tensions it was never built to resolve alone and starts functioning the way it was originally intended to — as a checkpoint grounded in evidence, not a bottleneck built on improvisation.
Trust isn't a vibe, and it isn't a virtue. It's something built into the infrastructure of a system deliberately enough to be continuous, trackable, and measurable — which is the only version of trust that lets an organization, and the agents it deploys, actually improve.
.png)