Approval should sit with the platform and security owners who can verify the runtime artifacts, not only with application developers. The decision should depend on the observed AI-BOM, declared-vs-observed reconciliation, and confirmed behavioral patterns that show the agent is operating within its intended envelope.
Why Go-Live Approval Has to Cover Runtime Agent Behaviour
AI agents that make dynamic tool calls are not shipping like conventional applications. Their real risk is not just the code path, but the action path they can assemble at runtime by combining prompts, tools, secrets, and external systems. That is why approval must be anchored in platform and security ownership, not only application delivery. The relevant question is whether the agent can prove its intended envelope through observed behaviour and an auditable AI-BOM, not whether the feature branch looks complete. Guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime accountability, because static sign-off misses emergent behaviour. NHI Management Group has shown how quickly exposed AI credentials become operational risk in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where attackers moved fast once secrets were available. In practice, many security teams encounter uncontrolled tool use only after the agent has already reached production and executed beyond its intended scope.
What a Safe Go-Live Review Actually Checks
Approval should validate what the agent can do at runtime, not just what the development team intended. That means reviewing declared versus observed tool usage, the identity and trust boundaries attached to each tool call, and whether the agent receives just-in-time credentials with short TTLs instead of standing privileges. For agentic systems, workload identity is the control point: the platform should prove which agent instance is acting, with what context, and under what policy.
A practical review normally includes:
- An AI-BOM that lists models, tools, connectors, policies, and secret dependencies.
- Observed behaviour from staging or controlled trials, including lateral tool chaining and escalation attempts.
- Runtime policy checks using policy-as-code, evaluated at request time rather than as a one-time gate.
- Secret handling that avoids long-lived tokens and revokes access automatically when the task ends.
- Approval by platform and security owners who can reject mismatches between declared and observed behaviour.
This is consistent with NHI governance lessons from Ultimate Guide to NHIs, where secret sprawl and fragmented control repeatedly undermine assumed safeguards. It also aligns with the implementation direction in the CSA MAESTRO agentic AI threat modeling framework, which treats agent behaviour and dependency mapping as first-class review items. The current guidance suggests using workload identity and runtime policy evaluation together, because one without the other leaves gaps in verification. These controls tend to break down in highly unstructured agent workflows where tool choice is open-ended and output cannot be fully bounded in advance.
Where Teams Misjudge the Approval Boundary
Tighter approval gates often increase release overhead, requiring organisations to balance speed against the risk of an agent gaining more autonomy than intended. The common mistake is treating developer sign-off as sufficient when the real authority should rest with the teams that can inspect the runtime envelope and revoke access if behaviour drifts. That tradeoff becomes especially visible in environments with many tools, multiple model providers, or frequent prompt and connector changes, because the agent can behave differently after each update.
There is no universal standard for this yet, but best practice is evolving toward continuous re-approval whenever the AI-BOM changes, tool scopes expand, or observed behaviour diverges from the original design. Security teams should look for evidence that the agent cannot persist credentials, cannot exceed purpose-built tool scopes, and cannot silently inherit broader platform rights. The lessons from OWASP NHI Top 10 and the latest OWASP agentic guidance reinforce that dynamic agents need dynamic approval boundaries, not annual paperwork. Organisations also need to remember the speed of compromise seen in Moltbook AI agent keys breach style incidents, where access materialised faster than most review processes could react.
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 AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Addresses agent misuse from dynamic tool calls and runtime behaviour. |
| CSA MAESTRO | T1 | Maps directly to agent threat modeling and approval of tool-enabled workflows. |
| NIST AI RMF | Supports governance of AI behaviour, accountability, and lifecycle risk decisions. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Relevant to credential handling for dynamic agent tool access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is essential when agents call tools dynamically. |
Require runtime controls and reassess any agent whose observed actions exceed its approved tool envelope.
