Vanarchain профилі | Binance Square

·

--

Мақала

Proof, Not Promises: Why Every AI Agent Needs an Evidence LayerWe just released Veil, an open-source evidence layer for autonomous AI agents, under Apache 2.0. Here's the problem it solves, and why "trust me, my logs are fine" is about to stop being acceptable. Six months ago at Vanar, we shipped xBPP, an open standard for deciding whether an AI agent should be allowed to take a given action. ALLOW, BLOCK, or ESCALATE. It closed what we called the Agentic Gap: the question of whether an agent should act, separated cleanly from the question of whether it can. Today we're closing the other half. Because once an agent has acted, once it has moved the money, signed the transaction, filed the report, somebody, eventually, will ask you to prove what it did. And as it stands, most teams cannot. The audit gap. AI agents are no longer just chat. They're signing transactions. Moving treasury funds. Filing expense reports. Negotiating prices with suppliers. Executing compliance workflows. Every one of those actions is a decision somebody will eventually be asked to defend. And right now, almost every team running production agents has one of three audit strategies, all of them flawed. The first is application logs. Mutable. Ungoverned. Usually missing the why behind a decision. Useless as cross-organisational evidence. If you've ever had to reconstruct what happened in an incident from a Datadog query, you know exactly how badly this scales. The second is database event tables. Plaintext, which means anyone with read access sees the customer narrative, is a compliance disaster waiting to happen. Mutable, which means tamperable. And no producer signature, which means no permanent identity trail. You can't actually prove who made the decision. The third is putting everything on-chain. Onchain is public. Public is unacceptable for the vast majority of business data. "Just put it on a blockchain" is the answer of someone who hasn't met a CFO. What's missing is a record format that is encrypted (so sensitive context stays private), signed (so producers can be held accountable), indexable (so reviewers don't have to decrypt to audit), and chainable (so the lifecycle of a single decision, request, approval, execution stays together as one provable unit). That's what Veil and VeilCapsule provide. And as of today, it's available on npm under Apache 2.0. The design insight: indexable AND encrypted. This is the design decision that separates VeilCapsule from a generic encrypted database. And it's the one I want to dwell on, because most teams that try to build an audit layer get this wrong. Most encrypted systems force a tradeoff. Either you can search the data, in which case the encryption isn't really protecting anything, or you can't, in which case the data isn't really useful. Auditors can't audit what they can't read. Compliance reviewers get blocked. Operations teams build shadow CSVs that defeat the entire purpose. VeilCapsule splits the record into two layers. • The structured plaintext layer , amount, currency, recipient, approver, timestamp, decision, the tool called. Indexed in the database. Queryable like any normal column. • The encrypted narrative layer, the LLM's reasoning, the user's original instruction, the supplier negotiation context. Decryptable only by the intended viewer. A compliance reviewer can run aggregate queries like "show me every agent decision above ten thousand dollars that wasn't approved by a human between Q1 and Q3" against ten thousand capsules, without ever decrypting a single record. They see that it happened and what kind of thing it was. Only a few records of the structured signal flags require a deeper look at the narrative. The auditor sees that it happened, and what kind of thing it was. They only decrypt the few records that the structured signal flags warrant a closer look. This is the property that makes Veil actually usable as a system of record. Not a database with encryption bolted on. A record format designed from the ground up to be inspectable without being exposed. What it looks like in practice. Concrete example. A user types into a Discord bot: "2550 for the flight from LHE to DXB to 0xaC773…" The amount exceeds the $50 escalation threshold the agent has been configured with. So three capsules are written, linked by a single action_id: • Capsule 1, ESCALATE. The agent records what was requested, why it escalated, and who requested it. The narrative, the user's exact phrasing, and the LLM's reasoning are encrypted. The plaintext metadata captures the amount, currency, recipient, and the escalation reason. • Capsule 2, APPROVED. A human approver responds in Discord. The approver's reasoning is encrypted. The plaintext captures who approved, when, and that the action_id is the same as cap1. • Capsule 3, EXECUTED. The transfer goes through. Plaintext captures the txHash and success status; the encrypted layer captures the executor's rationale and any error context. Read those three records together, and a reviewer can prove what was requested, why it escalated, who escalated it from where, who approved it and when, that the execution matches the approved intent, and what hit the chain, all without decrypting the narrative. The narrative, the LLM's reasoning, and the user's exact words stay readable only by the intended recipient. If something goes wrong six months later, the forensics aren't heroic. They're a single SQL join. The non-custodial mode. There's a second design decision worth flagging, because it's the one that matters most for consumer applications. By default, Veil capsules are encrypted to the operator. That's fine for an enterprise treasury deployment where the operator is the only intended reviewer. But for a consumer-facing agent, a personal AI paymaster, an assistant that handles your subscriptions, a bot that splits bills with your friends, the operator should not be able to read your data. So Veil ships with a non-custodial mode. The user derives a Veil keypair from a signature in their own EVM wallet. Their public key is registered with the operator once. From that point forward, every capsule about that user is encrypted to them. The operator stores the ciphertext but cannot decrypt it. Only the user, by re-signing the derivation message in their wallet, can regenerate the secret key and read their own audit history. The implications are significant. An operator can be subpoenaed and produce only ciphertext. A consumer AI assistant can serve millions of users while remaining structurally unable to read their data. The same primitives that gave Web3 self-custody of money now give it self-custody of the audit trail. Where Veil sits in the stack. Veil is the evidence layer. It sits underneath the parts of the stack that make decisions, xBPP, our open policy standard, and the parts that manage human approvals. It feeds the part of the stack that visualises the Vanar Governance Console, which any organisation can use to inspect their capsule chains as timelines, filter by structured metadata, and selectively decrypt the narrative for authorised viewers. Adopting the full Vanar stack means xBPP for automated policy, the Approval Engine for human-in-the-loop where policy requires, Veil for the signed and encrypted record, and the Console for the human-readable surface over those records. Each piece can be adopted independently. The whole stack interoperates by convention. And it sits comfortably alongside the rest of the agent ecosystem. x402, ERC-8004, ACP, those standards define how agents pay. Veil defines what evidence remains after they have. We're not competing with any of them. We're filling the same gap they've each gestured at and not closed. Why this matters right now. Three forces are converging. AI agents are graduating from chat to action. Production deployments in 2026 are no longer experimental. The agents handling treasury operations at a Fortune 500 next year already exist as prototypes today. The question is what audit layer they ship with. Regulators are catching up. The EU AI Act, MiCA, and the SEC's guidance on automated decisioning all of them require auditable records of AI decisions. "Trust me, my logs are fine" stops being acceptable. Auditable, signed, encrypted, queryable- that's the bar. And users are demanding control of their own data. The forces that produced GDPR and Apple's privacy positioning are now producing demand for user-owned audit trails when AI acts on their behalf. The companies that get this right will own the consumer-facing agent market. The ones that don't will keep apologising for breaches. The teams that build the audit layer correctly now will be the ones selling AI agents to regulated buyers in eighteen months. The teams that patch logs together will be answering subpoenas. Proof, not promises. If your AI agent is making decisions that matter, and increasingly, all of them are, you need an evidence layer that holds up to scrutiny. Application logs are not it. Plaintext databases are not it. Blockchain is not it. Veil is specifically the shape of evidence record the regulated world has been asking for: encrypted, signed, indexable, chainable, and verifiable, by exactly the right parties, exactly when they're entitled to it. The packages are live on npm. The crypto is standard. The convention is open. Apache 2.0, with a patent grant, so your legal team can adopt it without friction. We released xBPP because the question of whether an agent should act needed a standard before agents could go into production. We're releasing Veil for the same reason, because the question of what they did needs to be answered. By you. By your auditor. By your regulator. And by the user. npm and GitHub packages for Veil Capsule and Veil Keys from Wallet are now available under the Apache 2.0 license. Full documentation, specifications, and the complete capsule schema can be found at https://veilprotocol.org/

Proof, Not Promises: Why Every AI Agent Needs an Evidence Layer

We just released Veil, an open-source evidence layer for autonomous AI agents, under Apache 2.0.
Here's the problem it solves, and why "trust me, my logs are fine" is about to stop being acceptable.
Six months ago at Vanar, we shipped xBPP, an open standard for deciding whether an AI agent should be allowed to take a given action.
ALLOW, BLOCK, or ESCALATE. It closed what we called the Agentic Gap: the question of whether an agent should act, separated cleanly from the question of whether it can.
Today we're closing the other half.
Because once an agent has acted, once it has moved the money, signed the transaction, filed the report, somebody, eventually, will ask you to prove what it did. And as it stands, most teams cannot.
The audit gap.
AI agents are no longer just chat. They're signing transactions. Moving treasury funds. Filing expense reports. Negotiating prices with suppliers. Executing compliance workflows. Every one of those actions is a decision somebody will eventually be asked to defend.
And right now, almost every team running production agents has one of three audit strategies, all of them flawed.
The first is application logs. Mutable. Ungoverned. Usually missing the why behind a decision. Useless as cross-organisational evidence. If you've ever had to reconstruct what happened in an incident from a Datadog query, you know exactly how badly this scales.
The second is database event tables. Plaintext, which means anyone with read access sees the customer narrative, is a compliance disaster waiting to happen.
Mutable, which means tamperable. And no producer signature, which means no permanent identity trail. You can't actually prove who made the decision.
The third is putting everything on-chain. Onchain is public. Public is unacceptable for the vast majority of business data. "Just put it on a blockchain" is the answer of someone who hasn't met a CFO.
What's missing is a record format that is encrypted (so sensitive context stays private), signed (so producers can be held accountable), indexable (so reviewers don't have to decrypt to audit), and chainable (so the lifecycle of a single decision, request, approval, execution stays together as one provable unit).
That's what Veil and VeilCapsule provide. And as of today, it's available on npm under Apache 2.0.
The design insight: indexable AND encrypted.
This is the design decision that separates VeilCapsule from a generic encrypted database. And it's the one I want to dwell on, because most teams that try to build an audit layer get this wrong.
Most encrypted systems force a tradeoff. Either you can search the data, in which case the encryption isn't really protecting anything, or you can't, in which case the data isn't really useful. Auditors can't audit what they can't read. Compliance reviewers get blocked. Operations teams build shadow CSVs that defeat the entire purpose.
VeilCapsule splits the record into two layers.
• The structured plaintext layer , amount, currency, recipient, approver, timestamp, decision, the tool called. Indexed in the database. Queryable like any normal column.
• The encrypted narrative layer, the LLM's reasoning, the user's original instruction, the supplier negotiation context. Decryptable only by the intended viewer.
A compliance reviewer can run aggregate queries like "show me every agent decision above ten thousand dollars that wasn't approved by a human between Q1 and Q3" against ten thousand capsules, without ever decrypting a single record.
They see that it happened and what kind of thing it was. Only a few records of the structured signal flags require a deeper look at the narrative.
The auditor sees that it happened, and what kind of thing it was. They only decrypt the few records that the structured signal flags warrant a closer look.
This is the property that makes Veil actually usable as a system of record. Not a database with encryption bolted on. A record format designed from the ground up to be inspectable without being exposed.
What it looks like in practice.
Concrete example. A user types into a Discord bot: "2550 for the flight from LHE to DXB to 0xaC773…"
The amount exceeds the $50 escalation threshold the agent has been configured with. So three capsules are written, linked by a single action_id:
• Capsule 1, ESCALATE. The agent records what was requested, why it escalated, and who requested it. The narrative, the user's exact phrasing, and the LLM's reasoning are encrypted. The plaintext metadata captures the amount, currency, recipient, and the escalation reason.
• Capsule 2, APPROVED. A human approver responds in Discord. The approver's reasoning is encrypted. The plaintext captures who approved, when, and that the action_id is the same as cap1.
• Capsule 3, EXECUTED. The transfer goes through. Plaintext captures the txHash and success status; the encrypted layer captures the executor's rationale and any error context.
Read those three records together, and a reviewer can prove what was requested, why it escalated, who escalated it from where, who approved it and when, that the execution matches the approved intent, and what hit the chain, all without decrypting the narrative.
The narrative, the LLM's reasoning, and the user's exact words stay readable only by the intended recipient.
If something goes wrong six months later, the forensics aren't heroic. They're a single SQL join.
The non-custodial mode.
There's a second design decision worth flagging, because it's the one that matters most for consumer applications.
By default, Veil capsules are encrypted to the operator. That's fine for an enterprise treasury deployment where the operator is the only intended reviewer. But for a consumer-facing agent, a personal AI paymaster, an assistant that handles your subscriptions, a bot that splits bills with your friends, the operator should not be able to read your data.
So Veil ships with a non-custodial mode. The user derives a Veil keypair from a signature in their own EVM wallet. Their public key is registered with the operator once. From that point forward, every capsule about that user is encrypted to them.
The operator stores the ciphertext but cannot decrypt it. Only the user, by re-signing the derivation message in their wallet, can regenerate the secret key and read their own audit history.
The implications are significant. An operator can be subpoenaed and produce only ciphertext. A consumer AI assistant can serve millions of users while remaining structurally unable to read their data. The same primitives that gave Web3 self-custody of money now give it self-custody of the audit trail.
Where Veil sits in the stack.
Veil is the evidence layer. It sits underneath the parts of the stack that make decisions, xBPP, our open policy standard, and the parts that manage human approvals. It feeds the part of the stack that visualises the Vanar Governance Console, which any organisation can use to inspect their capsule chains as timelines, filter by structured metadata, and selectively decrypt the narrative for authorised viewers.
Adopting the full Vanar stack means xBPP for automated policy, the Approval Engine for human-in-the-loop where policy requires, Veil for the signed and encrypted record, and the Console for the human-readable surface over those records. Each piece can be adopted independently. The whole stack interoperates by convention.
And it sits comfortably alongside the rest of the agent ecosystem. x402, ERC-8004, ACP, those standards define how agents pay. Veil defines what evidence remains after they have. We're not competing with any of them. We're filling the same gap they've each gestured at and not closed.
Why this matters right now.
Three forces are converging.
AI agents are graduating from chat to action. Production deployments in 2026 are no longer experimental. The agents handling treasury operations at a Fortune 500 next year already exist as prototypes today. The question is what audit layer they ship with.
Regulators are catching up. The EU AI Act, MiCA, and the SEC's guidance on automated decisioning all of them require auditable records of AI decisions. "Trust me, my logs are fine" stops being acceptable. Auditable, signed, encrypted, queryable- that's the bar.
And users are demanding control of their own data. The forces that produced GDPR and Apple's privacy positioning are now producing demand for user-owned audit trails when AI acts on their behalf. The companies that get this right will own the consumer-facing agent market. The ones that don't will keep apologising for breaches.
The teams that build the audit layer correctly now will be the ones selling AI agents to regulated buyers in eighteen months. The teams that patch logs together will be answering subpoenas.
Proof, not promises.
If your AI agent is making decisions that matter, and increasingly, all of them are, you need an evidence layer that holds up to scrutiny.
Application logs are not it. Plaintext databases are not it. Blockchain is not it.
Veil is specifically the shape of evidence record the regulated world has been asking for: encrypted, signed, indexable, chainable, and verifiable, by exactly the right parties, exactly when they're entitled to it.
The packages are live on npm. The crypto is standard. The convention is open. Apache 2.0, with a patent grant, so your legal team can adopt it without friction.
We released xBPP because the question of whether an agent should act needed a standard before agents could go into production. We're releasing Veil for the same reason, because the question of what they did needs to be answered. By you. By your auditor. By your regulator. And by the user.
npm and GitHub packages for Veil Capsule and Veil Keys from Wallet are now available under the Apache 2.0 license.
Full documentation, specifications, and the complete capsule schema can be found at https://veilprotocol.org/

Vanarchain

Proof, Not Promises: Why Every AI Agent Needs an Evidence Layer

The Infrastructure Behind Accountable Agents

The Safety Layer For Autonomous Agents

AI Agents Need Rules Before They Spend

AI Agents Need Rules Before They Spend

Трендтегі тақырыптар