Continuous Assurance
The agent you approved may not be the system running three months from now.
Conventional software stays functionally stable between releases. Agents do not.
A provider updates a model. A retrieval corpus shifts. Memory accumulates. A new attack pattern appears in the wild. Nothing in your repository changed, and the evidence behind your approval no longer describes what is running.
What should send an agent back through the loop#
The triggers are concrete, and every one of them is a field in the composition record: a new model or model version; a changed system prompt, policy prompt, routing, or orchestration; a new tool, a changed tool schema, an expanded permission, or a new external endpoint; a new retrieval source or a changed grounding policy; a changed memory configuration or evidence of contamination; a new high or critical production finding; a change in intended use, user population, risk tier, or environment; a newly published vulnerability affecting a model, tool, or MCP server in the record; and the expiry of the freshness window the policy defines.
That the triggers are all record fields is what makes automated change detection possible, and it is the practical reason the inventory work in Chapter 5 earns its keep.
The question to ask of any change is whether the current evidence still describes the running agent.
Freshness needs both age and equivalence#
Age alone is a weak rule, because a monthly recertification can be stale an hour after a significant change. Similarity alone is weak too, because slow drift accumulates without a single triggering event.
Treating a run as fresh only when it is both recent enough and materially equivalent to the deployed configuration catches both patterns.
Three kinds of drift, with different owners#
Behavioral drift shows up as changed scores or new findings across comparable evaluations. Context drift happens when the information environment gets noisier or staler — a corpus grows, a summary policy changes, a new untrusted source appears. Control drift happens when the deployed system no longer matches the assumptions under which a control was tested.
They have different owners and different fixes, which is the argument against collapsing them into a single number.
Closing the loop without taking over the pipeline#
In ProofAgent, each agent carries a cadence. When it passes that cadence the platform raises a stale-evaluation alert and emits a signed event, so the customer’s own runner re-runs the harness and uploads fresh evidence.
The trust boundary there is deliberate and worth copying. Governance decides and signals; the customer’s CI and runtime enforce, by failing a pipeline, flipping a flag, paging an engineer, or re-running the evaluation. The governance plane never runs or deploys the agent, which means it needs no deploy credentials and no access to the agent’s environment.
Assurance also has to stay proportional. It is not continuous testing of everything, but continuous awareness of whether the evidence still supports the authority. High-risk agents need frequent evaluation and fast reassessment; a low-risk read-only assistant needs considerably less. Spending equally on both is how these programs collapse under their own cost.
When a new run does happen, compare it against the last approved baseline and record a new decision. The previous decision stays in the record, because the question an auditor asks is not whether an agent is approved, but what was approved, when, on what evidence, and by whom.
Everything up to this point has been the method. The next part applies it end to end, against one ordinary agent.
Readiness belongs to a version of an agent, not to the agent forever.
Decide now what will expire your current approval, while nothing is on fire. An assurance policy written after a model update is always written under pressure.