A security review supports conclusions about the system and conditions it examined. Keeping an agent's model unchanged does not establish that its tools, identities, or access to other systems remain within those conditions.
The right response to a changed configuration is to identify which conclusions still apply and which questions now need evidence. Discarding the entire earlier evaluation wastes useful work. Carrying its approval into a new execution scope without qualification can give that work a meaning it never supported.
A new capability changes the question
Consider a hypothetical assessment of an event-planning agent configured to read calendars and prepare scheduling suggestions. The review examines that arrangement, including its available inputs and read access. A proposed configuration later adds a tool that can alter invitations under a different acting identity, while retaining the same model.
These are conditions of an imagined review and change request, not a real product integration, an executed test, or an observed incident. No claim is made that the new tool has been used. The change is to what the proposed configuration could do and the identity through which it would do it.
Findings about scheduling suggestions may remain relevant within the conditions examined. They do not establish which invitations the added tool can modify, whose authority it uses, or how the destination restricts those changes. Those questions were outside a review limited to reading calendars and producing suggestions.
The AI agent security pillar provides the broader threat model. For change review, the specific task is to connect a conclusion to the capabilities and restrictions that made it supportable.
Read a conclusion together with its conditions
A finding needs enough context for another reviewer to determine where it applies. For the event-planning example, that includes the task, available calendar data, exposed operations, acting identity, and destination permissions relevant to the conclusion. “The model was reviewed” does not identify the access conditions around it.
NIST's AI RMF Playbook recommends documenting evaluation materials and demonstrating assurance criteria under conditions similar to deployment. It also recommends documenting differences between the measurement setting and the deployment environment. Those principles help assess whether earlier evidence addresses a proposed configuration; they do not establish that any test described in this example occurred. NIST AI RMF Playbook, MEASURE 2.1 and 2.3.
State assumptions that materially support the finding. If a conclusion relied on read-only permissions, preserve that condition with the evidence. If the review did not establish which identity a remote operation would use, keep that omission visible. A missing fact cannot become a verified restriction simply because it was absent from the report.
Carry forward evidence that still applies
The earlier evaluation can remain a useful baseline. Its findings about behavior on the examined inputs still describe that assessment. Whether they support a prediction about the changed configuration depends on what changed and which assumptions the finding used. A new tool does not automatically invalidate every observation of the model, but it can alter the decisions or context the agent encounters.
Separate an unchanged fact from a conclusion that depended on a former restriction. In this example, retaining the model is an unchanged fact. A claim about the effects available to the read-only agent depended on the absence of a write path. Adding an invitation-editing operation changes that basis even before anyone observes an unwanted edit.
Review effort should follow the dependency. Establish the new operation's permitted targets, acting identity, and control behavior; revisit model or workflow evaluation where the new capability changes the questions those evaluations need to answer. This is a proposal for scoping further assessment, not a claim that every change requires the same test suite or that unchanged components need no review.
The coding agent governance pillar applies a related distinction to workspaces and runners. The general lesson for an assessment is to retain evidence with its conditions instead of treating either a model name or an earlier approval as the boundary of the system.
Review the boundary where authority changed
An agent can cross several trust boundaries: from its runtime to a tool service, from that service to a destination, and from returned material back into its working context. The security boundary in this discussion includes those relationships. It is not a single perimeter that encloses the model and makes everything outside irrelevant.
In the scheduling example, identify where the invitation operation receives permission to act and which calendar resources that permission reaches. A restriction in the agent's local process does not establish the permissions of a remote service acting under its own identity. If MCP supplies the tool interface, the MCP security and governance guide explains why server access and authorization at the destination need separate examination.
OWASP's guidance on Excessive Agency connects the risks of LLM-based applications to their available functions, permissions, autonomy, and connected systems. It recommends limiting permissions and enforcing authorization at the destination. That supports examining the application around the model; it does not imply that every agent uses an LLM or that the hypothetical change caused harm. OWASP Excessive Agency.
The people who control the tool, credential, and destination need to supply the relevant evidence. An enterprise assessment can coordinate those contributions without pretending that one team owns every component. The enterprise AI security pillar explains how to connect resource protection to owners able to act.
Write a conclusion the next reviewer can use
For the proposed scheduling change, the review should identify the added operation and identity, the prior findings retained within their scope, and the new questions that have or have not been resolved. A conclusion can be narrow and useful. It need not declare the whole agent safe or the entire earlier assessment obsolete.
When further evaluation is performed, distinguish what was inspected, exercised, or inferred. Permission evidence may establish which calendars an identity can modify without proving how the tool applies a policy decision. A successful test of one permitted edit does not establish the behavior of every denied or exceptional path. Keep those limits attached to the resulting claim.
Apply the same discipline when evaluating Kona for Agents. Agree on the agent configuration, integrations, and security questions under consideration, then assess what the available evidence establishes for that arrangement. A review becomes reusable when its assumptions and limits are clear enough to compare with the next change.