Use both, but for different reasons. Pre-install scanning helps stop unsafe components before they enter the environment, while runtime monitoring catches prompt injection, drift, and tool abuse after execution begins. A clean scan is not enough if the agent can later be influenced, delegated new authority, or exposed to fresh malicious input.
Why Pre-Install Scanning and Runtime Monitoring Solve Different Agent Risks
Pre-install scanning answers whether a component is acceptable to introduce at all. Runtime monitoring answers whether the agent remains trustworthy once it starts receiving live prompts, tool responses, memory writes, and delegated actions. For agent security, those are different control points, and neither one fully substitutes for the other.
A clean pre-install result only tells you what was visible before deployment. It does not prove the agent will resist prompt injection, malicious tool output, stale context, or policy drift after it begins operating. Runtime controls are needed because the security posture of an agent can change as soon as it interacts with users, external services, or other agents.
That is why a layered approach is stronger than a single gate. Pre-install scanning helps reduce the chance that unsafe code, packages, prompts, connectors, or embedded secrets enter the environment. Runtime monitoring helps detect when a previously acceptable agent starts behaving outside its intended authority or communication pattern.
What Each Control Catches, and What It Misses
Pre-install scanning is best at static review: known vulnerable dependencies, risky configuration patterns, hardcoded secrets, exposed endpoints, and obvious supply-chain issues. It is useful when you can evaluate the asset before it is trusted, copied into production, or connected to sensitive tools.
Runtime monitoring is best at behavioural detection: unexpected tool calls, unusual data access, delegation changes, prompt injection attempts, memory poisoning, and action sequences that do not match the approved use case. Agentic AI Security Guide is useful here because it frames the agent attack surface as a combination of inputs, memory, tools, orchestration, and identity, not just the initial artifact.
The common mistake is treating static approval as proof of ongoing safety. An agent can pass pre-install review and still become dangerous if it later inherits new authority, accepts unsafe instructions, or chains benign actions into harmful ones. Runtime telemetry is what exposes that change in state.
How Teams Should Combine Scanning, Monitoring, and Access Control
The most reliable pattern is to use pre-install scanning as a release gate and runtime monitoring as an enforcement and detection layer. The first reduces the number of bad components you have to trust; the second limits the blast radius when an approved agent behaves unexpectedly.
For teams that need a practical governance baseline, Agentic AI Security Policy Template helps anchor the lifecycle question, because agent registration, monitoring, human oversight, and retirement need to be defined together rather than as separate controls.
Access control matters as much as observability. If an agent can call tools, move data, or act on behalf of a user, then monitoring should be paired with least privilege and explicit approval rules. AI Agent Authorisation Guide directly supports that decision by focusing on task-scoped access, per-action policy decisions, and delegated authority.
When the deployment includes multiple agents or shared channels, runtime checks should also cover trust boundaries between components. Multi-Agent and A2A Security Guide is relevant because inter-agent communication, signed identity claims, and delegation chains can create attack paths that no pre-install scan will fully predict.
Risk and Threat Considerations
Agent security risk is not limited to unsafe software entering the environment. The bigger exposure often appears after deployment, when an agent is influenced by malicious input, given broader authority than expected, or allowed to reuse trust across tools and conversations.
Failure mechanism: A component may be clean at install time but later be steered into unsafe action by prompt injection, poisoned memory, unsafe delegation, or tool misuse. The failure is usually a control gap between static approval and dynamic behaviour.
Impact: The agent can leak data, perform unintended actions, or widen its own blast radius through legitimate-looking requests, which makes compromise harder to spot and contain.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Agent runtime abuse often shows up through unsafe tool calls after deployment. |
| ASI03 — Identity & Privilege Abuse | The question turns on delegated authority and privilege changes after launch. | |
| ASI06 — Memory & Context Poisoning | Runtime monitoring must catch poisoned context that bypasses a clean install-time scan. | |
| Recommendation — Monitor and restrict agent tool calls to approved actions and destinations. Enforce per-action authorization and least privilege for agent authority. Detect and isolate contaminated context before it alters agent decisions. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Pre-install scanning is a malicious-content gate before components enter service. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Runtime monitoring depends on reviewing agent activity and anomalous actions. | |
| AC-6 — Least Privilege | Agent security depends on limiting authority even when software scans are clean. | |
| Recommendation — Scan components before deployment to block known bad code and artifacts. Review agent audit records for abnormal tool use and privilege changes. Constrain agent permissions to the minimum needed for each task. | ||
| NIST Zero Trust (SP 800-207) | ZT-NIST-207 — Zero Trust Architecture | Continuous verification is the right model when trust can change after deployment. |
| Recommendation — Verify each agent request continuously instead of trusting initial approval. | ||
| MITRE ATT&CK | T1204 — User Execution | Prompt injection and malicious instructions rely on action being triggered after exposure. |
| Recommendation — Hunt for triggered agent actions that follow untrusted input paths. | ||
Practitioner Guidance
What to prioritise: Treat pre-install scanning as a trust filter, then decide what runtime signal proves the agent is still operating within its approved envelope. If you only have budget for one improvement, choose the one that reduces the highest-consequence action path, not the one that is easiest to automate.
What to verify: Confirm that runtime alerts are tied to concrete agent behaviours, such as unexpected tool invocation, new data destinations, privilege expansion, or abnormal delegation. A log that merely records prompts is usually too weak to support an operational decision.
Practitioner takeaway: The right question is not which control is “better”, but whether you have both a pre-deployment gate and a live control that can still intervene after the agent starts acting.
Related resources from NHI Mgmt Group
- What breaks when security teams rely only on scanning and pre-runtime checks?
- Should teams rely on image scanning or runtime monitoring for container security?
- What breaks when security teams rely only on static scanning for agent dependencies?
- What do security teams get wrong about container monitoring when they rely only on pre-production controls?