[Bug]: Middleware and facade APIs declare full verification after checking only a subset of tax legality

[rahuldass19]

Summary

Severity: HIGH

Some qwed-tax execution-facing paths return high-assurance success states after verifying only a narrow slice of the overall tax/legal problem. One verified subcomponent is being presented as if the whole transaction were proven correct — a partial-verification bug.

---

Problem

The clearest example is payroll middleware that checks gross-to-net arithmetic and then returns a fully verified/executable result, even though other legally material checks were never run:

• Worker classification
• Withholding legality
• W-4 exempt eligibility
• Reciprocity withholding state
• Filing or reporting implications

A system that proves only arithmetic but returns VERIFIED for a payroll action is overstating assurance.

---

Why this violates QWED philosophy

QWED requires:

• Partial verification must never be treated as full verification
• Unproven results must never pass as valid
• Trust boundaries must be honest about what was actually checked

---

Affected scope

Primary affected path:

• qwed_tax/middleware/gusto_interceptor.py

Related orchestration surface:

• qwed_tax/verifier.py

Representative issue:

• verify_us_payroll() only checks gross-to-net math through PayrollGuard
• Middleware then returns a fully successful execution decision

---

Attack scenario

An upstream AI or system submits a payroll payload that is mathematically balanced but legally wrong.

Example cases:

• Worker is W-2 but being processed as a contractor
• Withholding treatment is invalid
• Exempt handling is wrong
• Filing/state-tax implications are incorrect

If the numbers balance, the middleware can still return:

{
  "status": "VERIFIED",
  "execution_permitted": true
}

This gives downstream systems the impression that the payroll action is tax-safe, when only arithmetic consistency was checked.

---

Security impact

This can allow:

• Illegal payroll execution
• False confidence in downstream payment systems
• Incorrect classification or withholding decisions to survive as long as the math balances
• Trust-boundary misuse where integrators believe "verified" means full tax verification

In financial systems, this is a serious assurance-labeling bug.

---

Fix direction

• Narrow success semantics so arithmetic verification is labeled only as arithmetic verification
• Do not return full VERIFIED / executable status unless all relevant legal checks have run and passed
• Introduce layered result states that distinguish:
  • Mathematical verification
  • Legal/tax verification
  • Execution approval
• Require orchestration of all applicable payroll checks before allowing execution

---

Goal

qwed-tax should never present subset verification as full transaction verification.

If only one part of the tax/legal problem was checked, the result must say exactly that.

[rahuldass19]

Audit findings — exact locations + TaxPreFlight pattern

Confirmed this issue's core finding with exact line numbers. The middleware is fail-closed (good) but overstated in its success semantics (the bug).

Finding already in this issue (with line numbers)

middleware/gusto_interceptor.py lines 79-84:

# The AI's logic is mathematically sound. Allow execution to Gusto.
return {
    "status": "VERIFIED",
    "message": "AI tax logic mathematically verified. Safe to execute.",
    "execution_permitted": True,
    "validated_payload": payroll_entry.model_dump(mode="json")
}

The call chain:

1. process_ai_payroll_request() → self.tax_verifier.verify_us_payroll(entry=payroll_entry) (line 52)
2. TaxVerifier.verify_us_payroll() → self.payroll.verify_gross_to_net(entry) (verifier.py line 359)
3. PayrollGuard.verify_gross_to_net() — arithmetic only (gross - taxes - deductions = net)

What was checked: gross-to-net math
What was NOT checked:

• Worker classification (W-2 vs 1099) — ClassificationGuard never called
• Withholding legality (W-4 exempt eligibility) — WithholdingGuard never called
• Reciprocity (state tax withholding) — ReciprocityGuard never called
• Filing obligations (1099 requirements) — Form1099Guard never called
• Nexus (state tax liability) — NexusGuard never called

The message at line 82 is half-honest: "AI tax logic mathematically verified" — correctly says "mathematically". But then overstates: "Safe to execute" + "execution_permitted": True + "status": "VERIFIED" — these signal full tax verification to downstream systems.

Additional pattern: TaxPreFlight partial verification

verifier.py lines 131-182 — TaxPreFlight.audit_transaction() runs multiple checks per action, but the allowed: True result can be consumed as "full verification" when only a subset of applicable tax rules ran:

# For action="hire", only worker_classification runs (lines 237-243)
# Missing: payroll tax verification, withholding, state reciprocity, filing

# For action="pay_invoice", only TDS runs (lines 316-334)
# Missing: ITC eligibility, GST split, RCM applicability

TaxPreFlight is more transparent than the middleware — it returns checks_run: list[str] so a consumer can see what was checked. But there's no checks_not_run or verification_completeness field to signal that applicable checks were skipped.

Note on middleware fail-closed behavior

The middleware's block paths are excellent — it blocks on:

• Missing payload (line 32-38)
• Schema validation failure (line 42-48)
• Unexpected result type (line 53-59)
• Verifier exception (line 60-67)
• Verification failure (line 70-77)

This is the standard for fail-closed in this repo. The bug is not in the block paths — it's in the success path overstating what was verified.

Recommended fix

Two options (matching the issue's fix direction):

Option A — Narrow the success label (minimal change):

# Line 80-84
return {
    "status": "ARITHMETIC_VERIFIED",  # ← not "VERIFIED"
    "message": "Gross-to-net arithmetic verified. Legal/tax classification NOT checked.",
    "execution_permitted": False,  # ← require legal checks before permitting
    "checks_run": ["gross_to_net_arithmetic"],
    "checks_not_run": ["worker_classification", "withholding_legality", "reciprocity", "filing"],
    "validated_payload": payroll_entry.model_dump(mode="json")
}

Option B — Orchestrate all applicable checks (correct but larger):

# Run all payroll-relevant checks
results = {
    "arithmetic": self.payroll.verify_gross_to_net(entry),
    "classification": self.classifier.verify_classification_claim(...),
    "withholding": self.withholding.verify_exempt_status(...),
    # ...
}
all_verified = all(r.verified for r in results.values())
return {
    "status": "VERIFIED" if all_verified else "BLOCKED",
    "execution_permitted": all_verified,
    "checks_run": list(results.keys()),
    "checks_results": {k: v.model_dump() for k, v in results.items()},
}

Option B is the correct long-term fix. Option A is the safe interim — stop overstating, block execution until full verification is implemented.