Decide by risk, purpose, and data sensitivity. Block high-risk actions such as prompt injection, credential exfiltration, and sharing prohibited data categories. Route sensitive but legitimate requests to approved internal models or apply tokenisation so the task can continue without exposing regulated data.
Why This Matters for Security Teams
Blocking versus routing AI interactions is really a policy decision about what the organisation will allow an autonomous workload to attempt, what data it may touch, and how much damage a tool-enabled model could do if it is manipulated. The wrong default is usually to “let it try” and inspect later. For agentic systems, that is too late: a prompt injection can turn a harmless request into credential theft, lateral movement, or secret leakage. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but AI routing adds a runtime decision layer that classic ticket-based approvals do not cover.
Security teams also need to separate legitimate business intent from unsafe execution paths. A finance assistant may be allowed to summarise invoices, but not to retrieve raw customer records. A developer agent may be allowed to open a pull request, but not to read production secrets. That distinction matters because AI systems often operate with delegated tool access, not human supervision. NHIMG research shows how quickly exposed credentials can be abused in practice, including the DeepSeek breach and the JetBrains GitHub plugin token exposure, both of which show how secrets become an immediate control failure rather than a theoretical risk.
In practice, many security teams discover AI routing gaps only after a tool-using model has already touched data it should never have seen.
How It Works in Practice
A practical decision model starts with three questions: what is the user or agent trying to do, what data is involved, and what downstream action would the model trigger if approved? If the answer includes prompt injection, secret extraction, exfiltration, external sharing of regulated data, or irreversible action, the interaction should be blocked. If the request is business-valid but sensitive, it should be routed to a safer execution path such as an approved internal model, a tokenised data service, or a constrained workflow with human approval. The NIST Cybersecurity Framework 2.0 and AI risk guidance from the NIST Cybersecurity Framework 2.0 are useful starting points, but they do not remove the need for AI-specific policy logic.
For agentic ai, routing works best when policy is evaluated at request time, not pre-approved by static role. That means using workload identity, short-lived credentials, and contextual rules that can inspect the prompt, target tool, data classification, tenant, and task intent. A common pattern is:
- Block known unsafe intent, such as credential harvesting or prohibited data disclosure.
- Route sensitive but legitimate work to a private model or isolated environment.
- Apply tokenisation or redaction before the model sees regulated fields.
- Use JIT credentials so tool access expires when the task finishes.
- Log every decision with the reason for block or route.
That control logic should be aligned to AI governance frameworks such as NIST Cybersecurity Framework 2.0, OWASP Agentic AI guidance, and CSA MAESTRO so policy, identity, and runtime enforcement stay connected. These controls tend to break down when the agent can chain tools across multiple systems because the effective risk changes after the first allowed step.
Common Variations and Edge Cases
Tighter blocking often increases operational friction, requiring organisations to balance safety against productivity, false positives, and user trust. That tradeoff is especially visible in customer support, software engineering, and research workflows, where an over-blocking policy can push users toward shadow ai rather than approved routes. Best practice is evolving here, and there is no universal standard for every line between block and route.
One common edge case is sensitive but non-regulated content. For example, internal strategy documents may not be legally protected, but they can still be business critical. Another is mixed-intent prompts, where a user asks for a valid summary and then quietly embeds a request to reveal secrets. In those cases, context-aware authorisation should inspect the full transaction, not just the final prompt. Agentic systems also make static RBAC weaker because an AI agent may behave differently on the next run, even with the same role and tool set. That is why current guidance increasingly favours intent-based controls, short-lived credentials, and workload identity over long-lived access grants. NIST AI risk management guidance and NIST Cybersecurity Framework 2.0 provide the governance frame, while the implementation details should be mapped to DeepSeek breach-style leakage scenarios and token exposure risks like the JetBrains GitHub plugin token exposure.
FRAMEWORK_REFS--- [{"framework_code":"OWASP-AGENTIC","control_ref":"A-02","relevance_note":"Covers prompt injection and unsafe tool use in agentic workflows.","framework_summary":"Block unsafe intents at runtime and only route approved tasks through constrained tools."},{"framework_code":"CSA-MAESTRO","control_ref":"TA-03","relevance_note":"Maps to runtime policy, trust boundaries, and agent tool governance.","framework_summary":"Enforce context-aware policy checks before any agent reaches data or tools."},{"framework_code":"NIST-AIRMF","control_ref":null,"relevance_note":"Supports governance, measurement, and oversight for AI risk decisions.","framework_summary":"Define risk thresholds and decision ownership for block-versus-route controls."}]Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
