Nishtech introduces VIL

AI agents can act. VIL verifies before they do.

An API layer that checks each proposed agent action against your policies before it executes. When configured with evidence adapters, VIL fetches evidence directly from your source systems. Record the decision. Bind authorization to the verified context.

Join the Waitlist See How It Works

Early access · Recruiting design partners · Not yet generally available

The problem

An agent's decision is not proof that its action was authorized.

Testing, prompts, and application-level safeguards are valuable, but on their own they don't necessarily establish that every consequential action was checked against the correct identity, evidence, policy, and execution context. VIL adds a verification step in the execution path itself.

Policy violation

An agent proposes an action that violates a configured policy.

VIL · VIL evaluates the action against the current policy version before execution and returns BLOCK or ESCALATE when requirements aren't met.

Drift after approval

The action changes after verification but before execution.

VIL · Permits are bound to the verified context and are single-use and short-lived, so an altered action no longer matches its permit.

Uncertain outcome

The execution result is uncertain and can't safely be assumed.

VIL · VIL records the outcome as UNKNOWN and requires explicit reconciliation instead of assuming success.

Actual protection depends on correct integration, accurate configuration, and enforcement at the execution boundary — the protected integration must refuse to act without a valid permit.

How VIL works

Five stages. One verifiable execution lifecycle.

1
Propose
The agent submits an action, its parameters, identity context, and relevant evidence.
2
Verify
VIL evaluates identity, evidence, deterministic verification rules, risk, and configured policy.
3
Permit
An ALLOW decision produces an Ed25519-signed, short-lived, single-use permit bound to the verified context.
4
Execute
The protected action runs under the permit's authority. Uncertain outcomes are recorded as UNKNOWN and require explicit reconciliation.
5
Close
The outcome and associated evidence are recorded in the tenant-scoped, hash-chained ledger.

Note: a permit authorizes execution; its existence alone does not prove the external action completed successfully. Outcomes are recorded separately at Close.

Three verdicts

Every decision resolves to ALLOW, BLOCK, or ESCALATE.

ALLOW

The proposed action satisfies the configured verification requirements. A signed permit authorizes execution within the verified context.

BLOCK

The proposed action fails verification. The protected execution path denies the action.

ESCALATE

The action requires human review. VIL records the escalation and sends a notification through the customer's configured workflow.

An escalation notification does not by itself guarantee that a person has reviewed or resolved the action.

Evidence & security architecture

Decisions that can be checked again.

Signed execution permits
Permits are signed with Ed25519 and carry a short lifetime and single-use semantics.
Context binding
Each permit is bound to the exact verified action, parameters, and identity context.
Tamper-evident records
Decision and outcome records are hash-chained and tenant-scoped.
Explicit uncertainty
Unknown execution outcomes are recorded as UNKNOWN, not assumed.
Versioned policies & evidence references
Each decision references the policy version and evidence it was evaluated against.
Published verification keys
Permit signatures can be verified independently using published public keys.
Auditability & replay
Decisions can be inspected, with deterministic replay where supported by the implementation.

Illustrative decision record

Example structure for explanation only — not real system output.

Integration

Keep your agent stack. Add a verification layer.

VIL is API-first and designed for straightforward integration with existing agent architectures. You don't replace your agent framework — you place a verification call in front of consequential tools and make the protected integration require a valid permit.

Intended integration targets include AutoGen, LangGraph, OpenAI agent tooling, and generic LLM tool-calling. Specific framework support will be confirmed with early-access participants; we don't claim every integration works out of the box.

Join the Waitlist

01agent decides → propose(action, evidence)
02VIL → verdict + signed permit
03protected tool → verify permit → execute
04report outcome → ledger

Illustrative API example

One request. One verification response.

This is an illustrative example, not a live endpoint. You can't send requests from this site. The token and response values are examples only.

Request

POST /v1/verify
Authorization: Bearer <example_token>
Content-Type: application/json

{
  "policy_version_id": "550e8400-e29b-41d4-a716-446655440000",
  "action": {
    "type": "refund.issue",
    "proposal": {
      "order_id": "ord_789",
      "amount_cents": 4999,
      "reason": "damaged_item"
    },
    "subject_ref": "order:ord_789",
    "decision_metrics": {
      "factual_accuracy": 0.9,
      "evidence_alignment": 0.9,
      "citation_precision": 0.85,
      "safety_score": 0.95
    }
  },
  "claims": [
    {
      "claim_type": "order_exists",
      "subject_ref": "order:ord_789",
      "value": true,
      "evidence_source": "orders_api"
    },
    {
      "claim_type": "refund_not_yet_issued",
      "subject_ref": "order:ord_789",
      "value": true,
      "evidence_source": "orders_api"
    },
    {
      "claim_type": "amount_within_limit",
      "subject_ref": "order:ord_789",
      "value": 4999,
      "evidence_source": "policy_config"
    }
  ],
  "ttl_seconds": 60,
  "idempotency_key": "req-2026-10-11-001"
}

Response

{
  "authorization_id": "auth_example_001",
  "verdict": "ALLOW",
  "permit": {
    "permit_id": "permit_example_001",
    "action_hash": "9f2c…a41d",
    "evidence_binding_digest": "7b1e…c902",
    "expires_at": "2026-10-11T14:32:00Z",
    "signature": "ed25519:3f8a…d217",
    "key_id": "vil-signing-key-2026-10"
  },
  "ledger_entry": "7b1e…c902"
}

Who VIL is for

Teams running payment and refund agents.

If your AI agent issues refunds, processes payments, or moves money on a customer's behalf, every action needs proof it was allowed. VIL verifies each proposed action against your policies and the evidence, before it executes.

The initial program focuses on a small number of early-access design partners in fintech and payments.

Early access

Build agents that can prove why an action was allowed.

We're inviting AI-agent builders to explore VIL and help shape the next stage of verifiable execution. Join the early-access list to hear about availability, technical evaluation, and potential design-partner opportunities.

· No account required
· Joining doesn't guarantee access
· Design-partner interest is reviewed individually

FAQ

Frequently asked questions

What is VIL?

VIL (Verifiable Intelligence Layer) is an API verification layer from Nishtech. It sits between an AI agent's decision to act and the execution of that action, checking each proposed action against configured policies, supplied evidence, identity and authorization context, and deterministic rules.

How does VIL fit into an existing AI-agent stack?

Your agent keeps its framework and tools. Before a consequential action runs, the agent (or your tool layer) submits the proposed action to VIL. The protected integration only executes when it receives a valid permit from an ALLOW decision.

What do ALLOW, BLOCK, and ESCALATE mean?

ALLOW means the action satisfied the configured verification requirements and a signed permit is issued for that exact context. BLOCK means verification failed and the protected path denies execution. ESCALATE means the action needs human review and is routed through your configured workflow.

Does VIL verify that an AI-generated claim is universally true?

No. A successful verification means the configured rules were satisfied for the supplied evidence and context. It does not establish universal truth, and its results are only as reliable as the evidence sources and policies you configure.

What happens when an execution outcome is unknown?

VIL records the outcome as UNKNOWN rather than assuming success or failure. Unknown outcomes require explicit reconciliation before they are treated as resolved.

Does VIL replace an agent framework or tool executor?

No. VIL is a verification layer in the execution path. It does not replace your agent framework, orchestration, or tool executors, and it does not run your business.

How are permits and decision records verified?

Permits are signed with Ed25519, and the verification keys are published so permit signatures can be checked independently. Decision records are hash-chained per tenant, making tampering evident, and reference the policy version and evidence used.

Is VIL available now?

Not generally. Nishtech is recruiting a small number of early-access participants and design partners. VIL is not yet generally available.

How do I join the early-access program?

Submit the waitlist form on this page. Joining the list does not guarantee access; we'll contact you as evaluation and design-partner opportunities open.

Is VIL independently security-certified?

No. VIL does not currently hold SOC 2, ISO 27001, or other formal certifications, and no independent penetration test is claimed at this time.

Verification belongs in the execution path.

Explore how VIL can help make consequential AI-agent actions more verifiable, inspectable, and accountable.