A green status indicator is a claim, not a blessing.
Somewhere beneath it, a system was assessed, a scope was defined, evidence was examined, and someone decided that a particular use was acceptable. The useful question is what happens when one of those conditions changes. Does the indicator move with reality, or does it continue to commemorate a successful meeting?
Imagine an agent evaluated on Tuesday for preparing internal research summaries. It reads a defined document collection and produces a draft for a human reviewer. On Wednesday, someone connects it to a customer workspace because that saves copying. On Thursday, memory is added. On Friday, the agent can send the finished response. Each change is convenient. Together, they create a materially different job from the one that passed Tuesday’s assessment.
The model may be exactly the same. The effective system has changed through reach, context, and authority. A reliable assistant drafting a paragraph for internal review is not the same operating arrangement as an assistant representing the company to a customer. The second use cannot simply inherit confidence from the first.
NIST’s AI Risk Management Framework treats risk management as lifecycle work and recognizes that context matters. The implementation challenge is to keep assurance attached to the conditions that made the assurance true.
Every material assurance claim should answer a few plain questions. What was assessed? For which purpose and action? Under which permissions, knowledge sources, and review arrangement? Which evidence supports the conclusion? What assumptions would make the conclusion unsafe to reuse? Permission to borrow the truck for an errand does not silently include permission to attach a trailer, leave the state, and develop a sudden interest in off-road exploration.
The point is not to freeze the system. The point is to make boundaries inspectable. If an evaluation established that an agent accurately summarizes a defined source collection, preserve that result. If the agent gains a new tool, ask which claims depended on its inability to take that tool’s actions. If a standing instruction changes, identify the behaviors and decisions it governs. A punctuation example and a new ability to transfer funds do not deserve the same review response.
A change-sensitive assurance process needs three parts. First, record the evaluated configuration, permissions, context, and claims. Second, connect operational changes to the claims they may affect. Third, define the interim state while review happens. The agent might continue with narrower permissions, return to drafting, or pause a specific action until evidence is sufficient. The response should match the significance of the change. Repeating a full review for every adjustment will teach people to route around the process.
The missing step in many designs is recognizing which assurance became stale. A change log over here and an evaluation result over there are not enough. The system needs an account of why the evaluation supported the decision in the first place. “Passed testing” is hard to maintain. “Under these conditions, the agent respected this approval boundary in these scenarios” gives the next reviewer something concrete to work with.
The world can also change while the agent stays still. A source document becomes outdated. A business relationship ends. The reviewer leaves. An exception expires. Even if every component remains at the approved version, the conditions that justified using it may have disappeared. Configuration control and operational context need to speak to each other, preferably before the customer does.
A useful evaluation exercise is direct: give a system a valid approval, then change one condition the approval depends on. Remove a reviewer. Revoke a permission. Replace a current source with an archived one. Observe what the workflow detects, what the agent recognizes, and who receives the unresolved decision. The controls should not depend entirely on the agent noticing its own changed circumstances.
Current-state trust preserves the value of past evidence while asking whether it still supports the action in front of us. The green dot can stay. It just needs a reason.
Tuesday’s audit tells us what was known on Tuesday. Wednesday still needs an owner.