LLM-guided formal verification

LLM-guided hierarchical decomposition solves 50-59% of TLA+ proof obligations TLA+ - The Temporal Logic of Actions
TL;DW
  • TLA+ proofs differ fundamentally from tactic-based provers like Lean—they decompose obligations into intermediate claims rather than apply sequential tactics, requiring a new LLM strategy.
  • Direct LLM-based proof generation (DLPG) fails due to syntax errors: LLMs struggle with TLA+'s low-resource language, mixing in syntax from other systems like Isabelle.
  • Hierarchical decomposition approach: use symbolic tool SAPG for simple obligations, ask LLM to decompose complex ones recursively until all leaves are provable by SAPG.
  • Normalize LLM output to structured JSON with assume/goal fields containing only boolean expressions, not full TLA+ proofs, reducing syntax errors dramatically.
  • LMGPA (LLM-guided proof automation) achieves 59% proof success on mathematical theorems with DeepSeek vs. 29% for direct generation with same model.
  • Validate decompositions by checking that subclaims together actually imply the parent obligation, preventing logically invalid decompositions from LLMs.
  • Syntactic validity improved from <1% (Gemini 2.5 Flash in DLPG) to 60%+ across models using normalized decomposition strategy.
  • Evaluated on 119 TLA+ theorems: 93 from mathematical benchmarks (F2F, ProofNet translated) and 26 from distributed protocol induction proofs representing practical use cases.
  • LMGPA consistently outperforms all baselines including obvious, SAPG alone, and DLPG across six state-of-the-art LLMs without fine-tuning.

LMGPA pairs an LLM with symbolic prover SAPG: simple obligations go straight to SAPG, complex ones get recursively decomposed by the LLM into normalized JSON subclaims rather than raw TLA+ syntax. The constraint lifts proof validity from ~20% to >60%, tested across 119 theorems from math and distributed protocols using six frontier models.

agentic AI security priorities

NDC: Data lake exposure eclipses prompt injection as critical risk in agentic systems NDC Conferences
TL;DW
  • Prompt injection receives disproportionate focus—spend 90% of AI security budget on it and miss critical threats like data lake breaches that destroy enterprises.
  • Data lake access is the most dangerous security surface: treat every connection as internet-exposed; require security engineers to personally review and execute all data queries, never allow direct access.
  • Split data lakes by workload type (agentic vs. classic, active vs. static) to apply appropriate security controls and prevent cross-contamination between agents, teams, and business units.
  • Guard models (Llama Guard, IBM Granite, GPT-O) provide free, open-source ingress/egress sanitization layers—they take text in, output safe/dangerous, replacing manual prompt filtering.
  • Parameterize inputs and keep arbitrary data outside AI systems: don't send real emails, credit cards, or URLs to agents; tokenize or primitize them instead.
  • Encryption key material cannot be deep-faked by AI—encrypt sensitive data at rest and in transit, only decrypting at the correct model/workload/customer combination.
  • Treat attack response time in seconds/minutes with AI, not hours/days: implement kill switches and company-wide character set sanitization at the gateway, not just per-application.
  • Track injection attacks at each infrastructure layer differently: gateway hits are normal; cloud hits are concerning; backend database hits signal breach; agentic layer hits indicate lateral movement or insider threat.
  • Learn model families, training data sources, and known vulnerabilities for each model your engineers propose—cursory knowledge of model security prevents deployment mistakes.
  • Assign lifecycle ownership and maintenance costs to each security control; with limited team capacity, prioritize controls you'll actually sustain rather than deploying 30 controls and maintaining none.

Jon McCoy argues prompt injection concern reflects survivor bias while the real threat is multi-agent, multi-team data lake access without workload isolation. Recommends treating data lake connections as internet-exposed endpoints, decomposing lakes by workload, and having security teams own every data pull.

microservices cost architecture

Wix cuts Kubernetes node count 50% by collapsing 4,000 microservices into shared-runtime host-guest pairs GeeCON
TL;DW
  • Wix runs ~4,000 microservices but most receive low traffic; single-runtime architecture bundles them into virtual monoliths to reduce costs and improve efficiency.
  • Achieved 50% reduction in Kubernetes nodes and 27% CPU, 32% memory reduction by moving from isolated services to host-guest architecture on shared pods.
  • Guest isolation achieved via separate Docker containers; host-guest gRPC communication adds only ~2ms latency, negligible vs. cross-service calls requiring database access.
  • Framework code (~90% of each service) moved to shared host; guests contain only business logic, reducing footprint from ~1.8GB to ~900MB memory per service.
  • Kubernetes daemon sets deploy single host per node (like log scrapers); multiple guest replicas use standard deployments for independent scaling and gradual rollout.
  • Custom deployment tool manages host upgrades across node groups (host-canary, host-1, host-2) separately from Kubernetes to ensure safe gradual rollout of critical infrastructure.
  • Backward and forward compatibility required for host-guest protocol; deploy protobuf changes before logic changes to safely handle staggered host and guest deployments.
  • Nile backend platform with code generation enables smooth migration; developers see no change—services automatically split into guest/host behind the scenes.
  • Framework upgrades deploy once on host instead of 4,000 times; infrastructure team controls centrally, eliminating need to chase service owners for updates.
  • Guest affinity planned: co-locate domain services (e-commerce, bookings, etc.) on same nodes to reduce network hops, improve latency via locality principle.

Wix's Nile platform bundles related JVM microservices as thin "guest" pods communicating via gRPC with a single "host" daemon set per node that owns all framework concerns—data access, Kafka, feature flags. Result: 27% CPU reduction, 32% memory reduction, half the node count across 5 billion daily requests.