Runtime monitoring exposes the gap in AI agent security scans

At a glance

What this is: ClawSecure frames AI agent runtime security as continuous behavioural monitoring that catches threats a one-time scan misses, including prompt injection, credential theft, code drift and exfiltration.

Why it matters: This matters because IAM and NHI teams cannot govern agent risk with install-time checks alone when an agent’s access can be misused after deployment and must be monitored at runtime.

By the numbers:

• 41% of popular OpenClaw skills carry security vulnerabilities, and runtime monitoring is what catches the ones that pass a scan then misbehave later.

Context

AI agent runtime security is the control layer that watches an agent after deployment, not just before it is installed. The core gap is simple: a clean pre-install scan cannot tell you whether an agent will later follow injected instructions, misuse delegated access, or begin moving data out of bounds.

That gap is especially important where agents inherit identity, tool access, or workflow authority from human and non-human identity programmes. In practice, runtime monitoring becomes the boundary between approved capability and runtime misuse, which is why agent identity governance belongs in the discussion from the start.

Key questions

Q: What breaks when AI agents are not red teamed before deployment?

A: Without adversarial testing, teams discover prompt injection, tool misuse, and data leakage only after the system is already trusted with real access. The failure is not usually a software crash. It is an apparently normal AI action that crosses a policy boundary, exposes information, or triggers an unsafe workflow. That is why pre-deployment red teaming is a governance control, not a nice-to-have test.

Q: Why do AI agents create a different access-risk profile than traditional applications?

A: AI agents can chain actions, call multiple tools, and change behaviour based on context, so one credential can enable more than one operational path. That means the risk is not just whether the agent authenticates, but how far it can move once inside. The key measure is privilege scope, not token count.

Q: What signals show that an AI agent is operating outside its intended purpose?

A: Look for mismatches across identity, data, model behaviour, posture, and environment. A clean authorization trail is not enough if the agent starts touching unrelated data, follows injected instructions, drifts from its known configuration, or continues acting in a way that does not fit the task.

Q: When should organisations prioritise runtime mediation over post-action review for AI agents?

A: As soon as an agent can touch production systems, external APIs, money movement, or sensitive data. Post-action review can explain what happened, but it cannot stop an irreversible action once the model has already executed it. Runtime mediation is the control that prevents impact, not just records it.

Technical breakdown

Why install-time scans miss runtime agent behaviour

A scan is a point-in-time check. It can verify code, configuration, and permissions at the moment of inspection, but it cannot observe how an AI agent behaves once it starts reading content, calling tools, or accepting new instructions. That matters because agent risk is often introduced later through fetched pages, updated packages, or chained tool calls. Runtime security therefore shifts the unit of control from static artefact assurance to live behavioural assurance. The monitoring problem is not just whether the code is clean, but whether the agent is acting within its intended policy envelope after it is live. See the Agentic AI Security Guide.

Practical implication: Treat install-time scanning as necessary but incomplete, and require continuous runtime controls for any agent with tool access or delegated authority.

What runtime monitoring looks for in an AI agent

Runtime monitoring focuses on behavioural signals that indicate misuse or compromise. Those signals include unexpected network destinations, unusual tool-call frequency, access to credential files, deviations from a normal execution pattern, and sequences of actions that together form an exfiltration path. The value is not any single indicator in isolation, but the pattern across time. For agent governance, this is closer to runtime policy enforcement than traditional endpoint integrity checking. It also creates evidence for attribution, because monitoring can show what the agent did, when it changed, and which actions crossed a boundary. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Instrument agents so behavioural baselines, tool invocations, and sensitive-file access are observable before you rely on them in production.

How drift detection closes the sleeper-agent problem

Drift detection addresses the case where an agent or skill changes after it has already been approved. A fresh hash and re-audit on change lets defenders catch a component that was safe at install but later receives a malicious update, altered instructions, or a hidden payload. This is not the same as scanning once and freezing the result. In AI agent environments, trust has to be revocable because the thing you approved can evolve. That is why continuous re-validation is a governance control, not just a detection feature. See the Agentic AI Identity Guide.

Practical implication: Require re-audit on every meaningful component change so approval does not silently expire when the agent or its dependencies drift.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI agent’s legitimate runtime access into a persistent path for credential theft, data exfiltration, or unauthorised action.

1. Entry occurs when a benign-looking agent or fetched content introduces prompt injection, a malicious update, or another behavioural trigger after the initial scan has already passed.
2. Credential access happens when the agent reads or handles credentials, secrets, or token material during runtime and begins using them within its tool chain.
3. Escalation follows when the agent’s legitimate access is repurposed into broader data collection, unexpected tool invocation, or an exfiltration path the original scan never observed.
4. Impact is achieved when the agent leaks data, misuses delegated authority, or performs actions outside its intended policy boundary.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime monitoring is becoming the control boundary for AI agents, not a supplemental feature. Once an agent can read content, call tools, and act on delegated authority, static assurance stops being enough. The security question moves from install-time trust to live governance of behaviour, which is why runtime monitoring should be treated as part of the identity and access model rather than as an endpoint add-on. Practitioners should design controls around what the agent can do after approval, not what its code looked like on inspection.

AI agents create a new trust problem: they can be both authorised and unsafe. Traditional access controls assume that a permitted actor will behave predictably until review catches up. That assumption fails when prompt injection, drift, or tool misuse can happen after the control decision has already been made. The practical consequence is that agent governance must include continuous observation, not just policy assignment. Teams should assume that legitimate access can become malicious within the same operational session.

Continuous re-validation is now a non-human identity requirement, not just an AI control. When an agent’s hash, manifest, or behaviour changes, the trust decision must change with it. That makes the identity lifecycle of agents more important than the initial approval event, especially where delegated access is broad or opaque. The right question is whether the system can revoke trust as fast as it grants it, and practitioners should treat that as a core NHI governance test.

Prompt injection is the named concept that exposes the runtime gap most clearly. The article shows that the threat is not only malicious code, but malicious instructions delivered through normal content flows after deployment. That means the security model has to inspect behaviour, tool use, and data movement in the live session, not just artefacts before release. Practitioners should align runtime controls to the behaviour of the agent, not the assumed cleanliness of the package.

Metadata-only monitoring is a governance compromise that can make continuous oversight deployable. The operational challenge in agent security is often that teams want observability without exporting secrets, source code, or conversation content. Watching component names, hashes, permission manifests, and behavioural telemetry preserves enough evidence for control while limiting unnecessary data movement. Practitioners should use that pattern where privacy, confidentiality, or regulatory constraints make full-content inspection impractical.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Prompt injection is now a runtime governance problem, not just a content-safety issue. Once an agent can fetch content, accept instructions, and invoke tools, the attack surface shifts to live behaviour. Teams need policy and observability that move with the session, because the relevant decision point is no longer installation but execution.

Agent identity has to be revocable in motion. If a component hash changes, if tool behaviour drifts, or if a permission manifest no longer matches the approved task, the trust decision should change immediately. That is the operational difference between supervising a software package and governing a non-human actor.

Least-privileged AI access changes incident likelihood materially: systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. That gap shows why runtime controls, scoped permissions and live re-validation must be designed together rather than treated as separate projects.

For practitioners

• Implement continuous runtime monitoring for every production agent Do not rely on a pre-install scan as the final trust decision. Monitor tool calls, network destinations, credential-file access, and behavioural drift while the agent is live.
• Scope delegated access to the minimum runtime task Remove broad standing access from agents that only need narrow action windows. Tie permissions to the specific task or request the agent is processing.
• Re-audit agents whenever their hash or manifest changes Treat code drift, dependency updates, and manifest changes as trust-relevant events. Re-validate the component immediately instead of waiting for a scheduled review.
• Instrument exfiltration signals before rollout Baseline normal behaviour first, then alert on unusual destinations, credential reads, or tool-call sequences that create a data-out path.

Key takeaways

• A one-time scan cannot see the runtime behaviours that make AI agents dangerous after deployment.
• The article’s evidence points to behavioural drift, prompt injection and exfiltration as the main control gaps.
• Continuous monitoring, drift re-auditing and scoped delegated access are the controls that change the risk profile.

Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Observability, Audit and Incident Response Guide · AI Agent Authorisation Guide · Gemini CLI prompt injection flaw 2025

Key terms

• AI Agent Runtime Security: AI Agent Runtime Security is the protection of an AI agent while it is actively making decisions and using tools. It covers runtime controls for identity, permissions, prompts, memory, network access, and action approval, reducing the chance of hijacking, unauthorized data use, or unsafe autonomous behavior in production.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.
• Metadata-Only Monitoring: Metadata-only monitoring captures activity context without recording detailed visual evidence such as screenshots. It is commonly used as a lower impact baseline for insider threat programs, because it preserves some visibility into user actions while reducing privacy concerns, storage overhead, and the volume of sensitive evidence collected.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and agentic AI identity for practitioners who need to govern delegated access and runtime risk. It is designed for security teams building durable controls around non-human actors, not just point-in-time reviews.