His agent is already taking action. Can he show what he was capable of?
AI agents no longer just respond: they query systems, select tools, and move data. The question that will come from the auditor, the client, or the risk committee is simple : What could that agent do, with what permissions, and who approved it?
From the co-pilot who responds to the officer in action
With a co-pilot, one person asks a question, the model answers, and the person makes the decision. The risk lies in the content.
Using an agent, the model decides the next step. It can call an API, query a knowledge base, or initiate a workflow without anyone reviewing it at that moment. The scope of governance is no longer about the response. It’s about the action.
And when something goes wrong, the conversation takes a different turn. It’s no longer enough to know what the AI said. We need to be able to reconstruct what it was capable of doing, why it was able to do it, and what its limitations were.
Seven Questions You Need to Be Able to Answer
Which agent intervened?
The specific agent or component that was involved in the execution.
What enabled it.
The delegated authority that allowed for that intervention.
What rules were in effect?
The rules and limits in effect at that time.
What he did and what it was about.
The transaction performed and the tool, data, or asset involved.
Under what conditions?
The account, the lead-up, and the sequence of events surrounding the decision.
Who spoke.
The human review or approval that was part of the workflow.
What caused it.
The result of the execution, linked to its evidence.
Most organizations can answer some of them. Very few can answer all of them, with specific dates, and in front of a third party.
Control and evidence are distinct layers
Execution platforms restrict, authorize, and block the agent while it is working. This is necessary, but it leaves no evidence. V-PROOF does not replace that layer or act as a firewall: it adds the evidence.
In practice, V-PROOF reads the configuration of each connected agent: model, version, tools, permissions, safeguards, and whatever else is needed to run it unattended. It only reads. Instructions and conversations do not leave the source platform.
Eight controls are applied to that configuration: authentication, access, tools, knowledge, human oversight, safeguards, documentation, and publication. None of them use a language model, so the result is deterministic: the same agent always returns the same verdict. Anything the platform does not assess remains “unassessed,” never “compliant.”
An approval applies to a specific configuration
Every configuration has its own fingerprint. If someone adds a tool or expands a permission, the fingerprint changes, and the previous approval no longer covers it. The V-Seal records every approval with a specific date and cryptographic proof, verifiable without an account.
For those working with the European AI Regulation, this aligns with two requirements that are common to high-risk systems: documented human oversight (Art. 14) and activity logging (Art. 12).
Where to Start
As of today, the Vertex AI connector has been validated in a production environment; Copilot Studio, Azure AI Foundry, Amazon Bedrock, Agentforce, and ServiceNow have connectors available and are currently undergoing validation.
The starting point is simple: choose the agents that are already operating on systems or data, connect them in read-only mode, and see which controls pass, which fail, and which remain unevaluated.
Govern the agent. Prove the action.
See how a real agent is audited.
Read-only configuration, eight controls without AI, and approval sealed with a cryptographic proof.
Watch the demo