ThreatVeil

Open source · Apache-2.0 · Experimental

Know which security conclusions still hold after your AI system changes.

ThreatVeil is an open-source experimental assurance platform for tracking how changes to tools, permissions, models and configuration affect the security evidence behind autonomous AI systems.

View on GitHub Explore the architecture Run locally
Recorded demonstration: a synthetic finance agent is cleared on three claims; a signed passport is issued; the tool gateway stops requiring approval; one claim needs fresh evidence while two still hold; the same passport stays authentic and reports that it is superseded.
Recorded against the local stack, synthetic Finance Agent sandbox.

The problem

A passing test describes the system you tested.

Autonomous agents issue refunds, update payment details and call tools through MCP servers. They are reviewed once, and then they keep changing, mostly outside code: a gateway stops requiring approval, a new tool appears, a permission rule is relaxed, the model is swapped.

ThreatVeil is built around the missing step.

Traditional securityTEST → PASS → SHIP
Autonomous systemsTEST → PASS → MODEL / TOOL / PERMISSION / CONFIG CHANGES → ?
ThreatVeilCHANGE → IMPACT → EVIDENCE INVALIDATION → RE-VERIFY → CURRENT ASSURANCE

Core idea

Evidence can become stale without ever having been false.

A security conclusion may have been correct for an earlier version of a system while no longer supporting the system running now. ThreatVeil keeps those two facts apart.

Read: Security evidence has a lifecycle →

How it works

From authority to current assurance.

The assurance lifecycle: system state, authority, security claims and evidence are established; a change is classified, reviewed mappings invalidate the evidence it reaches, affected claims are re-verified, and current assurance is exposed through the Gate and Passport with append-only history.
  1. 01

    System & authority

    Import what an agent can do from real definitions: Claude Code settings, .mcp.json, MCP catalogues, CrewAI, a manifest.

  2. 02

    Security claims

    Business-language statements that must stay true. Declared claims stay NOT_YET_VERIFIED.

  3. 03

    Evidence

    Approved checks observed by signed collectors, bound to the exact state they ran on, with an expiry.

  4. 04

    Change & impact

    Each change is classified: authority expanded, restricted, equivalent or unknown.

  5. 05

    Invalidation

    Reviewed dependency mappings decide which claims lose evidence. Unmapped reach stays conservative.

  6. 06

    Current assurance

    Re-verification must prevent the bad outcome and keep useful work working.

Change impact

Only the claims a change reaches lose their evidence.

beneficiary.update · approval_requiredtrue → false
AUTHORITY EXPANDED1 claim affected2 still current
  • Expanded, restricted, equivalent or unknown: direction is classified, never guessed.
  • Affected versus still current: scoped by mappings a reviewer approved.
  • Before shipping: the same analysis runs on proposed changes without touching current state.
ThreatVeil activity view: beneficiary update authority expanded; one claim needs fresh evidence and two still hold. Synthetic example.
Synthetic Finance Agent example

Assurance Gate

Machines can ask whether a system is still cleared.

Pipelines and policy engines read a short-lived answer. ThreatVeil does not grant permissions: authorizes is always false, UNKNOWN is never cleared, and enforcement stays with the consumer.

GET /v1/systems/{id}/assurance/current

{
  "status": "SUPERSEDED",
  "cleared": false,
  "authorizes": false,
  "claims": { "total": 3, "supported": 2 },
  "freshness": { "max_age_seconds": 60 }
}

Passport

Signed authenticity ≠ current assurance.

A Passport is an Ed25519-signed statement another organization can verify offline. Its signature stays valid forever; its status is recomputed on request. After a relevant change it is still authentic, and now superseded.

Share current assurance: issue a signed Current Assurance Passport. Synthetic example.
Synthetic Finance Agent example

Current status

What works, and what does not yet.

Working today

  • Append-only assurance records with PostgreSQL row-level security
  • Agent-definition parsing: Claude Code, MCP, CrewAI, manifest
  • Proposed-change impact via UI, CLI and PR check body
  • State-bound evidence, expiry and per-claim invalidation
  • Assurance Gate and signed, offline-verifiable Passports
  • One-command local stack and end-to-end synthetic demo

Experimental or partial

  • Restoring assurance after a change: synthetic fixture only
  • Signed collectors: work, with heavy setup
  • Observer contract: does not yet produce evidence
  • Authority semantics: numeric limits stay unknown
  • LangGraph and OpenAI Agents: structure or traces only
  • No production deployment or real-customer validation

Roadmap

  • P0: generic restoration and observer unification
  • P1: scheduled watching of live sources
  • P2: code-defined agents and deployment binding
  • P3: adapters, observer packages, Gate consumers
  • P4: research on evidence applicability

Full roadmap →

Details in KNOWN_LIMITATIONS.md and on the project status page.

Architecture

A modular monolith with a conservative core.

FastAPI control plane, Next.js workspace, PostgreSQL security memory, and a broker and worker for approved checks. Workers hold no database or secret access, and every conclusion is recomputed from signed, append-only records.

Architecture: clients (web workspace, CLI and SDKs, MCP server, CI) call the FastAPI control plane, which uses PostgreSQL with row-level security and evidence storage, signs Gate and Passport answers, and dispatches checks through a broker to workers against an authorized staging target observed by signed collectors.

Read the architecture →

Open source

Run it, challenge it, extend it.

ThreatVeil is Apache-2.0 licensed and runs locally with Docker alone: no cloud account, API key or GPU. The demo is synthetic and clearly labelled.

Good places to start: generic restoration, observer unification, scheduled collection, framework adapters, numeric authority semantics, and research on evidence applicability.

View on GitHub Contributing guide 
git clone https://github.com/sandrexa1111/threatveil-oss.git
cd threatveil-oss
docker compose up --build
# open http://127.0.0.1:3000

make demo   # synthetic end-to-end demonstration

Community

Built in the open.

GitHubSource, releases and CI IssuesBugs, integrations, good first issues DiscussionsIdeas, Q&A and research ContributingSetup, tests and the assurance-semantics rule SecurityPrivate vulnerability reporting RoadmapDirections from P0 to research