Agentic AI code execution risk is moving into runtime workflows

At a glance

What this is: This article argues that agentic AI is moving code execution into runtime workflows, where autonomous systems generate and run logic outside traditional review gates.

Why it matters: It matters because IAM, PAM, and application security teams now have to govern execution authority, tool access, and privileged runtime behavior together, especially where AI agents can act like high-trust non-human identities.

By the numbers:

• According to Gartner, 33% of enterprise software applications will use agentic AI by 2028, with roughly 15% of day-to-day work decisions made autonomously.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Apiiro's analysis of agentic AI code execution risk in runtime workflows

Context

Agentic AI changes the application security problem because execution is no longer confined to code written, reviewed, and deployed through a controlled pipeline. AI code execution now happens inside live workflows, where agents interpret context, choose tools, and generate actions in real time. That creates a new governance gap for both application security and non-human identity control, because the runtime entity making the decision is not a human user and not a conventional service.

The primary issue is not just unsafe code. It is the combination of autonomous planning, broad permissions, and opaque execution context. When an agent can call interpreters, invoke APIs, or chain actions across systems, the question becomes who or what is authorised to do that work, under which conditions, and with what blast radius. That is why this topic sits at the intersection of AI governance, IAM, and NHI oversight.

For most organisations, this is an acceleration of a familiar pattern rather than a wholly new class of risk. The difference is that the execution boundary has moved closer to production, and the control model has not kept pace.

Key questions

Q: How should security teams govern AI agents that can change actions at runtime?

A: Security teams should govern runtime AI by correlating identity, data, and intent before trusting an action path. If the system can select tools or alter its sequence mid-session, a static access policy is not enough. The control objective becomes contextual verification of what the agent is doing, why it is doing it, and whether the data touched matches the approved purpose.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What breaks when code execution is driven by agent context instead of review gates?

A: Review gates lose visibility when execution is generated at runtime from context, memory, or retrieved data. Security teams no longer have a stable artifact to inspect before production. That breaks assumptions about traceability, approval timing, and separation between data and instructions, which is why runtime controls and provenance tracking become essential.

Q: Who is accountable when a compromised AI agent misuses delegated access?

A: Accountability usually spans the business owner of the workflow, the team that issued or approved the credential, and the vendor if a third-party integration was involved. The critical governance question is not who logged in, but who allowed the delegation chain to exist and remain valid. That chain must be documented before incidents occur.

Technical breakdown

Why agentic AI turns code execution into a runtime capability

Traditional applications separate development, deployment, and execution. Agentic AI compresses those phases because the system can generate logic, select tools, and run code during normal operation. That means execution decisions are made at runtime from current context rather than from a static build artifact. The result is a moving attack surface where security teams cannot rely on review gates alone to see what will execute next. Execution behaviour may be transient, conditional, and invisible to standard source-code controls.

Practical implication: Treat runtime execution paths as first-class assets and inventory them alongside source code, pipelines, and service permissions.

How context becomes instruction in AI code execution workflows

Agentic systems consume more than prompts. They ingest documents, logs, tickets, API responses, memory, and other retrieved data, then use that material to plan actions. When untrusted content influences tool selection or code generation, the boundary between data and instructions weakens. This is why indirect prompt injection and poisoned context matter in application security: the agent may execute code because the input looked operationally normal, not because a human issued a malicious command. The risk is architectural, not merely linguistic.

Practical implication: Segment external context from execution authority and inspect where retrieved data can alter tool choice or code generation.

Why permission scope magnifies AI execution risk

Most agentic platforms rely on service-level permissions so the system can complete tasks without constant human approval. That makes operational sense, but it also means any execution flaw inherits the agent’s full authority. If the agent is misled, the resulting action can look fully authorised even when the underlying intent was manipulated. In identity terms, the agent behaves like a high-trust non-human identity whose privilege can be abused through execution logic rather than credential theft alone. Governance must therefore cover both access and behaviour.

Practical implication: Constrain agent privileges to the smallest task boundary possible and require step-up controls for high-impact actions.

Threat narrative

Attacker objective: The attacker wants to turn the agent’s legitimate execution authority into unauthorized code execution that looks like normal automation.

1. Entry occurs when untrusted content, a malicious dependency, or a poisoned memory entry reaches the agent’s context and influences runtime decisions.
2. Escalation happens when the agent uses legitimate credentials, interpreters, or automation hooks to generate and execute code with broader authority than the original intent justified.
3. Impact follows when the executed actions alter systems, expose data, or propagate unsafe dependency choices across trusted workflows.

NHI Mgmt Group analysis

Agentic AI creates an execution governance gap, not just a prompt risk. The central security problem is that code now runs as part of reasoning, not only as part of deployment. That means application security controls built around review gates, static artifacts, and known release windows are missing the place where risk now forms. Practitioners should treat execution authority as a governed asset, not a hidden implementation detail.

AI agents are emerging as privileged non-human identities with behaviour that must be constrained. When an agent can select tools, invoke interpreters, and act through service credentials, its identity is defined by both access and runtime decision-making. That puts the topic squarely inside NHI governance, because the question is no longer whether the identity exists, but how much it can do once context is manipulated. Teams need policy, lifecycle, and telemetry for the agent itself.

Context poisoning is the named failure mode this article exposes. The article shows that execution risk often begins before a command is run, when retrieved data, memory, or dependency selection corrupts the agent’s decision path. That is a more precise control gap than generic prompt injection because it captures how runtime context becomes executable behaviour. Practitioners should map this to continuous context validation and execution-scoped controls.

Permission scope is now the blast-radius variable that matters most. Broad service permissions make autonomous systems operationally useful, but they also turn small execution mistakes into enterprise events. This is where IAM and PAM intersect with AI governance: least privilege alone is not enough unless it is enforced at the point of tool invocation and action chaining. Security teams should re-evaluate whether their current access model assumes a human operator behind every decision.

Architectural visibility is becoming a prerequisite for defensible AI security. If teams cannot see which tools an agent can invoke, what context it consumes, and how execution authority changes over time, they cannot distinguish normal autonomy from misuse. That is the governance challenge this category is now creating. Practitioners should move from prompt review to execution mapping across design, code, and runtime.

What this signals

Agentic AI is pushing security teams toward a new control question: not whether code is approved, but whether execution is bounded. That shifts programme design away from static release controls and toward runtime policy, telemetry, and identity-aware governance. The organisations that adapt fastest will be the ones that can see context, privilege, and action as a single security surface.

Execution-aware governance: this is the emerging pattern where teams manage not just who can authenticate, but what an autonomous system can decide and execute once authenticated. It is the right lens for agentic AI because runtime authority is now the exploitable boundary. Security programmes should align this with NIST AI Risk Management Framework and OWASP Agentic AI Top 10 thinking, then map it back to NHI controls.

As agentic adoption scales, the pressure will fall on IAM and PAM teams to define where autonomous systems sit in the identity model. That means stronger service-account lifecycle controls, tighter tool authorisation, and clearer ownership for machine behaviour in production. The programme signal is simple: if you cannot explain an agent’s allowed actions in one sentence, you do not yet control the risk.

For practitioners

• Inventory agent execution paths Map every place an AI agent can generate code, call a tool, or invoke an interpreter. Include hidden runtime hooks, memory-driven workflows, and third-party integrations so you know where execution actually happens.
• Constrain service-level permissions Replace broad credentials with task-scoped access for agents and require escalation controls for actions that can change infrastructure, deploy code, or expose data. Treat the agent as a privileged NHI with bounded authority.
• Separate retrieved context from execution authority Validate documents, logs, tickets, API outputs, and memory before they can influence tool selection or code generation. Use policy gates so untrusted context cannot directly trigger higher-risk execution paths.
• Add runtime monitoring for agent behaviour Track tool use, dependency selection, command execution, and unusual retry patterns during live operation. Focus on behaviour change, because static review will not see the code the agent generates on the fly.

Key takeaways

• Agentic AI changes code execution from a release-time event into a runtime security problem.
• Broad permissions and hidden context make autonomous execution paths harder to detect and easier to abuse.
• IAM, PAM, and application security teams now need execution-aware controls for privileged non-human identities.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Execution-Aware Control: Execution-aware control is a security measure that evaluates what a system is allowed to do while it is running, not only what was approved at build time. It matters when software can generate actions dynamically, because runtime behaviour becomes the primary risk surface.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.

What's in the full article

Apiiro's full article covers the operational detail this post intentionally leaves for the source:

• How agentic code execution changes the SDLC risk model across design, build, and runtime
• Specific failure patterns such as indirect prompt injection, memory poisoning, and unsafe sandboxing
• The article's own breakdown of dependency-selection risk and confused-deputy behaviour in autonomous systems
• Implementation-oriented guidance on mapping architecture changes to execution exposure

👉 Apiiro's full article covers the detailed risk categories, execution paths, and security implications behind autonomous code generation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps security and identity practitioners build a common control model for autonomous systems and privileged runtime access.