Executive summary
Agentic change control should classify changes by the boundary they affect rather than by file count or deployment size. Model and provider changes can alter behavior. Prompt and policy changes alter goals and refusal. Retrieval changes alter evidence. Tool and identity changes alter authority and side effects. Memory and topology changes alter state and coordination. Human-review and runtime changes alter oversight and recovery. Domain changes can increase consequence even when software is unchanged. Each class needs a default evidence response and a named owner who decides whether the release remains valid.
Decision relevance: Define which changes require routine regression, conditional release, full reassessment, or immediate hold.
Material-change trigger register
| Changed boundary | Examples | Default evidence response |
|---|---|---|
| Model or provider | Model version, serving provider, system behavior, modality | Regression evaluation, safety/security review, cost and latency review |
| Prompt or policy | System instruction, policy bundle, refusal or escalation rule | Behavioral regression, policy conflict, authority and adverse-case review |
| Retrieval | Source set, index, embedding, reranker, query strategy, freshness | Retrieval quality, authorization, tenant isolation, provenance and stale-source tests |
| Tool contract | New tool, operation, input schema, side effect, error behavior | Threat model, authorization, idempotency, effect verification and rollback |
| Identity or permission | Scope, audience, role, delegation, token exchange | Least privilege, confused-deputy, revocation, audit and cross-tenant tests |
| Memory or state | New memory class, retention, shared state, supersession | Poisoning, privacy, concurrency, deletion, provenance and recovery |
| Topology | One agent to team, new supervisor, peer or swarm rule | Simpler baseline, coordination benefit, message cost, correlated failure and containment |
| Human authority | Approval timing, reviewer role, sampling, escalation, override | Decision rights, interface, reviewer capacity, queue behavior and appeal |
| Runtime or infrastructure | Queue, sandbox, network, region, orchestration, telemetry | Reliability, isolation, timeout, recovery, data residency and observability |
| Domain or consequence | New population, jurisdiction, financial value, physical effect | Full use-boundary and stakeholder reassessment |
Create a material-change taxonomy
Record the reason, owner, affected workflow, current and proposed versions, changed boundary, expected benefit, new risks, required tests, rollback, review date, and final release outcome. The absence of a source-code change does not mean the operating risk is unchanged.
Use four review depths
A useful operating model separates routine regression, targeted reassessment, full release-gate reassessment, and immediate hold. The default depth should increase when authority widens, external effects become harder to reverse, data sensitivity increases, or a new population or jurisdiction is affected.
- Routine regression. Backward-compatible change inside an already evaluated boundary.
- Targeted reassessment. One affected boundary with a bounded test and reviewer set.
- Full release-gate reassessment. Material change to purpose, consequence, authority, topology, or evidence model.
- Immediate hold. Unapproved change, critical incident, unknown effect, lost traceability, or inability to stop or recover.
Reopen the decision when authority changes
A new tool, broader scope, different token audience, remote agent, additional delegation hop, or changed human approval path is a release-relevant change even when the model and prompt are identical.
NIST's agent identity work and MCP authorization guidance both emphasize identification, authorization, auditing, resource boundaries, and scope. [S2] [S5]
Reopen the decision when evidence changes
A changed source set, retrieval policy, evaluation dataset, monitoring coverage, or retention rule can invalidate prior evidence. Store which evidence version supported the release and what remains comparable after change.
Treat protocol and standard updates as reviewed dependencies
Protocol versions can change capabilities, authorization, task semantics, and security requirements. Track exact versions of MCP, A2A, telemetry conventions, agent frameworks, model APIs, and tool contracts. A specification update is not automatically a production change, but it should trigger dependency review.
Research boundary
The change register is a governance aid, not a universal software-change policy. Review depth must reflect domain obligations, system consequence, evidence quality, and the organization's accepted risk.
Sources
Sources support the linked statements and terminology. They do not certify a system, establish buyer intent, or convert this research into a formal assurance.
- Artificial Intelligence Risk Management FrameworkNIST · Accessed 2026-08-01
Government framework
- Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and AuthorizationNIST NCCoE · Accessed 2026-08-01
Government concept paper
- Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI AgentsNIST · Accessed 2026-08-01
Government technical report
- Model Context Protocol specification, 2026-07-28Model Context Protocol · Accessed 2026-08-01
Technical specification
- Model Context Protocol AuthorizationModel Context Protocol · Accessed 2026-08-01
Technical specification
- Model Context Protocol Security Best PracticesModel Context Protocol · Accessed 2026-08-01
Draft technical security guidance
- Agent2Agent Protocol Specification 1.0A2A Protocol · Accessed 2026-08-01
Open technical specification
- Semantic Conventions for GenAI Agent and Framework SpansOpenTelemetry · Accessed 2026-08-01
Development-stage open telemetry specification
- Securing Agentic Applications Guide 1.0OWASP GenAI Security Project · Accessed 2026-08-01
Open security guidance