Execution-time risk

Execution-time risk is exposure that appears while a system is actively operating, not just during design or testing. For AI agents, that includes tool misuse, context leakage, and behavioural drift that only show up when the agent is interacting with live systems and data.

Expanded Definition

Execution-time risk refers to the hazards that emerge only when a system is live and making decisions, taking actions, or handling data in production conditions. It is distinct from design-time risk, which can be assessed in architecture reviews, secure coding, or pre-deployment testing. For AI agents and other automated systems, execution-time risk includes failures that depend on real context, such as tool misuse, privilege overreach, prompt injection effects, context leakage, and state changes that alter subsequent behaviour. These issues are especially relevant where an agent has execution authority over APIs, internal systems, or sensitive data, because the risk is created by the combination of autonomy, permissions, and live inputs.

The concept is still evolving in industry usage, so definitions vary across vendors and frameworks. NHI Management Group treats it as a governance term that focuses on runtime exposure rather than theoretical weakness. That aligns well with the risk-centred structure of the NIST Cybersecurity Framework 2.0, even though the framework does not use this exact phrase. The most common misapplication is treating execution-time risk as a testing-only issue, which occurs when teams assume pre-production validation captures failures that only appear under live data, live privileges, and real operator workflows.

Examples and Use Cases

Implementing execution-time risk controls rigorously often introduces monitoring and permission constraints, requiring organisations to weigh autonomy and speed against containment and visibility.

• An AI agent is allowed to query a ticketing system and accidentally retrieves customer records because runtime context includes broader data than the task needed.
• A support automation agent sends an approval message through a live workflow tool after a prompt injection alters its tool-selection behaviour during operation.
• A Non-Human Identity used by an orchestration service has standing permissions that are harmless in staging but create material exposure once the same identity operates against production secrets.
• An LLM-backed assistant works correctly in test cases but drifts in live use because changing prompts, conversation history, and tool outputs reshape its decisions over time.
• A security team detects that an agent’s use of OWASP guidance for LLM applications is insufficient once the model begins taking live actions rather than merely generating text.

These examples show why the term is useful in operational reviews: the failure is not just whether the system was built securely, but whether it remains safe once exposed to production inputs, privileges, and business processes.

Why It Matters for Security Teams

Execution-time risk matters because many security controls are strongest before deployment and weaker once a system starts interacting with real users, data, and connected services. That gap is especially important for autonomous software entities and NHI because the runtime environment can transform a low-risk design into a high-impact control problem. If an agent can call tools, reuse context, or inherit permissions, then the security team must understand not only what the system is allowed to do, but what it actually does under pressure, ambiguity, or adversarial input. This is where governance, access control, monitoring, and incident response converge.

For security operations, the practical lesson is that execution-time risk is often discovered through anomalies, unexpected transactions, or policy violations after a live event has already occurred. Teams should connect the term to runtime logging, session-level controls, least privilege, and rollback mechanisms, using the risk management structure reflected in the NIST Cybersecurity Framework 2.0. Organisationally, this becomes unavoidable only after an agent, service account, or automated workflow behaves in production in ways that testing never exposed.

Related resources from NHI Mgmt Group

• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• When does just-in-time access reduce risk in hybrid identity environments?
• When does just-in-time access reduce risk for autonomous agents?
• When does just-in-time access reduce risk for NHIs?