How do security teams decide whether to block prompt injection at discovery time or at call time?

Discovery time filtering removes risky tools from model awareness, which can reduce exposure to prompt injection. Call time validation is more flexible because it can evaluate the actual arguments and context. The right choice depends on whether the primary risk is tool visibility, contextual abuse, or both. Many teams will need both layers for defense in depth.

Why This Matters for Security Teams

Prompt injection is not just a model-quality issue. It is a control-placement decision that affects whether an agent can even see a risky tool, or whether the system only evaluates that tool use when the agent actually tries to call it. For agentic systems, that distinction matters because the attack surface is defined by autonomy, not by a fixed workflow. Guidance from the OWASP Agentic AI Top 10 and NHIMG’s Ultimate Guide to NHIs both point to the same operational reality: static assumptions fail quickly when tools, prompts, and secrets are dynamically assembled at runtime.

Discovery-time filtering reduces what the model can reason about, which can shrink exposure in tools-heavy environments. Call-time validation is narrower in scope, but it can inspect the actual arguments, the user intent, the current conversation, and the downstream effect of the action. In practice, teams that only filter at discovery time often miss malicious argument construction, while teams that only validate at call time may still expose too much tool metadata to the model. NHIMG research on the Top 10 NHI Issues shows how often weak identity and privilege controls compound exposure across integrated systems. In practice, many security teams encounter tool abuse only after an agent has already chained actions across multiple systems rather than through intentional testing.

How It Works in Practice

Security teams usually decide by separating the problem into two questions: can the model discover the tool, and should the tool call be allowed if the model requests it? Discovery-time controls are strongest when the concern is tool visibility, sensitive schema exposure, or preventing the model from learning about high-risk functions. Call-time controls are stronger when the concern is contextual abuse, because they can evaluate the full request at the moment of execution. That is where policy-as-code, request context, and runtime identity checks become more important than static allowlists.

A practical pattern is to combine both layers:

• Hide or scope tools by task, tenant, or workflow so the model only sees what it legitimately needs.
• Validate every call against current context, including user intent, conversation state, policy, and workload identity.
• Use short-lived, task-scoped credentials so a successful injection has less time to be abused.
• Log both discovery decisions and call decisions so investigators can reconstruct whether the issue was exposure or execution.

This is especially relevant for agents that can chain tools or act on behalf of a user across SaaS, code, and data platforms. The OWASP Agentic Applications Top 10 and the State of Non-Human Identity Security both reinforce that runtime authorization and identity posture matter when actions are autonomous. Call-time controls should be coupled with workload identity, such as OIDC-based proof or SPIFFE-style identities, so the system can verify what the agent is before it decides what the agent may do. These controls tend to break down when tool access is deeply embedded in custom orchestration layers because the policy point is no longer isolated from the execution path.

Common Variations and Edge Cases

Tighter discovery-time filtering often increases engineering overhead, requiring organisations to balance reduced model exposure against slower onboarding and more brittle tool catalogs. That tradeoff is real, especially when teams rely on many low-trust plugins, rapidly changing APIs, or agent frameworks that generate tool schemas on the fly. There is no universal standard for the split between discovery-time and call-time enforcement yet, so current guidance suggests using discovery-time filtering for high-risk or unnecessary tools and call-time validation for anything that must remain reachable.

Edge cases usually appear when the model should know a tool exists, but should not see all of its arguments or full capability set. In those cases, partial disclosure plus strict runtime checks can work better than all-or-nothing blocking. Another common exception is workflows with third-party connectors, where the risk is not only prompt injection but also inherited privilege from the underlying NHI. NHIMG’s NHI Lifecycle Management Guide is useful here because lifecycle controls, credential rotation, and offboarding often determine whether a blocked tool still remains exploitable through a separate path. Best practice is evolving, but teams should assume that discovery-time filtering alone will not stop a determined agent from reaching the same outcome through another tool chain.

Related resources from NHI Mgmt Group

• How do security teams decide whether secretless injection is enough?
• How do security teams decide whether sampling is safe for data discovery?
• How do teams decide whether to block code on security findings or just attach advisory feedback?
• How should security teams test whether prompt injection telemetry can name the compromised agent?