Changelog

​

QWED Verification — tenant-scoped admin endpoints and working RBAC

Security fix. Admin endpoints now authorize by the API key owner’s role and act only on the caller’s own organization. Previously, role checks never ran, so every admin endpoint returned 401 Unauthorized. The endpoints also accepted organization, log, and key IDs from the caller without an ownership check, which would have allowed cross-tenant access once role checks worked.

​

What changed

• Working role checks. QWED authenticates the API key, then checks the owning user’s role. The key must be live (not revoked or expired), and the owning user and organization must be active, with the user in the key’s organization. Otherwise QWED returns 403 Forbidden.
• Tenant scoping with 403. GET /admin/compliance/export/csv, GET /admin/compliance/report/soc2/{org_id}, and GET /admin/security/threats/{org_id} return 403 Forbidden for another organization’s ID.
• Tenant scoping with 404. GET /admin/compliance/verify/{log_id} and POST /admin/keys/rotate return 404 Not Found for an ID in another organization, without revealing that it exists.
• Key rotation rules. Members can rotate only their own keys. Owners and admins can rotate other users’ keys only when the key owner doesn’t hold a higher role. Revoked or inactive keys return 404 Not Found. The new secret is returned only for a key in the caller’s organization.

​

QWED Verification — verify_fact fails closed offline and Money rejects non-finite amounts

QWEDClient.verify_fact no longer reports a claim as verified when the QWED service can’t be reached. Money rejects NaN and Infinity amounts, and verify_invoice_total reports invalid inputs as a failed check instead of raising.

# Before: status="VERIFIED", is_verified=True after only a local PII scan.
# After: status="UNVERIFIABLE", is_verified=False.
result = client.verify_fact(claim=claim, context=context)
if result.status == "UNVERIFIABLE":
    reject(claim)

​

What changed

• verify_fact fails closed when the service is unreachable (#449). On a connection failure or a connect or read timeout, the Python SDK returns status="UNVERIFIABLE" and is_verified=False with a message explaining that remote verification was unavailable. Previously, a connection failure returned VERIFIED after only the local PII scan, and a timeout raised an exception. See verify_fact.
• Money rejects non-finite amounts (#451). Money("NaN"), Money("Infinity"), and Money(float("inf")) raise ValueError.
• verify_invoice_total never raises on invalid input (#451). Invalid amounts, a negative or non-finite tolerance, or a non-Decimal tolerance return (False, reason) instead of raising. Currency mismatches still return (False, "Currency mismatch: ...").

from decimal import Decimal
from qwed_new.core.money import Money, verify_invoice_total

subtotal = Money("1000.00", "USD")
tax = Money("180.00", "USD")
claimed_total = Money("1180.00", "USD")

ok, reason = verify_invoice_total(subtotal, tax, claimed_total, tolerance=Decimal("-1"))
# (False, "Invalid tolerance: Decimal('-1') must be a finite, non-negative Decimal")

​

QWED Verification — request body caps, timeouts, and sandbox concurrency limits

Availability hardening for self-hosted servers. Oversized bodies, slow providers, unbounded batch jobs, and concurrent sandbox containers can no longer stall or exhaust the API. Verdicts and fail-closed behavior are unchanged.

​

What changed

• Body cap on every /verify route. JSON routes accept up to 1,000,000 bytes. /verify/stats and /verify/image keep their larger upload caps. Oversized bodies return 413 before processing. See Request limits.
• Blocking work runs off the event loop. /verify/code runs under QWED_CODE_VERIFY_TIMEOUT (default 10 seconds) and returns 503 on timeout. Provider calls for natural_language, logic, and fact run under QWED_PROVIDER_TIMEOUT (default 30 seconds) and fail closed on timeout.
• Bounded batch job store. /verify/batch keeps at most QWED_BATCH_MAX_JOBS jobs (default 1000) and evicts finished jobs first. When every stored job is active, new submissions return 503. Items that exceed QWED_BATCH_ITEM_TIMEOUT are marked failed.
• Sandbox concurrency limit. Each server process runs at most QWED_SANDBOX_MAX_CONCURRENT sandbox containers (default 4). A request that can’t get a slot within QWED_SANDBOX_ACQUIRE_TIMEOUT (default 10 seconds) is rejected with Sandbox capacity reached — retry shortly.

​

v7.2.3 — Code, secret, and SQL verification security release

v7.2.3 is a fail-closed security release covering three advisories published on October 13, 2026: GHSA-6rxr-gq43-694g, GHSA-64xf-wffc-63fm, and GHSA-q5g6-6cw2-cjm3. They affect all versions up to 7.2.2. Upgrading is recommended. No breaking wire changes.

​

Security fixes

• Code verification never admits shell or process execution (GHSA-6rxr-gq43-694g). os.system, os.popen, the os.exec* and os.spawn* families, os.posix_spawn*, os.startfile, subprocess.*, pty.spawn, and asyncio.create_subprocess_* are now blocking process_execution findings. This includes calls through aliased imports such as import subprocess as sp, from os import system as run_it, and from os import *. Before, they were warnings and the code was admitted. verify_code, verify_python_deep, and POST /verify/code are covered. See Code engine.
• Project-scoped OpenAI keys are detected (GHSA-64xf-wffc-63fm). ConfigGuard and the code verifier detect sk-proj-, sk-svcacct-, and sk-admin- keys as well as legacy keys. See ConfigGuard.
• SQL in executable comments and tables outside the schema are rejected (GHSA-q5g6-6cw2-cjm3). Executable comments (/*! ... */, /*!NNNNN ... */, /*M! ... */) are expanded before analysis, so the SQL inside them is checked. With schema_ddl, a query on an undeclared table is BLOCKED with sql_verifier.schema_violation instead of being admitted with a warning. CTE names are not treated as tables. See SQL engine.

​

Soundness eval

​

Version bumps

​

Upgrading

​

QWED-A2A — request size limits, engine budget, and code guard hardening

Four fail-closed fixes to the A2A runtime. Oversized requests are rejected before they reach an engine. Engines run off the event loop under a wall-clock budget. The code guard sees through aliases and re-bindings. TrustBoundary is safe to share across threads.

​

What changed

• max_payload_size_bytes is enforced. It was declared but never read. POST /a2a/intercept returns 413 for bodies over the limit plus a 64 KiB envelope allowance, before buffering. An invalid Content-Length returns 400. intercept() returns blocked with engine size_limit for oversized payloads, which also covers library callers. The code guard blocks code over 256 KiB before parsing and returns unverifiable for non-string code. Keep a reverse-proxy body limit too.
• Engine execution budget. New engine_timeout_seconds config (float, default 5.0, greater than 0 and at most 60). Engines run on a dedicated pool (4 running, 32 waiting), so health, metrics, and JWKS stay responsive. A timeout returns error with engine engine_timeout. Overload returns error with engine engine_busy. Call the new A2AVerificationInterceptor.close() from your shutdown hook. A run that already started cannot be killed, and long calls that hold the GIL can still delay the loop.
• Code guard alias detection. The AST layer resolves import aliases, alias chains, re-bound functions, and annotated, walrus, and tuple-unpacking bindings. It also blocks posix, nt, builtins, and __builtins__ receivers, os exec/spawn/posix_spawn/startfile, star imports from dangerous modules, and getattr on a dangerous module. Known gaps are documented. A clean scan stays a non-admissible heuristic_pass.
• Thread-safe TrustBoundary. Every public method runs under a re-entrant lock. Rate limits hold under concurrency, and eviction no longer races. Trust scopes are snapshotted as frozensets at grant time.

​

QWED-Tax v0.2.1 — classification claim vocabulary and strict facts

qwed-tax v0.2.1 is a security patch. Upgrading is recommended for all users of NexusGuard (Python and npm) and ClassificationGuard. The release also ships the structured nexus claim described in the August 31 and September 1 entries.

# Before: "1099 contractor" was matched by substring and treated as 1099.
# After: verified=False with an INVALID_CLAIM audit trace outcome.
guard.verify_classification_claim(
    llm_claim="1099 contractor",
    facts={"provides_tools": False, "reimburses_expenses": False, "indefinite_relationship": False},
)

# After: pass a canonical claim and boolean facts.
guard.verify_classification_claim(
    llm_claim="1099",
    facts={"provides_tools": False, "reimburses_expenses": False, "indefinite_relationship": False},
)

​

What changed

• Closed claim vocabulary. ClassificationGuard.verify_classification_claim maps the claim through a fixed set of values instead of substring matching. W2, W-2, and EMPLOYEE map to employee. 1099, 1099-NEC, CONTRACTOR, and INDEPENDENT CONTRACTOR map to contractor. Matching ignores case, spaces, hyphens, and underscores. Any other text fails closed with INVALID_CLAIM.
• Strict worker facts. provides_tools, reimburses_expenses, and indefinite_relationship must all be present booleans. Otherwise the result fails closed with INVALID_FACTS. Strings such as "no" are rejected.
• TaxPreFlight hire intents. The same vocabulary and fact rules apply to worker_type and worker_facts.
• npm NexusGuard fails closed. The @qwed-ai/tax NexusGuard blocks states that are not in its threshold table and rejects invalid sales data, including non-object, non-finite, and negative values. The transaction-count prong applies only to states that have one.
• npm classification unchanged. The npm SDK still compares worker_type exactly. Pass "W2" or "1099".

​

Migration

​

QWED-Legal v0.5.1 — DeadlineGuard signing-anchor allowlist

Security patch. DeadlineGuard now computes a deadline from signing_date only for terms measured forward from signing. Upgrade if you use DeadlineGuard through the Python API, the npm SDK, or the GitHub Action.

# Before: computed signing + 30 days and could return verified=True.
# After: UNVERIFIABLE with an UNSUPPORTED trace step.
guard.verify(signing_date="2026-01-15", term="30 days before signing", claimed_deadline="2026-02-14")
guard.verify(signing_date="2026-01-15", term="30 days after closing", claimed_deadline="2026-02-14")

# Migration for a forward term anchored to another event:
# confirm the event date, pass it as signing_date, and rewrite the term.
guard.verify(signing_date="2026-03-02", term="30 days", claimed_deadline="2026-04-01")

​

What changed

• Signing-anchor allowlist. DeadlineGuard computes from signing_date only when the term is bare-relative ("30 days") or explicitly anchored to signing or execution ("30 days from signing", "15 days after execution"). Every other term fails closed with UNVERIFIABLE and an UNSUPPORTED trace step.
• Directional terms fail closed. Terms using before, prior to, ahead of, or preceding were previously computed forward from signing, which could certify the opposite direction.
• Any non-signing event anchor fails closed. Anchors outside the earlier event list, such as "after closing", "after completion", or "within 30 days of request", are now rejected. The open-ended event-noun list is replaced by an allowlist of signing-anchored phrasings.
• Check runs before date arithmetic. Rejected business-day terms never consult the holiday calendar.
• npm engine version gate. DeadlineVerifier in @qwed-ai/legal rejects its promise when the importable Python qwed-legal is older than 0.5.1. An npm-only upgrade cannot silently keep the old deadline engine. Upgrade both packages:

pip install "qwed-legal>=0.5.1"
npm install @qwed-ai/legal@0.5.1

​

v7.2.2 — Verification soundness and safety hardening

v7.2.2 is a fail-closed security release covering four coordinated advisories. They affect all versions up to v7.2.1. No new capability and no breaking wire changes. Upgrade is recommended for any deployment on v6.0.0 through v7.2.1.

​

Security fixes

• Local SDK math verification. The SymPy expression validator in QWEDLocal now rejects string literals nested inside container arguments. This closes an allow-list bypass that could route untrusted model output to SymPy’s string-evaluation path.
• Logic verification soundness. The Z3 constraint evaluator no longer accepts Python boolean operators (and, or, not) or chained comparisons (a < b < c) on symbolic objects. The DSL compiler now rejects string literals instead of materializing them as variables. Both cases could previously yield a VERIFIED verdict that did not follow from the input.
• Large-number math verification. verify_math now compares results at a precision scaled to the operands. Values beyond 15 significant digits are no longer rounded before the comparison, so a wrong claim on a large number can no longer pass as VERIFIED.
• Computational cost bounds. The math parser applies its compute-cost gates to implicit-multiplication input (2x, 3(x+1)). The logic and DSL engines bound statically known integer powers. Short requests can no longer exhaust a worker.

​

Version bumps

​

Upgrading

pip install "qwed==7.2.2"
npm install @qwed-ai/sdk@7.2.2
cargo add qwed@7.2.2

​

QWED Open Responses v0.6.1 — ToolGuard verifies client action items

ToolGuard now checks Responses API items that ask your client to run shell commands, apply patches, or control a computer. Before v0.6.1, these items read as tool-free content and passed. Upgrade from v0.6.0.

# Before: local_shell_call items passed a default ToolGuard
ToolGuard()

# After: opt out of the defaults and allowlist the action tools you run
ToolGuard(
    use_default_blocklist=False,
    blocked_tools=["bash", "sh", "powershell"],
    allowed_tools=["local_shell", "apply_patch"],
)

new ToolGuard({
  useDefaultBlocklist: false,
  blockedTools: ["bash", "sh", "powershell"],
  allowedTools: ["local_shell", "apply_patch"],
});

​

What changed

• Client action items are tool calls. ToolGuard normalizes local_shell_call, shell_call, apply_patch_call, computer_call, custom_tool_call, and mcp_approval_request items into tool calls. Blocklist, allowlist, dangerous-pattern, and validator checks apply. This covers direct items, output[] of a response object, tool_calls[] entries, and the streaming middleware.
• Canonical tool names. Action items are checked as local_shell, shell, apply_patch, and computer_use. Custom tool and MCP approval items use their own name. local_shell argv lists are also scanned as a joined command line.
• Unknown executable items fail closed. Any other *_call or *_request item in a streamed item, output_item event, or output[] of a response object is blocked. Provider-hosted items (web_search_call, file_search_call, code_interpreter_call, image_generation_call, mcp_call) keep their existing behavior.
• Ambiguous action items fail closed. An action item that also carries a tool_call, function_call, function, or tool_calls envelope is blocked. So is a named item whose tool_name or toolName disagrees with name.

​

What this means for you

• If your agent runs local shell, patch, or computer-use tools, configure ToolGuard with use_default_blocklist=False and an allowed_tools allowlist.
• If you rely on the default blocklist for shells, re-add those names through blocked_tools when you opt out.

​

QWED-Finance v3.0.1 — ISO 20022, sanctions, and QueryGuard security fixes

qwed-finance v3.0.1 is the current release. It fixes three security advisories. Upgrade from v2.1.0 or v3.0.0.

​

What changed

• ISO 20022 business rules read the parsed document (GHSA-mrrj-6m2q-jch9). CrossGuard.check_business_rules, verify_iso20022_with_rules, and UCPIntegration.verify_iso20022_payment take amounts and currencies from the parsed XML tree instead of regex over raw text. Amounts with child nodes, exponents, or grouping separators fail closed.
• Sanctions screening resists in-word perturbations (GHSA-mv2c-jwm9-pfrq). Diacritics and look-alike letters are folded, and separator-free names are compared, so E.V.I.L. CORP or ÉVIL CORP no longer clears an EVIL CORP entry.
• QueryGuard rejects MySQL executable comments (GHSA-q8r4-6gpp-5fx2). Queries containing /*! ... */ or /*M! ... */ are unsafe in every QueryGuard check and in CrossGuard.verify_query_with_pii_protection.

​

Included from v3.0.0 (September 27, 2026)

• Breaking (npm): the @qwed-ai/finance bridge sends JSON over stdin with runtime validation. Malformed inputs are rejected instead of falling back to defaults.
• VerificationReceipt.get_signature(key): keyed HMAC-SHA256 over all 15 receipt fields, with no default key. The unkeyed get_signature() was removed.
• ISO currency and amount business limits in receipts and UCP. UCPIntegration.verify_iso20022_payment takes kyc_verified and requires it to approve.
• Fail-closed AML, sanctions, amount, and message-validation fixes.

​

QWED-Legal — fail-closed date handling and input bounds

DeadlineGuard and StatuteOfLimitationsGuard no longer guess what a date means. Order-ambiguous dates, partial dates, and event-anchored terms now return UNVERIFIABLE instead of a confident verdict. ClauseGuard and ContradictionGuard gain input bounds.

# Before: "03/04/2026" was read month-first (March 4) and the claim verified.
# After: UNVERIFIABLE with an AMBIGUITY_NOTED trace step.
guard.verify(signing_date="03/04/2026", term="30 days", claimed_deadline="2026-04-03")

# Before: computed 30 days from signing.
# After: UNVERIFIABLE, because the clock starts at receipt, not signing.
guard.verify(signing_date="2026-01-01", term="30 days after receipt", claimed_deadline="2026-01-31")

​

What changed

• Order-ambiguous numeric dates fail closed (#90). DeadlineGuard and StatuteOfLimitationsGuard, including computation-only mode, return UNVERIFIABLE with an AMBIGUITY_NOTED trace step for dates such as 03/04/2026 that read differently month-first and day-first.
• Partial dates fail closed (#91). Inputs such as "March 2024", "Friday", or "23:00" would be completed from the system clock, so both guards reject them. In both cases, parsed datetimes in the result are None and the raw strings stay in the trace. DeadlineGuard.calculate_business_days_between() raises ValueError for these dates.
• Event-anchored terms fail closed (#92). DeadlineGuard returns UNVERIFIABLE for terms that start the clock at receipt, notice, delivery, occurrence, demand, invoice, breach, termination, service of process, or payment. It no longer computes those deadlines from the signing date.
• Deadline comparison by calendar date (#92). Claimed and computed deadlines are compared by date, not timestamp. Timezone-aware claims are converted to the computed deadline’s timezone. Mixed timezone-aware and naive inputs return UNVERIFIABLE. tolerance_days stays in whole days.
• ClauseGuard input bounds (#89). check_consistency() returns invalid_input for more than 200 clauses or any clause over 4,096 characters. It reports at most 100 conflict pairs and adds a truncation notice when it stops.
• Digit-run bound (#89). Digit runs longer than 18 characters fail closed in DeadlineGuard terms, ClauseGuard day counts, and ContradictionGuard operands.
• Faster US citation patterns (#89). CitationGuard US patterns no longer slow down on adversarial input.
• Added — npm SDK (#93). JurisdictionVerifier.verifyChoiceOfLaw() in @qwed-ai/legal accepts an optional fourth contractType argument and passes it to the guard as contract_type. JurisdictionResult adds optional contractType and contractClassification (goods, declared_non_goods, or unclassified) fields. Omitting contractType keeps the existing partial-coverage warning. The 0.5.0 npm package is published as @qwed-ai/legal.

​

What this means for you

• Normalize dates to ISO YYYY-MM-DD before calling the deadline and statute guards.
• For event-anchored deadlines, pass the event date as signing_date and drop the anchor from the term. The result reports that date as signing_date, so keep the real signing date separately.
• Treat invalid_input from check_consistency() on oversized clause lists as a rejection, not a pass.

​

QWED Open Responses v0.6.0 — fail-closed hardening

SchemaGuard now rejects undeclared root fields by default, verification is resource-bounded, and ToolGuard, the streaming middleware, and the Express middleware close several bypasses. The Python and npm packages both move to 0.6.0.

# Before: extra root fields passed silently
SchemaGuard(schema)

# After: opt out explicitly to allow them
SchemaGuard(schema, allow_additional_properties=True)

new SchemaGuard(schema, { allowAdditionalProperties: true });

​

What changed

• SchemaGuard cross-language parity. JSON Schema format validation for email, uuid, date-time, uri, and ipv4 now matches across Python and npm.
• Resource-bounded verification. JSON responses over 100,000 characters or 100 nesting levels, and responses with oversized integers, return a failed verdict instead of raising an exception. SafetyGuard scanning fails closed above 10,000 nodes, 100,000 characters, or 12 nesting levels. Email PII detection uses a linear-time scan.
• SchemaGuard reports the first error only. Failed results carry one error, with the total error count reported as unknown (total_errors=None, errors_truncated=True).
• ToolGuard raw argument scanning. Dangerous patterns run on the raw parsed argument strings, including nested values and JSON-encoded calls, so custom patterns match across tabs and newlines. Cyclic or too-deep arguments still fail closed.
• ToolGuard name and command normalization. Blocked tool names are normalized for case, surrounding whitespace, dashes, underscores, and camelCase. The default blocklist adds run_command, execute_command, command_line, and terminal. Command checks catch comment-separated keywords, spaced dots, and reordered rm flags, including inside JSON- and base64-encoded arguments. Allowlist entries still require the exact configured separators. Custom validator keys match case and whitespace but don’t merge distinct names.
• Streaming tool-call verification. OpenResponsesMiddleware.verify_stream verifies each tool item in its original shape before yielding it. Tool-call types are normalized for case and whitespace. Unknown, ambiguous, or nested tool-shaped items are blocked. tool_result and function_call_output items pass through when their correlation metadata is valid. ArgumentGuard and TaxGuard checks cover batched and nested calls.
• SafetyGuard scans field names and quoted credentials. Object field names are now checked for PII and prompt injection, not only values. Quoted JSON credentials such as "api_key": "sk-..." are blocked. Documented placeholders stay exempt.
• npm SafetyGuard configuration parity. The TypeScript SafetyGuard accepts customPatterns and piiAllowList. Each matched custom pattern blocks and reports its own custom_pattern finding. Invalid patterns throw at construction, and a pattern that exceeds its 25 ms execution limit fails the check. piiAllowList accepts camelCase and snake_case names, such as ipAddress and ip_address.
• ToolGuard envelope hardening. Envelopes that carry conflicting tool identities at the root, in a nested call, or in a function wrapper are blocked. Configured ToolGuards now check structured_output responses too. Nested scans that reach the depth limit block instead of reporting “No tool calls”.
• Verification context propagation. A context with usage caps now flows through verify_tool_call, verify_structured_output, and the OpenAI, streaming, LangChain, and LlamaIndex integrations. The OpenAI wrapper takes it as verification_context and doesn’t send it to OpenAI. The streaming middleware carries running total_cost and total_tokens forward, so later items can hit SafetyGuard budget limits.
• Express middleware fails closed on unparsed bodies. The npm verifyRequestBody middleware returns HTTP 422 when a request declares a body but has no parsed body, even with blockOnFailure: false. Bodyless requests and parsed empty JSON continue.

​

What this means for you

• Review SchemaGuard schemas for responses that carry extra root fields, and declare them or opt out.
• If you use the Express middleware, register a body parser such as express.json() before it.
• If ToolGuard now blocks your structured outputs or wrapped tool calls, give each call a single tool identity.
• To enforce budgets across a stream or agent run, pass usage totals in the verification context.

​

QWED-Legal — fail-closed hardening for guards, diagnostics, and GitHub Action

Five QWED-Legal paths that could report success over empty, blank, or unclassified input now fail closed. The QWED Legal GitHub Action now passes only on deterministic proofs.

​

What changed

• LiabilityGuard.verify_tiered_liability: empty tier lists. tiers=[] returns UNVERIFIABLE with total_computed=None and no proof_ref, whether claimed_total is zero or not.
• ProvenanceGuard: strict required fields. content_hash, model_id, and generation_timestamp must be non-empty strings. None, 0, False, [], and whitespace now give INCOMPLETE_PROVENANCE. Checks that cannot run are recorded as hash_integrity_skipped, timestamp_valid_skipped, and model_allowed_skipped instead of CONTENT_TAMPERED or UNAUTHORIZED_MODEL.
• JurisdictionGuard: blank party entries. check_convention_applicability() returns UNVERIFIABLE for blank entries such as [""]. Genuine negatives such as ["XX"] stay deterministic.
• JurisdictionGuard: three-way contract_type classification for CISG. Goods contracts (separator and case variants accepted, bare "sale" excluded) get the CISG warning. Declared non-goods contracts such as "services" get no CISG warning. Missing, blank, or unknown values get a partial-coverage warning and are not verified. The US and non-US party pair no longer triggers the CISG warning by itself. The classification is recorded in trace inputs.
• Diagnostics: no proof_ref without a deterministic step. LegalDiagnosticResult.verified() raises unless the evidence trace has a DETERMINISTIC step. Traceless or transport-stripped "consistent" verdicts and empty claim_texts are demoted to UNVERIFIABLE. Blank messages fall back to defaults instead of crashing.

​

QWED Verification — qwed init server identity handshake

qwed init now proves that the local server holds this project’s secrets before it bootstraps an API key. Previously, a healthy /health only proved that something answered on the port. A foreign process or a stale server running older secret values could receive the bootstrap and issue a key that stops working after a restart.

​

What changed

• New GET /health/identity endpoint. Takes a caller-supplied nonce (1–128 characters) and returns HMAC-SHA256 proofs over it under QWED_JWT_SECRET_KEY and QWED_API_KEY_LOOKUP_SECRET. Returns 400 for a missing or oversized nonce and 503 when server secrets aren’t configured. The secrets never leave the server. See GET /health/identity.
• Nonce-bound, replay-safe handshake. qwed init generates a fresh nonce on every run and compares the proofs against locally computed values in constant time. A captured response is useless for any later handshake.
• Runs on reused and freshly spawned servers. A reused server can be foreign or stale even when secrets were retained. A fresh spawn can lose a port race after the health poll.
• Fails closed. A mismatch, a 404 from an older server, any other non-200 status, a malformed response, an unreachable server, or missing local secrets stops qwed init with exit status 1 before any key is issued. Each message tells you to restart the local server or re-run qwed init.

​

QWED Verification — leaked API key auto-revocation and false-positive feedback

Verified reports from POST /webhooks/secret-scanning now trigger enforcement. QWED automatically revokes any matching active API key, records a security event, and emails the key owner. An opt-in reporter can send true-positive and false-positive labels back to the scanning service.

​

What changed

• Automatic revocation. A verified match against an active key sets is_active=False and revoked_at, and writes a SECRET_LEAK_AUTO_REVOKED security event. The event records only the key_preview. The plaintext token is never persisted, logged, or emailed.
• Owner notification. QWED emails the key’s user, falling back to the organization’s first active owner or admin. SMTP phases time out after 10 seconds. Revocation is committed first and is never rolled back if notification fails.
• Idempotent handling. Already-revoked keys and unknown tokens are not acted on. Redelivered or concurrent reports revoke and notify exactly once. Registered scanner patterns cover qwed_live_ keys only, so qwed_test_ keys are never reported.
• False-positive feedback reporter (opt-in). Set QWED_LEAK_FEEDBACK_ENABLED=true and QWED_LEAK_FEEDBACK_URL to POST one label per match after the revocation attempt. Items carry SHA-256 token hashes by default. QWED_LEAK_FEEDBACK_SEND_RAW=true is a separate explicit opt-in to send plaintext tokens, and only works with an HTTPS URL.

​

QWED Verification — canonical API-key format spec

QWED now publishes a canonical, machine-readable specification of its API-key formats, with lookaround-anchored scanning regexes and synthetic test vectors. Use it to build secret scanners, leak detectors, and SDK-side format validators.

​

What changed

• v2 checksummed format documented. Current keys match qwed_live_[A-Za-z0-9]{36}: 30 random Base62 characters followed by a 6-character Base62 CRC32 checksum that you can validate offline.
• Legacy v1 still accepted. Keys matching qwed_live_[A-Za-z0-9_-]{43} keep working and are never force-rotated.
• qwed_test_ exclusion. Scanners must exclude test keys from high-confidence production-secret matching.
• Lookaround-anchored regexes. Published patterns use charset-complement lookarounds instead of \b, because a v1 body can end in -. RE2-compatible delimiter-class alternatives are included.
• Masking guidance. Masked previews show the prefix, asterisks, and only the last 4 characters.
• Machine-readable spec and test vectors. spec/api-key-format.json and spec/api-key-test-vectors.json in the qwed-verification repository.

​

QWED Verification — signed secret-scanning webhook endpoint

New POST /webhooks/secret-scanning endpoint receives signed reports of leaked QWED API keys from GitHub secret scanning and compatible partner scanners. The endpoint is unauthenticated at the transport layer by design — external scanners have no QWED credentials — and the ECDSA-NIST-P256V1-SHA256 signature over the raw request body is the only credential. Verification runs before any JSON parsing, logging, or database work, and every failure mode fails closed to a distinct status code.

​

What changed

• New public endpoint. POST /webhooks/secret-scanning accepts a JSON array of leaked-token matches, verifies the Github-Public-Key-Identifier and Github-Public-Key-Signature headers against GitHub’s published signing keys, and hands verified batches to the revocation sink in the background. See POST /webhooks/secret-scanning for the full request/response contract.
• Raw-body signature verification. The signature is verified over the exact bytes received; the body is never re-serialized. Nothing in the payload is parsed or logged until the signature is proven genuine.
• P-256 pinning at key-load. Signing keys are pinned to secp256r1 when the PEM is loaded, so a future keys-list entry on another curve is dropped at load rather than silently trusted at verify time.
• 6-hour key cache with rotation retry. Signing keys are cached in-process for 6 hours with an ETag-conditional refetch. On an unknown key_identifier, QWED refetches the list exactly once (throttled to one forced refetch per 60 s after a success, 10 s after a failure) and retries. A dead or throttled key service fails closed to 503.
• Timing-safe verdict comparison. Success and failure branches run through hmac.compare_digest on a fixed-shape verdict, and every failure returns the same generic detail so the failing step is not observable.
• Fail-closed status separation. 401 for missing headers, 403 for a proven-bad signature against a fresh anchor, 503 for any state where verification was impossible (signing-key service down, anchor unusable, rotation retry throttled). 413 for over-cap bodies (1 MiB) or batches (500 matches); 400 for a malformed envelope. Tokens never appear in logs.
• Optional keys-fetch token. GITHUB_KEYS_TOKEN (or GITHUB_TOKEN as a fallback) can be set to raise the outbound rate limit on the keys request. Neither token grants any authority over the incoming webhook — only the signature does.

​

QWED Verification — qwed init provisions QWED_API_KEY_LOOKUP_SECRET

Fresh qwed init runs no longer crash the child server at boot on the fail-closed QWED_API_KEY_LOOKUP_SECRET import check. The CLI now generates the lookup secret alongside QWED_JWT_SECRET_KEY, writes it to .env, and threads it into the local server it starts.

​

What changed

• Auto-provisioned on first run. qwed init generates a URL-safe random QWED_API_KEY_LOOKUP_SECRET (at least 48 bytes) whenever one is not already set, persists it to .env with the same 0600 permissions as other credentials, and exports it into the child server’s environment.
• Retained on re-runs, never rotated. If .env, the process environment, or the project-root .env already holds a value, qwed init reuses it verbatim. Rotating this secret invalidates every stored API-key lookup digest, so the CLI will not do it for you.
• Refuses to persist an unbootable value. If the existing QWED_API_KEY_LOOKUP_SECRET equals QWED_JWT_SECRET_KEY, qwed init exits with an error instead of writing a value the server would refuse to start with. Remove the offending line (a fresh distinct value is generated) or set a distinct value manually.
• Stale-secret guard around the local server. If qwed init regenerates a missing secret but a QWED server is already running with older values, the CLI stops before bootstrapping a new API key — issuing one against a server that cannot verify it would produce a key that dies on the next restart.

​

QWED-A2A — /a2a/intercept requires per-agent API keys (breaking)

The FastAPI gateway’s POST /a2a/intercept endpoint previously trusted the body-declared sender_agent_id — any caller could impersonate any agent for trust evaluation, rate limits, and attestation. The endpoint now authenticates every request with a per-agent API key in the X-API-Key header, validated against the QWED_A2A_API_KEYS environment variable. The authenticated identity overrides the body’s sender_agent_id everywhere it matters. The dead AgentMessage.signature field, which was never verified, is removed.

​

What changed

• Per-agent API-key authentication — QWED_A2A_API_KEYS holds a JSON object mapping each key to its agent ID, e.g. {"key-abc123": "procurement-agent"}. Missing, unknown, or unconfigured keys return 401. Keys are compared in constant time.
• Authenticated identity wins — trust-boundary evaluation, token-bucket rate limiting, telemetry, and the attestation JWT all bind to the key’s agent ID. If the body’s sender_agent_id differs, the gateway logs a warning and overrides it. Direct library callers of intercept() get no override and own identity binding themselves.
• No-restart key rotation — the key map is read fresh on every request. Update the environment variable and old keys stop matching immediately.
• Agent-ID normalization — map entries are trimmed and validated against the AgentMessage contract (max 256 chars, no control characters); invalid entries are dropped and their keys denied.
• AgentMessage.signature removed — the optional field was documented as “JWT signature for tamper detection” but was never read by any verification path. Attestation integrity comes from the verdict JWT, not a caller-supplied field.

​

Migration

curl -X POST http://localhost:8000/a2a/intercept \
  -H "Content-Type: application/json" \
  -d '{"sender_agent_id": "agent-A", "receiver_agent_id": "agent-B", "payload_type": "general", "payload": {"message": "Hello!"}}'

export QWED_A2A_API_KEYS='{"key-for-A": "agent-A"}'

curl -X POST http://localhost:8000/a2a/intercept \
  -H "Content-Type: application/json" \
  -H "X-API-Key: key-for-A" \
  -d '{"sender_agent_id": "agent-A", "receiver_agent_id": "agent-B", "payload_type": "general", "payload": {"message": "Hello!"}}'

​

QWED-A2A — cross-deployment trusted issuers and jti replay lifecycle (security release)

Two fixes to A2ACryptoService attestation verification. Peer deployments can now be registered as trusted issuers, so verifying another deployment’s attestations no longer tempts operators into sharing one private key across deployments. And the jti replay registry now separates issuance from consumption: an issuer can verify its own token once, duplicate trace_ids are rejected at signing, and the consumption registry is injectable for cross-worker replay protection.

​

Cross-deployment verification (PR #108)

• Trusted issuers. verify_attestation accepts an optional trusted_issuers mapping of issuer IDs to {"deployment_id": ..., "jwks": ...}, with the QWED_A2A_TRUSTED_ISSUERS environment variable as fallback. Register a peer by copying its /.well-known/jwks.json entry verbatim. The env var is re-read on every verification, so key rotation needs no restart.
• Fail-closed on every mismatch. Unknown issuers, kid mismatches, and deployment_id mismatches all deny. Routing never trusts unverified claims: header and payload are read only after a candidate key verifies the signature, and one public key registered under two issuer identities keeps only the first identity.
• Verifier-only nodes. A node with no local signing key can verify peer tokens against trusted issuers. Only signing, JWKS publishing, and the interceptor still require QWED_A2A_SIGNING_KEY_PEM. With neither a local key nor trusted issuers, verification returns No verification keys available instead of raising.
• Peer jti namespacing. Replay tracking for peer tokens is namespaced per issuer, so two deployments reusing the same trace ID never shadow each other.

​

jti registry lifecycle (PR #109)

• Issuance/consumption split. sign_verdict records the trace_id in a separate per-instance issuance record instead of the consumption registry, so an issuer can verify its own token once — the second presentation is a replay.
• Duplicate trace IDs rejected at signing. Reusing a trace_id within its validity window raises ValueError at sign_verdict instead of minting two tokens under one jti.
• Injectable consumption registry. A2ACryptoService(jti_registry=...) accepts a shared registry (Redis, database) for cross-worker replay protection. The default remains process-local: two workers in two processes share nothing. Injected registries must provide atomic insert-if-absent, retention covering token lifetime, and a numeric ttl_seconds at least validity_seconds — anything less raises ValueError at construction.

​

Upgrading

​

v7.2.1 — Math answer comparison security patch

v7.2.1 is a fail-closed security patch. The math answer comparison path previously fed the untrusted model answer to raw sympy.sympify, which is an eval sink that can execute dunder-traversal gadgets smuggled in the answer turn. The answer is now parsed only through the hardened safe_parse_expr, and unparseable input fails closed. No new capability and no breaking wire changes. Upgrade is recommended for any deployment on v6.0.0 through v7.2.0.

​

Security fix

• Hardened answer parsing. QWEDLocal._math_answers_match no longer calls sympy.sympify on the model’s answer. It now parses through safe_parse_expr, which applies a character allow-list, an AST allow-list, strips builtins, and enforces the compute-cost bounds introduced in v7.2.0. Unparseable answers and a missing parser both return False, so the comparison never treats an attacker-controlled string as “equal” by accident.
• Release boundary gate covers the SDK. scripts/check_boundary.py now scans qwed_sdk/ and forbids raw sympify outside approved wrappers, so the eval sink cannot reappear in a future refactor.

​

Version bumps

​

Upgrading

​

v7.2.0 — Precision advisory and security hardening batch

v7.2.0 unifies the precision advisory capability and the security hardening batch across all SDKs. One additive capability — an advisory flag for binary floating-point constants in math and stats verification — plus fail-closed fixes: bounded engine-call waits, sandbox containment, and event-loop offload. The release is a semver minor with no breaking wire changes.

​

Precision advisory (new capability)

• AdvisoryCheck.float_precision() parses the verification source and, when float or complex constants are present, returns an advisory with constraint_id: "precision.float-constants" listing the offending constants and suggesting decimal.Decimal or SymPy exact rationals where exact arithmetic matters.
• /verify/math attaches the advisory to the result on all branches, before trust enforcement.
• StatsVerifier.verify_stats carries the advisory on completed analyses when the generated code uses floats — the expected shape for numpy/pandas code, so it flags without disrupting.
• Advisory, never a gate. Execution-safety gates decide what may run, not what is exact. Documented inputs like 1000 * (1 + 0.05)**2 legitimately contain floats and still verify. Unparsable input returns no advisory; parse failures belong to the security gates.

{
  "developer_fields": {
    "advisory_checks": [
      {
        "name": "floating-point-constants",
        "advisory_only": true,
        "constraint_id": "precision.float-constants",
        "details": {
          "constants": ["0.1", "0.2"],
          "note": "Binary floating-point values can be inexact; results may differ from exact decimal arithmetic.",
          "suggestion": "Use decimal.Decimal or SymPy exact rationals (sympy.Rational) where exact arithmetic matters."
        }
      }
    ]
  }
}

​

Engine-call bounds (PR #354)

• SymPy compute-cost gate. The safe expression parser adds a computational-cost layer: integer-literal cap (10^300), static exponent bound (10^4), exact-expansion bounds on factorial/binomial calls, caret-chain fold bounds, and a nested-power base-magnitude budget. Expressions like 2**factorial(10000) or ((9**9)**9999)**9999 are rejected before they can reach SymPy’s eager exact expansion. All cost comparisons use exact arithmetic, never binary floats.
• Provider HTTP timeouts. All six LLM provider clients are pinned to a 30-second timeout with zero SDK-level retries. The previous SDK defaults allowed roughly 30 minutes per stalled call. Retry policy belongs to the caller.
• Stats upload cap. /verify/stats gains a byte-counting body-limit middleware with a 30-second read deadline and an in-flight concurrency cap, a 10 MB file cap with header preflight, and an early abort at 1 million cells.

​

Sandbox containment (PR #351)

• Log rotation and process caps. Sandbox containers run with json-file log rotation (10 MB, single file) and pids_limit=128.
• Guaranteed container removal. Containers are force-removed in a finally block covering the whole post-creation lifecycle, with create-then-start ordering so start failures cannot leak, one retry for transient daemon races, and a warn-only fallback so cleanup failure never discards a valid verification result.
• Result size caps. result.json is capped at 2 MB both inside the container wrapper (streamed, aborts at cap) and at host read-back before parsing. observed_result and every VerificationLog.result site are bounded by a shared pre-encode traversal with per-string caps, an aggregate budget, and cycle markers, and remain valid JSON for the audit integrity verifier.

​

Event-loop offload (PR #352)

• Consensus now awaits an async path with a per-call executor sized to the engine list, one aggregate deadline, and per-engine timeouts. Timed-out, errored, or circuit-open engines degrade to partial BLOCKED results with correct circuit-breaker recording instead of hanging the request.
• Stats offloads CSV parsing and the verification chain to a worker thread, and every Docker daemon call is bounded at 30 seconds.

​

Version bumps

​

Included PRs

​

Upgrading

​

QWED Verification — all-tenant metrics restricted to explicit platform operators (security release)

GET /metrics and GET /metrics/prometheus exposed every organization’s request volumes, latencies, provider usage, and per-tenant breakdowns to any self-service signup. The access gate treated the organization-scoped owner/admin role as platform-wide authority, and since signup is the only user-creation path — hardcoding role="owner" for every new account — the gate degenerated to “possess any account,” one anonymous request away. Access is now an explicit operator allowlist, fail-closed when unset.

​

What changed

• Operator allowlist. All-tenant metrics require the caller’s user ID to be listed in QWED_METRICS_OPERATOR_USER_IDS (comma-separated). The list is read per request, so granting or rotating operators takes effect without a restart.
• Org roles are no longer platform authority. owner and admin remain meaningful inside their own organization; they confer no cross-tenant access anywhere.
• API-key path hardened. A key resolves through its owning user, who must be on the allowlist. Expired (expires_at) or revoked (revoked_at) keys are no longer usable credentials — but they also no longer preempt a valid operator JWT presented in the same request. Key-only callers without a valid credential are still denied.
• Fail-closed by default. With the variable unset, both endpoints deny every caller. Per-tenant metrics (GET /metrics/{organization_id}) are unchanged.

​

Behavior changes

​

QWED Verification — float precision advisory for math and stats verification

Math and stats inputs may contain binary floating-point constants (0.1 + 0.2, 1e9) whose evaluation can be inexact relative to decimal arithmetic. A new advisory surfaces that signal without gating anything: it is a precision advisory, never a rejection, because execution-safety gates decide what may run, not what is exact.

​

What changed

• precision.float-constants advisory. When an expression or generated statistics code contains float or complex constants, the result carries an AdvisoryCheck in developer_fields.advisory_checks listing the offending constants and suggesting decimal.Decimal or exact SymPy rationals.
• /verify/math. The advisory is attached on all result branches. The submitted expression is checked lexically, so equations (0.1 + 0.2 = 0.3, 0.5x = 0.5x) and collapsing forms retain their float literals even when symbolic simplification would eliminate them. Scientific notation and complex literals (1.0j) are flagged too.
• Stats verification. The completed-analysis result carries the advisory when the generated code uses floats — the expected shape for numpy/pandas code, so it flags without disrupting.
• Structurally non-verdict-affecting. AdvisoryCheck enforces advisory_only=True at construction. The advisory cannot change the verification status or proof_ref. Unparsable input yields no advisory; parse failures belong to the security gates.

​

QWED Verification — structural math parser and sandbox gate hardening (security release)

Two security fixes close sandbox-escape bypasses in math expression parsing and sandboxed code execution. The math parser now validates expressions structurally (NFKC normalization, ASCII charset gate, AST node allowlist) instead of relying on a denylist, and the consensus and stats execution paths gained a single-expression structural gate plus a module-indirection blocklist.

​

Math expression parser (PR #344)

• NFKC normalization first. CPython normalizes identifiers at compile time, so Unicode look-alike codepoints (mathematical bold letters, fullwidth forms) could previously slip past string filters. All checks now see exactly what the compiler sees.
• ASCII charset allowlist. Only letters, digits, underscore, whitespace, and + - * / ( ) . , ^ % are accepted. A . is legal only as a decimal point with digits on both sides, which makes attribute access structurally impossible on the implicit-multiplication path.
• AST node-type allowlist. Python-parseable input may contain only arithmetic operators, function calls, names, and numeric constants. Attribute access, subscripts, string constants, lambdas, comprehensions, and comparisons are rejected before evaluation.
• Caret exponentiation fixed. convert_xor joined the default transformation pipeline, so x^2 parses as x**2 instead of failing at evaluation time.
• The regex denylist is retained as defense in depth.

​

Execution gates (PR #346)

• Single-expression gate on translated math. A translated math expression must parse as exactly one Python expression (ast.parse in eval mode). Multi-statement, import-bearing, and multi-line-smuggled input fails by construction. Expressions over 500 characters are rejected before parsing.
• Module-indirection blocklist. The pre-execution AST check on sandboxed code now inspects every dotted segment of imports and attribute chains. Blocked module roots were extended (posix, nt, importlib, ctypes, builtins), OS-primitive call names (system, popen, import_module, the exec*/spawn* families, fork) are matched on bare names and attribute targets, and package-internal re-export gadgets through pandas/numpy internals are caught.
• sys read-only allowlist in the stats executor. Only named read-only interpreter metadata is accessible; frame introspection and every other sys member fail closed.

​

Behavior changes

​

What this means for you

​

QWED Verification — API-key lookup migration and per-IP auth throttling

API-key lookup digests move from PBKDF2 to HMAC-SHA256 keyed by a new required QWED_API_KEY_LOOKUP_SECRET, removing ~67ms of CPU cost from every unauthenticated request. Anonymous /auth/* routes gain a per-IP rate limit, and password hashing no longer blocks the event loop.

​

Breaking changes

# Before (pre-v7.2 key): now rejected
curl -H "X-API-Key: qwed_live_old_key" https://api.qwedai.com/v1/health
# -> 401 Unauthorized

# After: sign in with email/password (no API key needed), then mint a new key
curl -X POST https://api.qwedai.com/v1/auth/signin \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com", "password": "..."}'

curl -X POST https://api.qwedai.com/v1/auth/api-keys \
  -H "Authorization: Bearer eyJhbG..." \
  -H "Content-Type: application/json" \
  -d '{"name": "Production Key"}'

​

What changed

• HMAC-SHA256 API-key lookup. The previous PBKDF2 digest (100,000 iterations, ~67ms) ran on every request carrying an x-api-key header, valid or not, letting ~15 garbage requests per second saturate the service. API keys are high-entropy random tokens, so the KDF cost bought no brute-force resistance. The replacement keyed MAC costs microseconds.
• Dedicated lookup secret (required). Digests are keyed by QWED_API_KEY_LOOKUP_SECRET. Self-hosted servers fail closed at startup if it is missing or equal to QWED_JWT_SECRET_KEY — reusing the JWT secret would silently break every API-key lookup on the next JWT-secret rotation. Set it before issuing v7.2 keys; changing it later requires a one-time re-issue.
• Per-IP rate limit on /auth/*. Anonymous auth routes (signup, signin) are throttled per client IP: QWED_RATE_LIMIT_PER_IP, default 10 requests per minute. Over-limit requests get 429 Too Many Requests with a Retry-After header of at least 1 second. X-Forwarded-For is honored only when the direct peer is listed in QWED_AUTH_TRUSTED_PROXIES (comma-separated CIDRs, default empty), and only the rightmost hop is used, so clients cannot choose their own bucket. The IP table is hard-bounded against spoofed-address floods.
• Password hashing off the event loop. Signup and signin bcrypt calls run in a worker thread instead of blocking the server. Signin also performs a dummy verify on unknown emails, so response timing no longer reveals which addresses are registered.
• Atomic signup. The organization and user rows commit in one transaction; a failure mid-signup rolls back both instead of stranding an orphaned organization.

​

What this means for you

​

QWED-Tax — npm verifier enforces structured nexus claims fail-closed

The @qwed-ai/tax npm verifier now requires the structured boolean claimed_collects_tax claim for economic-nexus checks, matching the Python guard’s contract. Unknown states, non-boolean claims, and malformed sales facts fail closed instead of passing as no-nexus.

​

What changed

• Structured claim required — TaxPreFlight.audit and NexusGuard.checkNexus verify the boolean claimed_collects_tax against the independently computed nexus. Non-boolean values (including strings like "false") are rejected with "Computed nexus liability only. Provide claimed_collects_tax as a boolean for deterministic verification.".
• Legacy fallback narrowed — tax_decision: 'no_tax' maps to claimed_collects_tax: false only when the intent does not contain a claimed_collects_tax key. A present-but-invalid structured claim is blocked even when the legacy string is also set.
• Unknown states fail closed — states not in the npm threshold table (currently NY, CA, TX, FL) return verified: false with a block-pending-configuration error instead of being verified as no-nexus.
• Input hardening — nexus validation runs whenever sales_data is present (including falsy or explicitly undefined values). Non-string state, non-finite amounts (NaN, Infinity), and negative sales or transaction counts are rejected before threshold math.

​

What this means for you

​

QWED-Tax — explicit boolean claim required for economic nexus verification

Economic nexus verification now fails closed unless the caller provides an explicit claimed_collects_tax boolean. Free-form tax_decision / llm_decision text is no longer interpreted as a verification claim — free-form model output cannot be a verification substrate.

​

What changed

• NexusGuard.check_nexus_liability — Gains a keyword-only claimed_collects_tax: bool parameter. The guard computes the state’s threshold independently and verifies the boolean against the computed nexus. When the parameter is omitted, the guard returns {"verified": False, "computed_only": True, "has_nexus": <bool>, "error": "Computed nexus liability only. Provide claimed_collects_tax as a boolean for deterministic verification."}. Non-boolean values (including truthy strings) return verified=False with an invalid-claim error.
• llm_decision deprecated — The parameter is retained for positional compatibility but is never parsed. Passing it has no effect on the verdict.
• TaxPreFlight economic_nexus intents — The required claim field changed from tax_decision (string) to claimed_collects_tax (boolean). Intents that still send tax_decision are blocked as incomplete claims before NexusGuard runs.

​

Breaking changes

# Before
guard.check_nexus_liability("NY", 600000, 10, llm_decision="No tax needed")

# After
guard.check_nexus_liability("NY", 600000, 10, claimed_collects_tax=False)

​

What this means for you

​

QWED Open Responses — fail-closed verification and expanded guard coverage

verify() now fails closed when no guards are configured, ToolGuard recognizes and polices more tool-call envelope shapes, and SafetyGuard scans nested content. All three changes ship in both the Python and TypeScript packages.

​

What changed

• Zero-guard verify fails closed. Absence of verification is not success. A verify() call with no guards returns a ResponseVerifier guard result with severity="error" and the block reason “No guards configured — fail-closed (zero-guard verify).”
• ToolGuard envelope coverage. ToolGuard now extracts tool calls from Anthropic content[].type=tool_use blocks and matches type values case-insensitively, so a Tool_Use block is policed instead of ignored. OpenAI function wrappers and JSON-encoded argument strings are normalized before blocklist and dangerous-pattern checks.
• ToolGuard fail-closed rejections. Tool-like content in an unrecognized shape, non-object entries in tool_calls/choices/content, hybrid envelopes that mix a direct tool call with a sibling collection, nameless tool calls, and argument payloads over 10,000 characters or 128 nesting levels are all blocked instead of passing silently.
• SafetyGuard recursive extraction. SafetyGuard scans string content nested up to 12 levels deep, including the canonical choices[].message.content shape, so PII, injection, and harmful patterns inside nested structures are detected.

​

What this means for you

Economic nexus verification now fails closed unless the caller provides an explicit claimed_collects_tax boolean. Free-form tax_decision / llm_decision text is no longer interpreted as a verification claim — free-form model output cannot be a verification substrate.

​

What changed

• NexusGuard.check_nexus_liability — Gains a keyword-only claimed_collects_tax: bool parameter. The guard computes the state’s threshold independently and verifies the boolean against the computed nexus. When the parameter is omitted, the guard returns {"verified": False, "computed_only": True, "has_nexus": <bool>, "error": "Computed nexus liability only. Provide claimed_collects_tax as a boolean for deterministic verification."}. Non-boolean values (including truthy strings) return verified=False with an invalid-claim error.
• llm_decision deprecated — The parameter is retained for positional compatibility but is never parsed. Passing it has no effect on the verdict.
• TaxPreFlight economic_nexus intents — The required claim field changed from tax_decision (string) to claimed_collects_tax (boolean). Intents that still send tax_decision are blocked as incomplete claims before NexusGuard runs.

​

Breaking changes

# Before
guard.check_nexus_liability("NY", 600000, 10, llm_decision="No tax needed")

# After
guard.check_nexus_liability("NY", 600000, 10, claimed_collects_tax=False)

​

What this means for you

​

QWED-MCP v0.2.2 — hardened math expression sandbox (security release)

qwed-mcp v0.2.2 fixes GHSA-2p69-jpm6-jrxh (CWE-94), a residual sandbox-escape bypass in the math expression parser. The previous regex denylist could be evaded through unlisted dunder names, string-literal splitting, and NFKC-equivalent Unicode identifiers. The parser now validates expressions structurally before any evaluation.

​

What changed

• AST node allowlist. Only arithmetic node types survive (binary and unary operations, calls, names, numeric constants). The allowlist rejects attribute access, subscripts, lambdas, and comprehensions before parsing. Every sandbox-escape traversal needs an attribute or subscript node; legitimate math never does.
• String and bytes literals rejected. The validator fails expressions containing string or bytes constants with SafeParserError, closing the concatenation-gadget class (for example '__glo'+'bals'+'__').
• NFKC normalization before validation. CPython NFKC-normalizes identifiers at compile time, so Unicode look-alike characters (mathematical bold letters, fullwidth forms) could previously bypass the ASCII denylist. The sandbox now normalizes input first, so the checks see exactly what the compiler sees.
• Implicit-multiplication charset guard. Inputs that are not valid Python (such as 2x or sin x) cannot pass AST checks, so the guard restricts their character set instead: it bans quotes, brackets, and separators, and allows . only as a decimal point. 2x, sin x, x^2, 2.5x, and 2(x+1) still parse; the guard blocks 2x.__class__.
• Regex denylist retained as defense in depth.

​

What this means for you

pip install --upgrade qwed-mcp

​

QWED-Infra v0.3.0 — Verification Context v1.0 and attestation trust boundary

Every qwed-infra guard now emits a portable Verification Context v1.0 document via to_verification_context(), and ADMIT decisions now require a cryptographically valid ES256 attestation bound to the exact claim and evidence.

​

Added

• to_verification_context() on all four guards — IamGuard (#45), NetworkGuard (#46), CostGuard (#48), and ArtifactBoundaryGuard (#50) each produce a schema-valid, tamper-evident VC document with claim, verifier identity, sha256-bound evidence, and an ADMIT/DENY admission decision, built on the shared bridge module from PR #44.
• Attestation trust boundary (PR #54) — ES256 (ECDSA P-256) JWT attestation service with a never-None fail-closed AttestationResult contract, revocation registry, and a single consumption-side gate validating signature, issuer, expiry, and revocation plus claim bindings (status match, query_hash == sha256(formal_statement), proof_hash == proof_ref).
• mint_diagnostic_attestation() — issues a token bound to a VERIFIED diagnostic’s own evidence commitment.

​

Breaking changes

• Admission semantics — VERIFIED results admit only with a cryptographically valid attestation bound to the exact claim and evidence. Arbitrary non-empty attestation strings are rejected as forged tokens and produce BLOCKED. A missing token demotes VERIFIED to UNVERIFIABLE/DENY. Callers previously passing placeholder tokens must mint via create_verification_attestation() or mint_diagnostic_attestation().
• New runtime dependencies — pyjwt and cryptography for attestation signing and validation.

​

Fixed

• Fail-closed on malformed inputs at every VC boundary (PR #51 and follow-ups) — undecimal budgets, non-string build backends, malformed topology, policy, or package inputs, symlink escapes and loops, and wheel entries outside the scanned boundary all map to BLOCKED/DENY documents instead of exceptions or guessed approval.

​

v7.1.0 — Verification Context v1.0 Rollout

v7.1.0 ships Verification Context v1.0 end-to-end: a formal specification with a machine-readable JSON Schema, a typed document model with fail-closed invariants, public proof_ref generation and resolution, and exposure across the API, Python SDK, CLI, verifiers, and the Docker GitHub Action. The release is additive — a semver minor with no breaking wire changes.

​

Spec and core model

• Verification Context v1.0 specification — the atomic JSON record of a verification: verified object, four context layers (interpretation / proof / evidence / decision), verdict, and admission, with canonical RFC 8785 encoding for the proof_ref evidence commitment (PR #302). See the Verification Context specification.
• VerificationContextDocument model + schema validation — typed VerificationContext, VerificationContextDocument, Verdict, Admission, and nested layer types with fail-closed invariants enforced at construction: VERIFIED requires a sha256:<64-hex> proof_ref; UNVERIFIABLE/BLOCKED require proof_ref: null with admission DENY (PR #308).
• Public proof_ref generation and resolution — compute_document_proof_ref() and resolve_document_proof_ref() derive and verify the content-bound SHA-256 commitment over the canonical document. Resolution fails closed: a proof_ref that cannot be resolved confers no authority (PR #309).

​

Surface exposure

• API endpoints — POST /verification-context/from-diagnostic, /validate, and /resolve convert DiagnosticResult records into VC documents, validate documents against the schema, and resolve proof_ref commitments (PR #311).
• CLI commands — the qwed context group: validate, resolve, and from-diagnostic (PR #311).
• SDK re-exports — all VC v1.0 types and helpers importable directly from qwed_sdk, plus create_verification_context_from_diagnostic(), validate_verification_context(), and resolve_verification_context() on both sync and async clients. See the Python SDK (PRs #311, #315).
• to_verification_context() across the verifier classes — implemented on the Code, Consensus, DSL Logic, Fact, Graph Fact, Image, Logic, Reasoning, Schema, SQL, Stats, and Symbolic verifiers plus the BatchFactVerifier and MultiVLMVerifier helpers, each mapping a DiagnosticResult to a VC document. Math and the secure code executor have no such method; their results convert through POST /verification-context/from-diagnostic (PRs #310, #316).
• Docker action VC outputs — the GitHub Action emits verdict, admission, proof_ref, and verification_context outputs in every mode (PR #313).

​

Fail-closed behavior

• A VERIFIED diagnostic without an attestation token fails closed to BLOCKED (trust_gate.mandatory_attestation_missing) when converted to a VC document — attestation is enforced through the same trust boundary as /verify/*.
• Malformed diagnostic payloads convert to BLOCKED documents instead of crashing, so the audit trail records the failure.
• resolve returns true only for a schema-valid VERIFIED document whose stored proof_ref matches the re-derived commitment.

​

Version bumps

​

Included PRs

​

Upgrading

​

v7.0.0 — Full DiagnosticResult engine conformance

v7.0.0 completes the engine migration to the unified DiagnosticResult contract (META #216). SchemaVerifier, SQLVerifier, CodeVerifier, SecureCodeExecutor, and StatsVerifier — plus the fact and image batch entry points — now all return DiagnosticResult (status / agent_message / developer_fields / proof_ref). The release also completes the truth-vs-admission separation: verification answers “is this claim provably true?” while a separate AdmissionDecision answers “should this be allowed at this boundary?”.

​

Breaking: POST /verify/code — VERIFIED is truth, admission is policy

{
  "status": "BLOCKED",
  "agent_message": "The code failed security verification and is not safe to use.",
  "developer_fields": { "is_safe": false },
  "proof_ref": null
}

{
  "status": "VERIFIED",
  "agent_message": "The code failed security verification and is not safe to use.",
  "developer_fields": {
    "constraint_id": "code_verifier.code_unsafe",
    "is_safe": false,
    "is_valid": false,
    "critical_count": 1,
    "issues": [ ... ]
  },
  "proof_ref": "sha256:...",
  "is_authoritative": true,
  "admission": "BLOCKED"
}

# Before (v6.x)
if response["status"] == "VERIFIED":
    execute(code)

# After (v7.0.0)
if response["admission"] == "ADMIT":
    execute(code)

​

Breaking: POST /verify/stats — execution success is never VERIFIED

{
  "status": "SUCCESS",
  "result": 52340.5,
  "code": "df['salary'].mean()"
}

{
  "status": "UNVERIFIABLE",
  "agent_message": "Statistical analysis completed, but the claim could not be deterministically verified.",
  "developer_fields": {
    "constraint_id": "stats_verifier.claim_not_verified",
    "is_valid": false,
    "observed_result": 52340.5,
    "generated_code": "df['salary'].mean()",
    "dataset_sha256": "9f2c...",
    "sandbox_type": "docker"
  },
  "proof_ref": null,
  "is_authoritative": false
}

​

SchemaVerifier → DiagnosticResult (#294)

• verify() and verify_ucp_transaction() return DiagnosticResult. A schema violation is VERIFIED (as-invalid) with developer_fields.is_valid: false; BLOCKED (schema_verifier.parse_error / schema_verifier.validation_error) is reserved for schemas that cannot be parsed or validated.
• proof_ref is computed deterministically from canonical JSON of the schema + instance evidence; unsupported values and cyclic structures fail closed to BLOCKED.
• Recursive schema meta-validation: malformed keyword shapes (non-dict properties, invalid required entries, invalid or non-finite numeric constraints, negative size constraints) return BLOCKED instead of being silently treated as empty. Oversized integer bounds (e.g. 10**1000) no longer raise OverflowError.
• UCP hardening: money arithmetic uses Decimal quantized to the currency precision (no more 0.01 float tolerance), tax is selected by key presence so tax: 0 is honored, verdict fields (transaction_type, currency, schema_verifier.ucp_* constraint ids) are complete on every path, and string/None amounts no longer raise.
• agent_message is sanitized — no rule IDs, issue types, or schema internals leak into agent-facing output.

​

SQLVerifier → DiagnosticResult (#295)

• verify_sql() returns DiagnosticResult. A safe query is VERIFIED (sql_verifier.sql_valid, is_valid: true, proof_ref from the AST). A proven-malicious query is VERIFIED-as-malicious (sql_verifier.malicious, is_valid: false, malicious_classification: true) — proving malice is a successful proof, so it retains its proof_ref.
• BLOCKED is reserved for incomplete or failed analysis: sql_verifier.parse_error, sql_verifier.schema_parse_error (takes precedence over malice detection — no authoritative proof from incomplete analysis), sql_verifier.complexity_limit_exceeded, and sql_verifier.execution_error.
• POST /verify/sql attaches the admission field (ADMIT / BLOCKED) alongside the verdict.

​

CodeVerifier & SecureCodeExecutor → DiagnosticResult (#296)

• verify_code(), verify_python_deep(), and verify_batch() return DiagnosticResult with the truth-vs-admission semantics described above.
• verify_batch() returns per-item verdicts plus a summary (safe / unsafe / blocked counts, total_critical) and an overall is_valid that is true only when all snippets are safe — the batch is otherwise non-admissible.
• SecureCodeExecutor.execute() no longer executes code wholesale on the verifier verdict: an unconditional OWASP LLM06 dangerous-pattern gate blocks execution with CONSTRAINT_DANGEROUS_PATTERN. The scan is AST-aware, so dangerous keywords appearing only in comments, docstrings, or string literals do not cause false denials.
• ConsensusVerifier and StatsVerifier code stages now require is_verified and developer_fields.is_valid is True, so consensus results can no longer admit unsafe code.

​

StatsVerifier → DiagnosticResult (#297)

• verify_stats() returns DiagnosticResult with the execution-is-not-verification semantics described above.
• The API boundary is a thin pass-through: POST /verify/stats forwards the engine’s DiagnosticResult through enforce_trust_decision() unchanged.
• Logging is fail-closed and claim-aware: a non-authoritative result (BLOCKED / UNVERIFIABLE, proof_ref: null) can never be persisted as verified, even if mutable developer_fields.is_valid metadata is true.
• A non-serializable sandbox result (e.g. a DataFrame) is coerced to a JSON-safe value before entering developer_fields, so a legitimate UNVERIFIABLE verdict is not silently downgraded to BLOCKED.

​

Fact & image batch verification fail closed (#297)

• The batch is authoritative (VERIFIED + proof_ref) only when every claim is deterministically verified.
• Any refuted or blocked claim fails the whole batch closed (fact_verifier.batch_blocked / image_verifier.batch_blocked).
• An empty batch is BLOCKED (*.empty_batch).
• The batch proof_ref binds full claim digests and the shared input (image digest for image batches, context digest for fact batches), never truncated display text.
• Aggregation is shared via diagnostics.aggregate_batch_diagnostic() so the fail-closed logic cannot drift between engines.

​

Version bumps

​

Included PRs

​

Upgrading

​

v6.0.0 — Trust Boundary Completion

v6.0.0 closes the Trust Boundary Completion epic (Issue #263, 12/12 sub-issues). Every verification pathway now returns a unified DiagnosticResult and routes through enforce_trust_decision. The trust boundary is no longer advisory: the control plane requires and verifies attestation before admitting VERIFIED results, and VERIFIED is a protocol guarantee backed by a deterministic proof_ref — never by execution, agreement, confidence, or provenance.

​

Architecture: observation vs. admission

• All /verify/* endpoints return DiagnosticResult — unified response contract across every verification surface (PR #276)
• Control plane enforces mandatory attestation — require_attestation=True, attestation issued and verified at the admission boundary, and the enforced status drives the HTTP response status (PR #278). See Cryptographic attestations.
• Batch math routes through the trust boundary — /verify/batch results carry DiagnosticResult, proof_ref, and attestation, and pass through enforce_trust_decision (PR #282). See POST /verify/batch.
• Attestation scope alignment — attestations bind to the translated expression, not the natural-language query, so query_hash binds to what was actually verified (PR #285).

​

VERIFIED is a protocol guarantee

• ConsensusResult uses the DiagnosticStatus enum with proof_ref and verified_evidence (PR #280). See Consensus engine.
• FactVerifier heuristic SUPPORTED verdict → UNVERIFIABLE with advisory_checks (PR #283).
• Consensus code execution advisory-only — VERIFIED → UNVERIFIABLE (PR #281).
• Consensus stats advisory-only — never VERIFIED (PR #277).
• LogicVerifier migrated to DiagnosticResult (PR #262 — details in the entry below).
• AgentStateGuard proof_ref is now a real sha256 of committed bytes, not a static sentence (PR #284). See Agent state guard.

​

Engineering and security hardening

• TOCTOU closure in enforce_trust_decision — developer_fields snapshotted via recursive rebuild (no deepcopy alias window); fail-closed snapshot (PR #290)
• Attestation signature verified before claim decode — silent generic error for every failure mode (PR #287)
• Tenant-isolated verification cache — VerificationCache keys namespaced by normalized tenant_id (PR #286)
• Unicode normalization in AgentStateGuard canonicalization — NFC collisions rejected (PR #288)
• Mandatory proof artifact for VERIFIED attestations at both issuance and consumption (PR #248)
• Credential / JWT / dockerignore security alerts resolved (PR #249)
• Math whitelist injection bypass removed (PR #251)
• Engine classification docs — Proof / Policy Enforcement / Advisory (PR #247)

​

Version bumps

​

Included PRs

​

Upgrading

​

v6.0.0 — LogicVerifier conforms to DiagnosticResult

LogicVerifier is the second engine — after FactVerifier — to conform to the unified 3-layer DiagnosticResult contract introduced in v5.2.0. All nine public methods now return a DiagnosticResult with .status, .developer_fields, .is_verified, .agent_message, and .proof_ref. The legacy LogicResult dataclass has been removed. Two fail-closed input-strictness fixes ship with it.

​

What changed

• All nine methods return DiagnosticResult. verify_logic, verify_with_quantifiers, verify_bitvector, verify_array, prove_theorem, check_implication, check_equivalence, verify_optimization, and check_vacuity all now return a DiagnosticResult with the three diagnostic layers populated.
• Per-method SAT/UNSAT disambiguation. Z3’s sat/unsat outcome is mapped to a DiagnosticStatus per method (for example, verify_logic sat → VERIFIED, but prove_theorem sat → BLOCKED with a counterexample; prove_theorem unsat → VERIFIED because the theorem was proved by contradiction). The raw solver verdict is preserved on developer_fields["deterministic_verdict"].
• symbol_table on every VERIFIED result. developer_fields["symbol_table"] is a sorted list of {"name": ..., "type": ...} entries for every declared variable, so audit logs capture exactly what was proven.
• proof_ref from the Z3 assertion stack. Every VERIFIED result carries a deterministic sha256:... proof_ref computed from the solver’s assertions — the authority bit that downstream gates use for admissibility.
• Empty variables dict now fails closed. The _infer_variables type-guessing heuristic has been removed. Calls with an empty variables dict return BLOCKED with constraint_id = "logic_verifier.explicit_declarations_required". Declare every variable explicitly.
• Malformed BitVec[N] declarations now fail closed. Type strings such as "BitVec", "BitVec[]", or "BitVec[abc]" no longer silently default to 32 bits. They return BLOCKED with constraint_id = "dsl_compiler.type_validation".
• agent_message is sanitized. No raw Z3 output leaks into the agent-facing layer. Structured diagnostic details live under developer_fields.

​

Before and after

# Before — LogicResult with a solver-level status string
result = verifier.verify_logic({"x": "Int"}, ["x > 0"])
if result.status == "SAT":
    solution = result.model

# After — DiagnosticResult
result = verifier.verify_logic({"x": "Int"}, ["x > 0"])
if result.is_verified:
    solution = result.developer_fields["model"]
    verdict  = result.developer_fields["deterministic_verdict"]  # "SAT"

# Before — SAT meant "theorem is valid"
result = verifier.prove_theorem(variables, premises, conclusion)
if result.status == "SAT":
    ...  # theorem valid
elif result.status == "UNSAT":
    counterexample = result.model

# After — VERIFIED means "theorem proved", BLOCKED means "counterexample found"
result = verifier.prove_theorem(variables, premises, conclusion)
if result.is_verified:
    ...  # theorem proved by contradiction
elif result.status.value == "BLOCKED":
    counterexample = result.developer_fields["model"]

# Before — types were guessed from constraint syntax
verifier.verify_logic({}, ["x > 5", "P and Q"])
# Inferred: x -> Int, P/Q -> Bool

# After — BLOCKED
result = verifier.verify_logic({}, ["x > 5", "P and Q"])
result.developer_fields["constraint_id"]
# "logic_verifier.explicit_declarations_required"

​

What this means for you

​

QWED Control Plane — mandatory attestation admission on /verify/math, translated-expression attestation scope

The control plane now treats attestation as an admission gate on the math verification path — the final response status is set by the enforcement step after signing, not by the raw verifier verdict. In the same release, the attestation qwed.query_hash now binds to the translated deterministic expression, not to the user’s natural-language query.

​

What changed

• enforce_trust_decision(..., require_attestation=True) is now the single source of truth for the math response status and trust_boundary.overall_status. Both fields are set from the enforced decision after attestation is issued, never from the raw verifier verdict.
• A VERIFIED math result is only surfaced once create_verification_attestation() returns ISSUED. Any attestation signing failure downgrades the response to BLOCKED — the error code is echoed under trust_boundary.attestation_error and no token is returned.
• trust_boundary.attestation_policy is now always "mandatory". The previous advisory mode has been removed.
• The attestation qwed.query_hash binds to the translated expression the engine actually evaluated, not to the natural-language query. The natural-language query is still returned in response.user_query for display, and trust_boundary.verification_scope = "translated_expression_only" continues to disclose the narrowed scope.

​

What this means for you

• Downstream consumers verifying a QWED attestation must hash the translated expression when re-checking qwed.query_hash. Hashing user_query will not match — that is intentional, because QWED does not attest to the LLM translation step.
• If your integration branched on trust_boundary.overall_status, it now reflects the post-attestation decision. Signing outages surface as BLOCKED with attestation_error, not as a raw VERIFIED verdict.
• See Trust boundary and POST /verify/natural_language for the full response contract, and Cryptographic attestations for the AttestationResult fail-closed contract.

​

v5.3.0 — SymbolicVerifier: DiagnosticResult reference implementation

QWED-Verification v5.3.0 makes SymbolicVerifier the first fully DiagnosticResult-conformant engine. The unified 3-layer diagnostic model introduced in v5.2.0 is no longer aspirational — the Code engine is the reference implementation the remaining engines will migrate to.

​

What changed

• Six methods migrated to DiagnosticResult — verify_code, verify_function_contract, verify_safety_properties, verify_bounded, analyze_complexity, and get_verification_budget now return the unified 3-layer diagnostic type. Every result carries status (DiagnosticStatus), agent_message (Layer 1), developer_fields (Layer 2), and proof_ref (Layer 3, always None for this engine).
• verification_mode on every result — developer_fields["verification_mode"] is "symbolic" for standard runs and "bounded_symbolic" for verify_bounded(), so callers can distinguish the two verification modes without inspecting the call site.
• VERIFIED is intentionally never emitted — CrossHair’s search is timeout-bounded, not a completeness proof, so a clean run maps to UNVERIFIABLE with constraint_id = "symbolic_verifier.no_counterexample_found". The DiagnosticResult contract structurally requires a proof_ref for VERIFIED, and this engine has no proof artifact to bind. Downstream policy gates must reject symbolic-engine output for control flow.
• verify_code() no longer accepts check_assertions — the parameter was never wired up. The current signature is verify_code(self, code: str) -> DiagnosticResult.
• Advisory checks throughout — verify_safety_properties, analyze_complexity, and get_verification_budget attach structured AdvisoryCheck entries to developer_fields["advisory_checks"]. Advisory checks never influence the verdict.

​

Before and after

result = verifier.verify_code(code)

if result["status"] == "verified":
    admit(payload)
elif result["status"] == "counterexamples_found":
    for issue in result["issues"]:
        log(issue["description"])

from qwed_new.core.diagnostics import DiagnosticStatus

result = verifier.verify_code(code)

# This engine never emits VERIFIED — treat every result as unverified for
# control flow, and use developer_fields for the specific reason.
reject(payload, reason=result.agent_message)

if result.status is DiagnosticStatus.UNVERIFIABLE:
    if result.developer_fields["constraint_id"] == "symbolic_verifier.counterexample_found":
        for issue in result.developer_fields["issues"]:
            log(issue["description"])

​

Field cheat sheet

​

Version propagation

​

Included PRs

• #212 — feat: migrate SymbolicVerifier to DiagnosticResult (Phase 1)
• #220 — fix: remove unused check_assertions parameter from verify_code
• #239 — feat: add verification_mode to SymbolicVerifier DiagnosticResults
• #240 — feat: migrate verify_bounded to return DiagnosticResult
• #241 — feat: migrate get_verification_budget to return DiagnosticResult
• #242 — feat: migrate analyze_complexity to return DiagnosticResult
• #243 — feat: migrate verify_safety_properties to return DiagnosticResult
• #244 — release: v5.3.0 — SymbolicVerifier: DiagnosticResult reference implementation

​

What this means for you

​

QWED-A2A — UNVERIFIABLE verdicts carry no JWT, and five README behaviors realigned with the code

The interceptor no longer produces a signed FORWARDED verdict for empty or malformed FINANCIAL_TRANSACTION and LOGIC_ASSERTION payloads, and no longer silently forwards GENERAL / DATA_QUERY messages. Both cases now return verdict.status = "unverifiable" with attestation_jwt = None — signing a token for content that was never verified would be a false cryptographic claim. The A2A docs are updated to match the shipping behavior on five points that previously overstated what the interceptor does.

​

What changed

• Empty/malformed finance and logic payloads → UNVERIFIABLE, no JWT. A FINANCIAL_TRANSACTION missing data, line_items, or claimed_total, or with non-numeric amounts, now returns status=unverifiable from finance_guard. A LOGIC_ASSERTION with a missing, non-list, or empty assertions array, or malformed entries, returns status=unverifiable from logic_guard. Earlier releases collapsed these cases to verified=True + a signed FORWARDED verdict.
• GENERAL and DATA_QUERY are no longer silently forwarded. The passthrough branch now returns an unverifiable verdict with engine_used="passthrough", attestation_jwt=None, and reason "No verification engine available for this payload type". Callers must decide their own downstream policy for unverified traffic.
• No Bypass verification stage. The pipeline has four stages, not five. config.trusted_agents is pre-added to the TrustBoundary allowlist at interceptor construction time — trusted agents still flow through engine routing and receive a normal verdict. The Verification interceptor and Architecture pages have been corrected.
• CodeGuard is AST-first, regex-second. Code payloads are first parsed into an AST and inspected for direct dangerous constructs (eval(, exec(, subprocess.run(, import subprocess, etc.). Only if the AST layer is clean does a regex heuristic scan run to catch obfuscation patterns (getattr(__builtins__, ...), base64-encoded exec, dynamic __import__). The verdict is BLOCKED if either layer triggers, or HEURISTIC_PASS if both are clean — not a proof of safety.
• JWT attestation expiry is 300 seconds (5 minutes), not 24 hours. The default validity_seconds on A2ACryptoService is 300 — one A2A hop lifetime. The Crypto attestations page and its signing example were updated.

​

New verdict-status contract

​

What this means for you

​

QWED verification — signature-first attestation validation, uniform rejection error, and TOCTOU-safe trust-boundary snapshot

Two follow-ups harden the attestation trust boundary introduced last week. verify_attestation() now verifies the JWT signature before applying any issuer authorization or revocation checks, and every rejection path returns the same generic "Invalid token" error so callers cannot enumerate trusted issuers, probe token expiry, or confirm revocation state through response text. enforce_trust_decision() now returns a fully detached DiagnosticResult snapshot, closing a TOCTOU window where a concurrent caller could mutate developer_fields between the validation read and the admission decision.

​

What changed

• Signature-first verification order. verify_attestation() cryptographically verifies the JWT (signature + expiration + required claims) before it applies the trusted-issuer authorization check or the revocation check. An unknown-issuer token that is not correctly signed is rejected on signature grounds and the trust-list check never runs.
• Uniform "Invalid token" rejection. Every failure mode — expired, revoked, untrusted issuer, unsupported external issuer, malformed, oversized, malformed base64 — returns the same (is_valid=False, claims=None, error="Invalid token") triple. Detailed reasons are still recorded in the server-side attestation.rejected audit log; only the caller-facing error is generic. This closes the trusted-issuer enumeration side channel.
• Detached-result snapshot in enforce_trust_decision(). Before validation, developer_fields is recursively rebuilt into an isolated snapshot that admits only immutable scalars, AdvisoryCheck, and JSON-safe containers. The value you validate is the value you return, so a concurrent mutation of the caller’s DiagnosticResult can neither skew the decision nor leak into the returned result.
• Fail-closed snapshot failure. When developer_fields contains an unsupported value type (custom class instance, generator, open file handle) or an object that resists copying, enforce_trust_decision() returns a BLOCKED result with constraint_id="trust_gate.diagnostic_snapshot_failed". Only the exception type is logged — never the exception message, which could embed caller data.
• Runtime dependency. cryptography is now a runtime dependency (previously an optional extra), so ES256 signature verification runs by default.

​

Before and after

# Distinct messages leaked expiration, revocation, and trusted-issuer identity.
is_valid, claims, error = client.verify_attestation(bad_jwt)
# error = "Untrusted issuer: did:qwed:node:staging"
# error = "Attestation has expired"
# error = "Attestation has been revoked"
# error = "External issuer key resolution not implemented"

# Every rejection path returns the same string.
is_valid, claims, error = client.verify_attestation(bad_jwt)
# is_valid = False, claims = None, error = "Invalid token"

result = engine.verify(query)  # DiagnosticResult(developer_fields={"score": 0.9})
decision = enforce_trust_decision(result, attestation_token=token, ...)

# Concurrent code holding `result` could mutate developer_fields AFTER
# validation but BEFORE the caller admitted the decision — the returned
# reference aliased the input.
result.developer_fields["score"] = -1.0
assert decision.developer_fields["score"] == -1.0  # TOCTOU: mutation leaked in

result = engine.verify(query)
decision = enforce_trust_decision(result, attestation_token=token, ...)

# `decision.developer_fields` is a detached snapshot. Mutations to the
# original never reach the enforced result.
result.developer_fields["score"] = -1.0
assert decision.developer_fields["score"] == 0.9  # unchanged

​

What this means for you

​

QWED verification — mandatory proof artifact for VERIFIED attestations and a single trust-boundary entry point

Two related enforcement-boundary changes ship together. Issuance side, the crypto layer now refuses to sign a VERIFIED verdict that has no proof artifact. Consumption side, a new enforce_trust_decision() function is the single trust-boundary entry point that release gates route through — it verifies the attestation JWT, binds its claims to the result (status, query hash, proof hash), and fails closed on any mismatch.

​

What changed

• create_verification_attestation() blocks VERIFIED without proof. Calling with verified=True (or status="VERIFIED") and an empty or missing proof_data now returns AttestationResult(status=BLOCKED, token=None, error_code="VERIFIED_WITHOUT_PROOF", error=...). The crypto layer will not sign a VERIFIED result that has no evidence to hash into the token’s proof_hash claim. UNVERIFIABLE and BLOCKED verdicts are unaffected.
• New enforce_trust_decision() trust-boundary gate. Exported from qwed_new.core, this is the single consumption-side entry point every release gate must route through. It takes the engine’s DiagnosticResult plus the attestation token, verifies the JWT (signature, expiry, trusted issuer), and blocks the decision when the token’s qwed.result.status, qwed.query_hash, or qwed.proof_hash claims do not match the result. UNVERIFIABLE/BLOCKED results pass through unchanged.
• require_attestation policy toggle. enforce_trust_decision(result, require_attestation=True, ...) (default) is the mandatory policy — VERIFIED without a valid token is downgraded to BLOCKED. require_attestation=False is the advisory policy for staged rollouts: a missing token still passes as VERIFIED, but a present-and-invalid token still blocks. Both modes emit structured trust_gate.blocked audit logs on rejection.
• Control plane integration. The math control plane now routes every verification through enforce_trust_decision() and records the outcome and policy on the trust boundary (trust_enforced, attestation_policy) so operators can watch the mandatory rollout from telemetry before flipping the switch.

​

Before and after

# Before — the crypto layer signed a VERIFIED verdict even with no proof_data,
# emitting an attestation whose proof_hash pointed at an empty artifact.
create_verification_attestation(
    status="VERIFIED",
    verified=True,
    engine="math",
    query="2+2=4",
)
# AttestationResult(status=ISSUED, token="eyJ...", error_code=None)

# After — issuance is refused; there is no way to obtain a signed
# attestation for a VERIFIED claim without evidence.
create_verification_attestation(
    status="VERIFIED",
    verified=True,
    engine="math",
    query="2+2=4",
)
# AttestationResult(
#     status=BLOCKED,
#     token=None,
#     error_code="VERIFIED_WITHOUT_PROOF",
#     error="VERIFIED status requires proof_data — cannot sign attestation without proof artifact",
# )

# Before — release gates inspected result.status directly and could admit
# a VERIFIED result whose attestation was missing, invalid, or bound to a
# different query. There was no single enforcement point.
if result.status == "VERIFIED":
    proceed()

# After — one call gates the boundary. Missing/invalid tokens or
# mismatched claims downgrade the decision to BLOCKED with a
# structured audit event.
from qwed_new.core import enforce_trust_decision

decision = enforce_trust_decision(
    result,
    attestation_token=token,
    require_attestation=True,
    trusted_issuers=["did:qwed:node:production"],
    query="2+2=4",
)

if decision.status.name == "VERIFIED":
    proceed()
else:
    reject(decision)

​

What this means for you

​

QWED-A2A — verify_attestation() now requires an AttestationContext (breaking)

A2ACryptoService.verify_attestation() used to accept a token on its own — a cryptographically valid signature was treated as sufficient proof. A detached attestation could therefore be lifted from one exchange and replayed against a different sender, receiver, or payload without detection. The method now requires a second argument, an AttestationContext describing the current request, and rejects the token if the sender, receiver, payload hash, or session claim does not match.

​

What changed

• New AttestationContext dataclass in qwed_a2a.security.crypto with fields sender_agent_id: str, receiver_agent_id: str, payload: Any, and optional session_id: str | None. The payload is hashed internally with the same deterministic method as sign_verdict(), so callers never handle raw hashes.
• New context-binding verification step — sender, receiver, payload hash, and (when supplied) session_id are compared against the token’s qwed_a2a claims and sub claim. Any mismatch returns a structured rejection: "Attestation sender mismatch: expected=..., got=...", "Attestation receiver mismatch: ...", "Attestation payload hash mismatch — detached attestation rejected", or "Attestation session mismatch: ...".
• Verification order updated. Context binding now runs after the deployment-context check but before the jti replay check. This is deliberate: an out-of-context token no longer pollutes the jti registry, so a legitimate future presentation of the same token in its correct context is not locked out.
• Signing is unchanged. sign_verdict() still takes the same arguments — only the verify side gained a parameter.

​

What this means for you

from qwed_a2a.security.crypto import AttestationContext

context = AttestationContext(
    sender_agent_id="procurement-agent",
    receiver_agent_id="treasury-agent",
    payload=request_payload,
    session_id=request_session_id,  # optional
)
is_valid, claims, error = crypto.verify_attestation(token, context)

​

QWED Math Engine — fail-closed on mode ambiguity, eigenvalue cardinality, and IRR convergence

Three core-verifier fixes tighten the math engine’s fail-closed contract. verify_statistics(statistic="mode"), verify_matrix_operation(operation="eigenvalues"), and verify_irr() no longer produce VERIFIED when the underlying claim is ambiguous, under-specified, or numerically unproven. Callers see BLOCKED or CORRECTION_NEEDED with structured diagnostics instead of a best-effort answer.

​

What changed

• verify_statistics(statistic="mode") requires a unique mode. When two or more values tie for the maximum frequency, the engine returns BLOCKED with an ambiguous_modes list instead of heuristically picking one. Only a unique mode can produce VERIFIED.
• verify_matrix_operation(operation="eigenvalues") requires cardinality match. The claimed eigenvalue list length must equal the calculated count (counting algebraic multiplicity). Mismatched lengths return CORRECTION_NEEDED with calculated_count/claimed_count. Previously the value comparison used zip, which silently truncated to the shorter list.
• verify_irr() requires proof of Newton-Raphson convergence. BLOCKED is now returned when cash flows have more than one sign change (multi-root ambiguity per Descartes’ rule), zero sign changes (no real IRR), all-zero cash flows (IRR undefined), the Newton derivative stalls at zero, or the method fails to converge within 100 iterations. Successful results include converged: true and iterations_used.

​

Before and after

# Before — heuristically picked one of the tied values and could return VERIFIED
client.verify_statistics(statistic="mode", data=[1, 1, 2, 2, 3], expected=1)
# status: "VERIFIED"

# After — BLOCKED with the full list of tied values
client.verify_statistics(statistic="mode", data=[1, 1, 2, 2, 3], expected=1)
# status: "BLOCKED"
# ambiguous_modes: [1, 2]

# Before — zip truncated the comparison to length 1 and returned VERIFIED
client.verify_matrix_operation(operation="eigenvalues", matrix=[[2, 0], [0, 3]], expected=[2])
# status: "VERIFIED"

# After — CORRECTION_NEEDED with explicit cardinality diagnostics
client.verify_matrix_operation(operation="eigenvalues", matrix=[[2, 0], [0, 3]], expected=[2])
# status: "CORRECTION_NEEDED"
# calculated_count: 2, claimed_count: 1
# calculated_eigenvalues: [2.0, 3.0]

# Before — Newton-Raphson returned a best-effort iterate that could be VERIFIED
client.verify_irr(cash_flows=[-100, 230, -132], expected=0.10)
# status: "VERIFIED"

# After — BLOCKED because two sign changes admit multiple real IRRs
client.verify_irr(cash_flows=[-100, 230, -132], expected=0.10)
# status: "BLOCKED"
# sign_changes: 2

​

What this means for you

​

QWED-Finance — v2.1.0 released

qwed-finance v2.1.0 is now the current release. This is a version-sync release: the Python package, npm wrapper, GitHub Action, and quickstart workflow reference are all realigned so QWED Finance Guard reports a single consistent version across PyPI, npm, and SARIF output in GitHub Advanced Security.

​

What changed

• qwed-finance Python package is now v2.1.0 on PyPI (qwed_finance.__version__ == "2.1.0").
• @qwed-ai/finance npm package version bumped to 2.1.0 to match.
• GitHub Action auto-syncs its reported version from the installed package — the QWED Finance Guard name in workflow logs and the version field on SARIF uploads to the GitHub Security tab now both read 2.1.0 instead of a hardcoded v2.0.
• Quickstart qwed-verify.yml workflow is re-pinned from the stale v1.1.4 SHA to the v2.1.0 SHA (QWED-AI/qwed-finance@19ce969f21d1fc2019da4d89fff23bc108e15a98 # v2.1.0).

​

What this means for you

pip install --upgrade qwed-finance

- name: Verify banking calculations
  uses: QWED-AI/qwed-finance@v2.1.0

​

QWED-UCP — v0.3.0 released

qwed-ucp v0.3.0 is now the current release. This version ships the typed TrustStatus enum on every verification result, alongside the fail-closed middleware and internal-error handling delivered over the v0.2.x series.

​

What changed

• qwed-ucp Python package is now v0.3.0 on PyPI.
• Express middleware qwed-ucp-middleware package version bumped to match.
• TrustStatus enum is confirmed as available from v0.3.0 onward — see Trust status for the full state table and usage.
• GitHub Action should now be pinned to QWED-AI/qwed-ucp@v0.3.0.

​

What this means for you

pip install --upgrade qwed-ucp

- name: Audit Commerce Transactions
  uses: QWED-AI/qwed-ucp@v0.3.0

​

QWED-UCP — Express middleware fails closed on internal verification errors

When a guard raised an unexpected exception, the Express middleware previously logged the error and called next() — letting an unverified checkout through to the downstream handler. That defeated the trust boundary. The catch block now short-circuits with HTTP 500, X-QWED-Verified: false, and code: "INTERNAL_VERIFICATION_ERROR" so an internal crash can no longer be mistaken for a passing verification.

​

What changed

• Express middleware catch block is now fail-closed. On any exception raised during verifyCheckoutLocally(), the middleware returns:
  {
    "error": "QWED-UCP Verification Failed",
    "message": "Internal verification error: verification could not be completed",
    "code": "INTERNAL_VERIFICATION_ERROR"
  }
  
  The underlying exception is logged server-side via console.error but is not included in the response body — raw stack traces, file paths, and internal messages stay out of client-visible output.
• X-QWED-Verified: false is set on the 500 response so upstream policy layers can treat it the same as a 422 failure.
• npm package fix. qwed-ucp-middleware.js is now included in the published files array. Previous versions installed via npm were missing the entrypoint that index.js required at runtime.

​

What this means for you

​

QWED-UCP — typed TrustStatus enum on every verification result

Verification results previously exposed a single verified: bool that collapsed “proof disproved,” “proof could not be established,” “input outside supported semantics,” and “verifier engine crashed” into the same False bucket. Every result dataclass now also carries a typed status: TrustStatus field so downstream policy code can make trust-aware decisions without parsing error strings.

​

What changed

• New TrustStatus enum exported from qwed_ucp with seven states: VERIFIED, FAILED, UNVERIFIABLE, UNSUPPORTED, PARTIAL, ENGINE_ERROR, and QUARANTINED (reserved).
• status field on every result — GuardResult, UCPVerificationResult, and each per-guard result type (MoneyGuardResult, StateGuardResult, SchemaGuardResult, LineItemsGuardResult, DiscountGuardResult, CurrencyGuardResult, RefundGuardResult, TipGuardResult, FeeGuardResult, AttestationResult).
• UCPVerifier.verify_checkout() now surfaces ENGINE_ERROR when any guard raises an exception, instead of silently collapsing to verified=False.
• verified: bool is preserved as a backward-compatible derived field: result.verified is True only when result.status == TrustStatus.VERIFIED. Existing constructors that pass verified=True/verified=False continue to produce the corresponding VERIFIED/FAILED status.

​

What this means for you

​

QWED-UCP — middleware fails closed on empty and non-JSON request bodies

The FastAPI and Express middleware previously forwarded requests with an empty body, malformed JSON, or a non-object JSON payload to the downstream handler without running any guards. On a /checkout-sessions route that defeated the trust boundary — an attacker could send {}’s worth of nothing and skip verification. Both middlewares now reject those requests with HTTP 422, X-QWED-Verified: false, and code: "UNPARSEABLE_REQUEST" before the handler runs.

​

What changed

• FastAPI: returns a distinct message per case:
  • Empty body → "Empty request body: cannot verify empty payload"
  • Malformed or non-UTF-8 body → "Malformed request body: expected JSON"
  • Top-level non-object JSON → "Invalid request body: expected JSON object"
• Express: all three cases return "Empty or non-JSON request body: cannot verify unparseable payload".
• Non-protected methods and paths (for example, GET /health or a POST to a route outside verify_paths) still pass through untouched.

​

What this means for you

​

QWED-A2A — persistent signing key and JWKS discovery endpoint

A2ACryptoService no longer generates an ephemeral ECDSA P-256 key per process. The signing key is now loaded from the QWED_A2A_SIGNING_KEY_PEM environment variable (or the pem_key constructor argument) so attestation JWTs issued before a restart remain verifiable afterwards. A new /.well-known/jwks.json endpoint publishes the current public key for external consumers.

​

What changed

• Persistent signing key — A2ACryptoService reads an unencrypted PKCS#8 P-256 PEM from QWED_A2A_SIGNING_KEY_PEM on first use. The derived key_id is a SHA-256 fingerprint of the public key, so it stays stable as long as the PEM does.
• Fail-closed on missing key — sign_verdict, verify_attestation, get_public_key_jwk, and A2AVerificationInterceptor.intercept() all raise RuntimeError when the PEM is missing, malformed, or uses a curve other than SECP256R1. The FastAPI gateway surfaces this as HTTP 503 Signing key unavailable.
• JWKS endpoint — A new wellknown_router exposes GET /.well-known/jwks.json for downstream services and auditors to fetch the current public key without an out-of-band exchange.
• get_public_key_jwk() — Returns the current public key as a JWK (kty, crv, x, y, kid, use, alg).

​

Breaking changes

openssl ecparam -name prime256v1 -genkey -noout \
  | openssl pkcs8 -topk8 -nocrypt \
  > qwed_a2a_signing_key.pem

​

What this means for you

​

QWED-Tax — structured 3-layer diagnostics for TDS, ITC, and GST-RCM

QWED-Tax adopts the same 3-layer DiagnosticResult contract introduced in QWED-Verification v5.2.0 — as an independent model, no cross-package dependency. The first three guards (TDS, Input Tax Credit, GST reverse-charge) now expose a structured diagnostic in addition to their existing dict response.

​

What’s new

• Tri-state status — Every diagnostic resolves to VERIFIED, UNVERIFIABLE, or BLOCKED. No HEURISTIC or AMBIGUOUS middle ground.
• Three disclosure layers — A short agent-safe summary (no statute IDs or detection logic), a structured developer evidence block (constraint ID, statute, jurisdiction, audit trace, deduction, net payable), and an optional proof reference.
• Proof reference is the authority bit — A deterministic sha256 hash of the audit trace, present only when a result is VERIFIED. Absent on UNVERIFIABLE and BLOCKED.
• First migrations — TDSGuard, InputCreditGuard, and GSTGuard (reverse-charge) each expose the new diagnostic format alongside their existing return shape.

​

Compatibility

​

What this means for you

​

QWED-Tax — exact paise comparison, edge-case input rejection, and strict payload schemas

Three input-strictness fixes ship together. CryptoTaxGuard.verify_flat_tax_rate now compares quantized paise values exactly instead of within a 0.1 tolerance, ValuationGuard and RemittanceGuard reject the edge-case numeric inputs that previously slipped through, and every QWED-Tax Pydantic input model now forbids unexpected fields.

​

What changed

• CryptoTaxGuard.verify_flat_tax_rate — The Decimal("0.1") tolerance was removed. Both the computed expected_tax and the caller’s claimed_tax are now quantized to two decimal places using ROUND_HALF_UP and compared with an exact ==. A 1-paise (0.01) deviation correctly returns verified=False.
• ValuationGuard.verify_conversion — Added explicit range checks: discount must be in [0, 1), and cap, next_round_price, and investment must all be strictly positive. DivisionByZero is now caught alongside InvalidOperation so a degenerate cap = 0 or discount = 1 no longer crashes — it fails closed with a structured {"verified": False, "error": "..."} response. The previous behavior allowed a discount > 1 to produce a negative share count.
• RemittanceGuard.verify_lrs_limit — After numeric parsing, amount_usd and financial_year_usage are now checked for negativity. Negative inputs return {"verified": False, "error": "BLOCKED: ..."} instead of being summed into the limit check, where a negative usage could mask a transaction that exceeds the $250,000 LRS cap.
• Input models — Address, WorkArrangement, WorkerClassificationParams, ContractorPayment, TaxEntry, DeductionEntry, PayrollEntry, and VerificationResult are now configured with model_config = ConfigDict(extra="forbid"). Any payload with an unexpected key raises a Pydantic ValidationError at the boundary. QWEDTaxMiddleware already surfaces this as status: "BLOCKED" with risk: "INVALID_PAYLOAD".

​

Breaking changes

from decimal import Decimal, ROUND_HALF_UP

claimed = (vda_income * Decimal("0.30")).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

​

What this means for you

​

Audit reference

​

QWED-Tax — middleware never returns full “verified” and ReciprocityGuard no longer always-passes

Two fail-closed fixes ship together. The Gusto interceptor middleware no longer overstates a gross-to-net arithmetic pass as full tax verification, and ReciprocityGuard no longer returns verified=True for arrangements with no reciprocity agreement.

​

What changed

• QWEDTaxMiddleware.process_ai_payroll_request — The success response is now status: "ARITHMETIC_VERIFIED" with execution_permitted: false. The middleware only verifies gross-to-net math; classification, withholding legality, reciprocity, and filing checks are still required before execution. The response includes checks_run (what was verified) and checks_not_run (what is still required) so callers can decide what to run next.
• TaxPreFlight report — Every report now includes a checks_not_run list covering both unselected guards and known gaps (checks not yet implemented for the action). For example, action="hire" reports payroll_arithmetic, withholding_legality, reciprocity, and filing_obligations as known gaps.
• ReciprocityGuard — The Z3 solver was removed (the prior expression was tautologically satisfiable and ignored the same_state parameter). The guard is now a deterministic lookup against the reciprocity-pair table with explicit fail-closed paths: same state → verified, known pair → verified, no agreement → verified=False, unknown state → verified=False. A new verify_reciprocity(residence_state, work_state, same_state=None) method takes string inputs; determine_withholding_state(arrangement) is kept for backwards compatibility.

​

Breaking changes

​

What this means for you

​

Audit reference

​

QWED-Tax — fail-closed on ambiguous classification and unverified claims

Six more QWED-Tax guards now refuse to sign off when they can’t independently prove a result. Ambiguous worker classifications, unparseable trade dates, unknown set-off heads, and reverse-charge inputs the guard doesn’t recognize all return verified=False with a structured error instead of a quiet pass.

​

Bug fixes

• CapitalGainsGuard — Unparseable acquisition or disposal dates and unknown asset types now block instead of being coerced into a sentinel value that flowed through to verified=True. SLAB-rate verification can no longer succeed without an income bracket — slab rates can’t be proven from the claim alone.
• ClassificationGuard — Mixed employee/contractor signals now return verified=False with an “ambiguous classification” error. The guard only returns CONTRACTOR when no employee indicators are present.
• SpeculationGuard — Set-off verification now requires a known income source (intraday, f&o, futures, options, delivery, business, capital_gains). Unrecognized sources are blocked instead of silently treated as non-speculative.
• InterHeadAdjustmentGuard — Set-off eligibility now runs against an explicit allowlist of heads. Salary loss set-off is added to the prohibition matrix, and unknown heads are blocked rather than defaulting to allow.
• GSTGuard (RCM) — Unrecognized service or entity types in reverse-charge checks now surface as a verified=False error naming the unknown value, instead of being coerced to OTHER or INDIVIDUAL and potentially suppressing a statutory RCM obligation. The verifier also gained an optional claim parameter — when you pass a claimed_is_rcm value, the guard compares it to the computed result and only returns verified=True on an exact match. Calls without the claim get a computed_only=True flag so calculation and verification are no longer conflated.
• CryptoTaxGuard — Zero VDA income now verifies a claimed tax of zero, instead of returning verified=True regardless of claim. Negative VDA income (a loss) returns verified=False with a message directing the caller to use verify_set_off for loss treatment — the method does not internally invoke verify_set_off, so callers must handle the verified=False branch explicitly.

​

What this means for you

​

QWED-Tax — fail-closed on unknown tax rules

Tax guards no longer silently pass when they encounter a service, asset, jurisdiction, or payment type they don’t model. Six guards now return verified=False with a structured error instead of an unsafe default.

​

What changed

• TDSGuard — unrecognized payment categories no longer return “verified, zero deduction.” This closes a path where an agent could classify a payment into an unknown bucket and have it execute with no withholding. TaxPreFlight now blocks these payments.
• CapitalGainsGuard — unknown asset class or holding term fails closed instead of returning “no hard constraint.”
• NexusGuard — states not in the configured risk list now require manual review instead of being treated as low-risk.
• AddressGuard — unknown state codes fail closed with “manual review required” instead of “assumed valid.”
• Form1099Guard (US) — unmodeled payment types return filing_required=None with a manual-determination flag, instead of defaulting to “no filing required.”
• InputCreditGuard (GST) — verified=True remains the legal default (ITC is allowed unless specifically blocked), but unknown categories now carry an explicit unverified_category=True flag in the result and an audit_trace entry of category_match: "default_allow" so downstream consumers can distinguish known-eligible from default-allowed.

​

What this means for you

​

QWED-Infra — ecosystem policy framework adopted

qwed-infra now ships with the shared QWED governance baseline: QWED_RULES.md, contributor guidance, PR template, CodeRabbit config, and a boundary-check workflow that is consistent with the other QWED repositories.

​

QWED-MCP — boundary-check parity with QWED-Infra

The qwed-mcp boundary-check tool now catches the same import-alias, module-alias, wildcard-import, eval/exec alias, and shell=True patterns that qwed-infra does, and fails closed when the scan root is missing.

​

What this means for you