Security teams should govern the whole agent bundle as the release unit, not just the model file. That means tracking prompts, skills, MCP configs, code and deployment metadata together, with one approval trail and one rollback point. Without that, the same agent can behave differently after a small unreviewed change.
What a versioned agent bundle should contain
Security teams should treat a versioned AI agent bundle as the release artifact, not just the model checkpoint. The bundle needs to capture the prompt set, skills, MCP configuration, code, deployment metadata and any attached policy in one versioned unit so the approved behaviour is reproducible. That gives you a single point of truth for review, rollback and forensic comparison.
This matters because agent behaviour is shaped by the full execution context, not the model alone. A prompt tweak, a tool permission change or a connector update can alter outputs, actions and blast radius without changing the model file itself. Versioning the whole bundle makes those changes visible as security-relevant deltas instead of hidden drift.
A good release definition also preserves the relationship between the agent and the systems it can reach. If the bundle can be deployed independently of its tool list, approval trail or environment bindings, then the version number becomes cosmetic. For governance to work, the version must describe what the agent can do, where it can do it and under which controls.
How to review and approve changes safely
Review should focus on the parts of the bundle that can change agent intent, authority or side effects. That includes prompt templates, retrieval sources, tool manifests, connector scopes, environment variables and any code that interprets agent output before execution. A change to any of those should trigger the same level of scrutiny as a model swap if it can alter decisions or actions.
One practical way to govern this is to require the release record to show exactly what changed from the previous approved bundle. That diff should be understandable to reviewers who are not the original builders, because the security decision depends on whether a new instruction, skill or integration expands behaviour in a material way. The approval should attach to the bundle hash, not to a loose collection of files or a ticket comment.
Versioned bundles also make segmented approvals possible. High-risk agents can be reviewed with stronger sign-off when they touch production data, privileged tools or external systems, while low-risk internal assistants may use a lighter path. The key is consistency: the same bundle version should never be approved in one environment and silently modified before deployment in another.
Why rollback and drift control are part of governance
A versioned agent bundle should always have one rollback point, because incident response needs to restore the exact last-known-good behaviour. If prompts, skills and deployment settings are versioned separately, rollback becomes partial and unreliable, and you may restore the model while leaving the unsafe tool path in place. That creates a false sense of recovery.
Security teams should also assume that small, unreviewed changes can create large behavioural shifts. The safest governance pattern is to compare each live deployment with its recorded bundle version and flag any drift in prompts, tool permissions, connectors or configuration. Agentic AI Security Guide is useful here because it frames identity, tools and orchestration as a single threat surface rather than separate operational concerns.
When the bundle is the unit of control, incident investigation becomes much clearer. Teams can ask which version was active, what approvals existed, what tools were reachable and whether the release changed after approval. That is far more defensible than trying to reconstruct behaviour from scattered configuration stores after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Versioned agent bundles govern changes that can expand agent authority or tool access. |
| ASI02 — Tool Misuse | Prompts, skills and MCP configs control which tools an agent can invoke and how. | |
| Recommendation — Track bundle changes that alter agent authority and require re-approval before release. Review tool manifests and connector scopes as part of every approved bundle version. | ||
| CSA MAESTRO | GOVERN — GOVERN | Governance of agent bundles needs lifecycle, approval and rollback controls across the release unit. |
| Recommendation — Define one governed release record for each agent bundle and tie deployment to it. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Bundle versioning must include deployment metadata and environment bindings that affect runtime security. |
| Recommendation — Version deployment metadata with the bundle so environment-specific changes are reviewed before rollout. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | The bundle is a controlled configuration item whose changes need documented approval and traceability. |
| Recommendation — Require formal change approval for any bundle element that can alter agent behaviour. | ||
Practitioner Guidance
What to prioritise: Make the bundle manifest mandatory and immutable at release time. It should enumerate the prompt, skills, tool registrations, environment bindings, policy references and deployment metadata so the security review matches the runtime reality.
What to verify: Confirm that the deployed bundle hash matches the approved release record, and that any post-approval change forces a new approval cycle. If the deployment platform cannot prove that match, the governance control is incomplete.
Decision rule: If a change can affect what the agent can access, invoke or return, treat it as a governed bundle change even when the model weights are unchanged. If it only changes a non-operative label or cosmetic setting, it should not create a new security release.
Practitioner takeaway: Versioning only the model is not enough for agents with tools and delegated actions, because the security decision belongs to the whole executable bundle, not any single component.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org