Why do static scans fail to stop malicious agent behaviour?

Why This Matters for Security Teams

Static scanning is useful for finding obvious defects in code, prompts, and attached files, but it does not observe the agent’s actual decision path at runtime. That gap matters because malicious behaviour often emerges only after the agent receives a goal, selects a tool, chains actions, or reuses credentials across steps. This is why current guidance around agentic systems increasingly emphasises runtime policy, context-aware authorisation, and short-lived access rather than inspection alone, as reflected in the OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework.

For NHI programs, the real problem is not just malicious code, but delegated identity with too much room to improvise. An agent can appear benign in a scan and still misuse a valid token, pivot through an approved connector, or combine harmless tools into harmful outcomes. NHIMG research on OWASP NHI Top 10 and the LLMjacking threat pattern shows how quickly compromised NHIs become an execution path rather than just a credential issue. In practice, many security teams discover abuse only after the agent has already chained its way into production data or external services.

How It Works in Practice

The control boundary must move from “what was submitted” to “what the agent is allowed to do right now.” Static scans can still catch unsafe prompts, exposed secrets, or obviously dangerous code, but they cannot judge intent, session context, or whether a tool call is appropriate for the current task. That is why runtime checks, policy-as-code, and workload identity are becoming the practical baseline for agent governance. The agent should prove what it is through a workload identity such as SPIFFE or OIDC, then receive only the minimum permissions needed for a single task.

A workable pattern is:

• Authenticate the agent as a workload, not as a person or a long-lived service account.
• Issue just-in-time credentials with short TTLs and automatic revocation after task completion.
• Evaluate policy at each tool request, not only at deployment or code review.
• Constrain tool chaining so one approved action does not silently unlock unrelated access.
• Log decisions, denials, and escalations so investigators can reconstruct the session path.

This aligns with the direction of CSA MAESTRO agentic AI threat modeling framework and the runtime focus of MITRE ATLAS adversarial AI threat matrix. It also matches NHIMG findings in Amazon Q AI Coding Agent Compromised, where delegated execution, not static code alone, created the blast radius. These controls tend to break down in loosely governed plugin ecosystems because each connector adds a new trust edge that static analysis cannot fully model.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, so organisations have to balance stronger containment against developer friction and latency. Current guidance suggests that not every agent needs the same level of scrutiny, but there is no universal standard for this yet. A low-risk retrieval assistant may tolerate broader read access than an autonomous remediation agent that can modify infrastructure or send emails. The policy should reflect that difference rather than forcing a single scanning model across all agent types.

Edge cases also appear when the agent works across multiple tenants, nested tools, or human-in-the-loop approvals. A static scan might flag one harmful instruction, yet miss a benign-looking sequence that becomes dangerous only after the second or third tool call. That is why security teams should treat prompts, code, and attachments as inputs to a living session, not as the whole control surface. NHIMG’s research on the Gemini AI Breach and CoPhish OAuth Token Theft via Copilot Studio highlights how prompt injection and token abuse can bypass static assumptions while still looking operationally normal.

The practical takeaway is simple: static scanning remains a useful input control, but it cannot be the final gate for autonomous behaviour. When agents can reason, chain tools, and act under delegated authority, the decisive safeguard is runtime enforcement with short-lived permissions and explicit context checks.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• When do AI agent credentials create more risk than they reduce?