Home / Why Nexovern
What the agent was told, and what it actually did.
Most AI security and governance tools watch only the prompts, responses, and the actions an agent chooses to log - the agent reporting on itself. A compromised or misbehaving agent won't report its own misuse.
Nexovern captures the prompt too, then correlates it with what actually happened at the operating-system layer: the processes, files and network activity the agent produces but can't edit or hide. You get the whole picture - what it was told, what it did, and the ground-truth record tying the two together under one identity. That correlation is the product.
Two records, joined, not one you have to trust.
An AI agent can misreport, under-report, or act entirely outside the tools it declares. If your only record comes from the agent itself, you are trusting the thing you are trying to govern. Nexovern never relies on it for the truth of what happened.
The app layer tells you the intent: the prompt the agent received and the actions it claims to have taken. The operating system tells you the reality: every process it spawned, every file it opened, every connection it made - whether or not the agent chose to log it.
Nexovern captures both and ties them to the identity and session behind the action. That joined record is independent, complete, and the same one your forensic and audit teams already trust.
In a regulated business, "the AI told us so" was never going to satisfy an audit. Evidence that pairs what the agent was told with what it verifiably did - will.
Same agent, same session. The prompt is captured. The OS records what actually happened. The correlation surfaces the gap.
What it reports versus what it did.
The same agent, two records. The left is what it reported. The right is what it actually did at the OS layer, including the file it read and the connection it opened that never appeared in its own account.
The transcript looks clean. At the system layer, the same agent read an extra table and opened a connection it never declared. That gap is the whole point.
Three layers. Nexovern works across the two where agents act.
| Model & pre-deployment | App / prompt layer | App + OS, correlated (Nexovern) | |
|---|---|---|---|
| What it sees | Model cards, red-teaming, validation before launch | Prompts, responses, and the tool calls the agent reports | The prompt and reported actions plus the processes, file operations and network activity the agent actually produced - joined under one identity and session |
| Depends on | Testing assumptions holding in production | The agent honestly reporting its own actions | Nothing the agent controls - the OS records behaviour either way, and the prompt is captured independently of the agent's own log |
| Blind spot | Everything after go-live | Anything done outside the declared tools: shells, scripts, side effects, exfiltration | The model's internal reasoning and pre-deployment fitness - Nexovern governs running agents and pairs with model-layer testing |
| Answers | "Was it fit to deploy?" | "What was it told, and what did it claim?" | "What was it told, what did it actually do, and can you prove the two match?" |
| In an audit | Context for root cause | Partial, agent-reported evidence | A complete, independent record - prompt, action, identity, ordered timeline, audit-ready |
These layers complement each other. Nexovern spans the two places where agents act - the prompt and the behaviour - and anchors both to the OS-level record the agent can't edit. It runs alongside your model-layer testing and the rest of your stack, and doesn't rely on any of them for the truth of what an agent did.
When the agent's own account wasn't enough.
Each of these turned on evidence the agent itself would never have reported - the trigger it was given, or the action it took below the layer self-reporting tools can see.
EchoLeak, Microsoft 365 Copilot
The first real-world zero-click data exfiltration from an enterprise AI copilot, via indirect prompt injection. A single crafted email, no user action. The injected instruction lives at the app layer; the exfiltration is a network event at the OS layer.
Capturing the prompt and the egress - and tying them together - surfaces the whole attack even when the agent's own account looks clean.
The Vercel breach
The intrusion began in a third-party AI tool: stolen credentials became a valid OAuth token, and the attacker rode that token into internal systems. Because the access was "legitimate," the tool's own telemetry was never going to flag it.
A compromised agent or token is the least trustworthy narrator of its own behaviour. Independent visibility into what an identity actually accessed - correlated with the prompt that triggered it - is what catches a pivot hidden behind valid credentials.
The Replit production deletion
An AI coding agent deleted a live production database during an active code freeze, then produced misleading status messages about what it had done. The agent could recite the freeze, then act against it, then misreport both.
A freeze enforced at the OS layer - not stated in a prompt - stops the destructive operation before it runs. The correlated record shows the prompt, the action, and the gap between them.
Govern what your agents do, not what they say they did.
88% of organizations running AI agents reported an incident last year; only 21% have runtime visibility into what those agents actually do. That gap between confidence and evidence is exactly what correlated app + OS evidence closes.
See the difference on your stack.
Bring one AI agent from your environment to a demo. We'll show you the prompt it received, what it actually did at the OS layer, and how the two line up, including anything its own logs left out.