Because the main risk appears when the agent turns intent into action. Deployment-time approval only says the configuration looked acceptable at one point in time, while decision-time controls can block unsafe behaviour in the exact session where it would cause harm.
Why the control belongs in the moment of action
Agentic systems are not risky because they were once approved, they are risky because they can make a fresh choice in a live context. Decision-time control checks the current task, current data, current tool, and current blast radius before the action executes, which is where unsafe behaviour becomes real. Deployment-time review can still be useful, but it cannot see the exact request that the agent is about to make.
That distinction matters because the same agent can be safe in one session and unsafe in another. A model, prompt, tool list, or policy bundle may look acceptable at deployment, yet the live request may involve a different user, a different target system, a different privilege set, or a poisoned input. Decision-time controls are what stop the system from turning changing context into irreversible action.
Why deployment-time approval is not enough
Deployment-time controls answer a configuration question: was this agent allowed to exist, connect, or ship in this form? They do not answer the more important runtime question: should this specific action be allowed right now? For agentic ai, that runtime question is the one that determines whether an instruction becomes a data pull, an email, a payment, a ticket, a code change, or an administrative action.
That is why static approval tends to degrade into a checkbox. Once the agent is deployed, the actual risk moves with the conversation, the memory state, the tool chain, and the surrounding principal. A control that only validates the build or release leaves a gap between design intent and live execution, and attackers or misconfigurations can exploit that gap by steering the agent into unsafe actions after launch.
Decision-time control is also better aligned with least privilege. The practical question is not whether the agent can ever use a tool, but whether it should use that tool for this specific action, with this scope, at this moment. That is the point at which a policy engine, human approval, or step-up check can still prevent overreach before the action leaves the boundary of the session.
What decision-time control needs to inspect
Effective decision-time control evaluates the live request, not just the identity of the agent. It should consider the active principal, requested tool or resource, sensitivity of the target, scope of authority, and whether the action crosses a threshold that needs extra approval. In practice, the control must be close enough to execution to compare intent, context, and policy in one place.
- Verify the current session and principal, not only the deployed configuration.
- Check whether the action is within the agent’s current authority and task scope.
- Escalate when the action would touch sensitive data, external systems, or irreversible state.
- Re-evaluate if the input, memory, or downstream request changes after initial approval.
For agentic systems, this is the difference between a standing permit and a per-action decision. The first is static trust; the second is a live boundary. If the boundary is missing, the system can remain “approved” while still being one prompt away from a harmful action.
Risk and Threat Considerations
When controls sit only at deployment time, the main exposure is that an attacker or faulty workflow can wait until runtime to trigger the bad behaviour. Prompt injection, tool misuse, poisoned context, privilege overreach, and trust abuse all become more damaging when the decision is deferred until after the unsafe action is already queued. The closer the control is to execution, the less room there is for hidden context to change the outcome.
Failure mechanism: A one-time approval cannot reliably account for session drift, changed context, or adversarial input that appears after deployment, so the agent executes with authority that is no longer appropriate for the current action.
Impact: The result can be unauthorized data access, destructive tool use, policy bypass, or cascading actions that are hard to unwind once the agent has already acted.
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 addresses the attack surface, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST AI RMF set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Decision-time checks limit live privilege abuse by agents. |
| Recommendation — Enforce per-action authorization before agents use sensitive tools or data. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Live authorization is needed to keep agent actions within current privilege. |
| Recommendation — Apply least privilege at the moment of action, not only at deployment. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Zero trust requires continuous verification of each request from the agent. |
| Recommendation — Verify every agent request before granting access or execution. | ||
| ISO/IEC 42001:2023 | AI Management System | Agentic AI governance must control runtime decisions, not just releases. |
| Recommendation — Define governance so AI actions are approved and monitored in operation. | ||
| NIST AI RMF | Govern | AI risk governance must address operational decision points where harm occurs. |
| Recommendation — Place AI risk controls around live decision-making and oversight. | ||
Practitioner Guidance
What to prioritise: Put the enforcement point where the agent actually crosses from reasoning into action. If the control cannot see the current request, the current principal, and the current target, it is too early in the pipeline to prevent harm.
Decision rule: If the action can change external state, reveal sensitive data, or spend meaningful privilege, require a decision-time check rather than relying on deployment approval alone. Reserve deployment review for admission, policy setup, and baseline hardening, not for the final authorisation decision.
What good looks like: The agent can still operate autonomously inside safe bounds, but every sensitive action is individually judged, logged, and attributable at the moment it matters. That is the control pattern that preserves utility without turning the deployment approval into false comfort.
Practitioner takeaway: Deployment-time approval validates the agent’s starting conditions; decision-time control validates the action that actually creates risk. For agentic AI, that second check is the one that matters most.
Related resources from NHI Mgmt Group
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
- How should security teams govern machine identity credentials in agentic AI environments?
- What are the main reasons AI agents struggle to achieve enterprise-scale deployment?
- When should organizations reconsider the deployment of AI agents?