Microsoft tests what a proof can guarantee about an AI-written login
Microsoft Research has demonstrated PDD Kit on the login flow of an agent-written Rust web application. The tool turns a developer’s intentions into explicit conditions and checks proofs against them. The example exposes an incomplete password rule and separates verified login properties from trusted components and empirical tests. It does not claim to prove the entire application.
Artificial Intelligence··Night
Login intent becomes explicit conditions
Microsoft Research has demonstrated PDD Kit, a tool for turning a developer’s intended behaviour into specifications, on the login flow of an agent-written web application. The example uses Rust and roughly five thousand lines of code, with an Axum and SQLite backend and a Leptos frontend compiled to WebAssembly. PDD Kit works in GitHub Next’s Chopin planning environment. Verus, a verifier for Rust, checks the resulting proofs. The developer approves the intended login behaviour before an agent constructs the proof. Empirical tests check third-party components and user-interface behaviour outside the verified login logic.[1], [2]
A correct-password rule needs both directions
The developer initially asks for a token to be issued only with the correct password, and for administrator tokens to go only to administrators. PDD Kit points out that rejecting everyone would also satisfy the first restriction. It therefore asks whether the converse should hold: must the correct password actually allow access? The developer chooses both directions. The specification later covers the asynchronous path that waits for database lookups and signs a token. Eight result conditions connect the checked account with the identity named in that token and constrain how an administrator role can be issued. Making those relationships explicit changes what the verifier is being asked to establish.[1]
Trusted components remain outside the proof
Database queries, password checking, token signing, the clock, error conversion and the request-unpacking shell rely on explicit trusted contracts. Tests are planned for those assumptions, with a passing test described as evidence rather than proof. The verified properties do not guarantee termination, speed, limits on repeated login attempts or other endpoints’ interpretation of roles. Microsoft introduces a deliberate bug for each result condition and checks whether verification rejects it. These mutation checks test whether the properties impose meaningful restrictions. The developer accepts each trusted assumption individually. Once the specification is approved, a build stage creates tasks in which agents write implementation and proof, Verus checks them and trusted components receive their planned tests.[1], [2]
Related columns
For more information on this topic, you can read the related columns.
