TL;DR: Agentic AI is shifting code execution from reviewed pipelines into runtime workflows, where agents generate logic, select tools, and act with broad permissions, according to Apiiro. That makes execution risk less about developer-written code alone and more about autonomy, context, and control of live execution paths.
At a glance
What this is: Agentic AI is shifting code execution into runtime workflows, where agents generate logic and act dynamically inside trusted systems.
Why it matters: That matters because traditional AppSec assumes code is reviewed before execution, while agentic systems can create and run behaviour after deployment with broad permissions and limited visibility.
By the numbers:
- 33% of enterprise software applications will use agentic AI by 2028, according to Gartner cited by Apiiro.
- roughly 15% of day-to-day work decisions made autonomously, according to Gartner cited by Apiiro.
Context
Agentic AI changes code execution from a release-time event into a runtime behaviour. Instead of code moving through a predictable chain of development, review, and deployment, agents can generate logic, invoke tools, and execute actions inside production workflows.
The governance problem is that existing application security models assume stable code paths, clear ownership, and reviewable artefacts. Once execution decisions are made dynamically from context, logs and static scans capture only part of the risk, and identity controls matter because agents often act with service-level permissions.
Key questions
Q: What breaks when agentic AI can generate and run code at runtime?
A: The main failure is the loss of a clean separation between development review and execution. When agents can create code during live workflows, static approval no longer fully describes risk. Security teams must govern runtime authority, tool access, and the context sources that can trigger execution, because the dangerous behaviour may never exist as a reviewed commit.
Q: Why do broad agent permissions increase security risk?
A: Broad permissions increase risk because one compromise or misconfiguration can expose many systems at once. The same agent may read email, modify code, touch cloud resources and move data, so the blast radius is much larger than the original task requires.
Q: What do security teams get wrong about agentic code scanning?
A: The common mistake is treating the model as the control, when the harness is what actually drives precision, scope and budget. Without a structured harness, an agent can spend time in irrelevant files, miss the vulnerable path and overstate confidence. Teams should govern the orchestration layer as carefully as the model choice itself.
Q: How should organisations govern agentic AI when it makes judgment calls, not just automated actions?
A: Organisations should govern the decisions agentic AI is permitted to make, not only the data it can access. That means defining escalation thresholds, preserving human decision rights for ambiguous cases, and logging the signals that explain why the agent chose a path. If the decision itself is unreviewable, policy drift can occur without a visible breach.
Technical breakdown
Why runtime code execution changes the attack surface
Agentic systems do not wait for a commit, build, or deployment gate before behaviour changes. They can plan a task, generate code, invoke tools, and complete execution in one continuous loop. That collapses the normal separation between design, release, and production, which is why execution risk shifts from a static artifact problem to a live control problem. The security question becomes whether the runtime environment can constrain what an agent is allowed to generate and run, not just whether the original codebase was reviewed.
Practical implication: Treat runtime execution as a governed control plane, not as a downstream outcome of secure development.
How context becomes executable behaviour
In agentic AI, inputs are not limited to prompts. Documents, logs, API responses, memory entries, and retrieved tool output can all influence planning and action selection. That means untrusted or misleading content can shape code generation even when no obvious exploit exists in the source code. The boundary between data and instructions becomes unstable, which is why code execution risk now includes indirect prompt injection, context poisoning, and tool misuse. Traditional AppSec tools rarely model this path because the problem emerges only when context is interpreted at runtime.
Practical implication: Map which inputs can influence agent decisions and restrict what context can reach execution-capable tools.
Why broad permissions amplify agentic AI risk
Agentic systems often use service-level credentials so they can complete tasks across systems without constant human intervention. Those permissions are functionally useful but dangerous when execution is dynamic, because any harmful action appears authorised if the agent had valid access. This is where identity and privilege governance intersect directly with code execution risk: the issue is not only what the agent can do, but what it can do at the moment it decides to act. Without narrow execution scopes and strong runtime boundaries, one compromised decision path can have a large blast radius.
Practical implication: Apply least-privilege access and task-scoped execution boundaries to every agent that can run code or call tools.
Threat narrative
Attacker objective: The attacker wants to steer an agent into running unintended code or automation through legitimate execution paths.
- Entry occurs when untrusted context, such as retrieved documents, logs, or API output, influences an agent's planning process.
- Credential and tool access then let the agent convert that context into generated code or automated execution using legitimate permissions.
- Escalation happens when broad service-level access turns a single bad decision path into actions across connected systems and runtime workflows.
- Impact is code execution inside trusted environments, with misuse blending into normal automation and becoming harder to distinguish from authorised activity.
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.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
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 execution is now an identity problem as much as an application problem: once agents can generate and run code inside production workflows, the decisive control becomes who or what is allowed to execute at that moment. Static review still matters, but it no longer defines the full attack surface. Practitioners need to govern execution authority, not just code provenance.
Context is becoming the new instruction layer: agentic systems routinely convert documents, logs, retrieved memory, and API output into action. That creates a control gap that traditional AppSec rarely models because the risky behaviour emerges after ingestion, not at write time. Security teams should treat untrusted context as a potential execution trigger, especially when the agent can invoke tools or interpreters.
Broad service permissions create a runtime blast-radius problem: the more an agent can do with valid credentials, the easier it is for a poisoned decision path to look legitimate. This is where NHI governance and agentic AI security converge, because the credential is not just an access token, it is execution authority. Least privilege must be rethought around tasks, not just accounts.
Continuous visibility matters more than static approval: agentic code execution changes over time as models, memory, tools, and workflows evolve. A system can look safe at design review and still become unsafe through runtime drift, especially when dependencies or tools are selected dynamically. The practitioner conclusion is to monitor execution paths as first-class assets, not as side effects of the pipeline.
Named concept: execution-aware governance: this article describes a control model that tracks when, why, and with what authority code is generated and run. That concept is more useful than treating agentic AI as a prompt-safety issue because the real risk lives in live execution paths. Security programmes should align controls to execution authority, context sources, and runtime isolation.
From our research library:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Security Guide
What this signals
Execution-aware governance: agentic AI turns runtime behaviour into a security boundary, so teams need to track when execution authority changes rather than assuming static review is enough. That makes code generation, tool invocation, and service credentials part of the same control conversation.
The practical signal for programmes is that autonomy and privilege have to be evaluated together. If an agent can translate context into action with broad permissions, the control failure is not only malicious code but uncontrolled execution authority.
For readers building identity and AI governance, the immediate watchpoint is whether their current access model can distinguish recommendation from execution. If it cannot, runtime workflows will outpace the approvals designed for pre-production software.
For practitioners
- Define execution boundaries for every agent Separate agents that can only recommend actions from those that can invoke interpreters, shells, or cloud APIs. Limit each execution path to the smallest task scope possible and record the approvals that grant that scope.
- Restrict context sources before execution Block untrusted documents, logs, and retrieved memory from reaching code-generation or tool-invocation steps unless they are explicitly validated. Treat indirect prompt injection as an input-governance issue, not only a model-safety issue.
- Review service-level permissions for agent workflows Inventory every agent that runs with service-level credentials and map the exact systems it can touch during a task. Remove standing access that is not required for the runtime action the agent actually performs.
- Monitor runtime changes to tools and dependencies Track when agents add interpreters, packages, or external tools into a workflow so execution capability does not expand silently. Correlate those changes with code generation and runtime events to detect new blast-radius conditions.
Key takeaways
- Agentic AI shifts code execution from reviewed pipelines into live workflows, where context and tool choice become security controls.
- The risk is amplified when agents act with service-level permissions, because legitimate credentials can mask harmful execution paths.
- Controls need to move toward execution-aware governance, with context validation, task-scoped access, and runtime monitoring.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article centres on agents selecting tools and executing code at runtime. |
| ASI03 — Identity & Privilege Abuse | Broad service-level permissions are the core amplifier in this runtime risk. | |
| Recommendation — Limit agent tool permissions and validate every tool invocation path before execution. Bind agent actions to task-scoped identity and reduce privilege to the minimum runtime need. | ||
| CSA MAESTRO | Agentic AI threat modeling | This is a threat-modeling problem involving autonomy, tools, and runtime execution paths. |
| Recommendation — Model agent execution paths, context sources, and isolation boundaries before production rollout. | ||
| NIST AI RMF | MAP — Map AI risks and impacts | The article calls for mapping execution authority and runtime exposure across the AI system. |
| Recommendation — Map how context, tools, and credentials combine to create code execution risk. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Abused credentials and tool access can spread execution impact across connected systems. |
| Recommendation — Map agent misuse to TA0006 and TA0008 to prioritise detection around credentialed execution paths. | ||
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.
- Usage-aware governance: A governance model that uses actual activity as part of access decisions. Instead of certifying access only by role or schedule, it checks whether the entitlement is still being used, still justified, and still appropriate for the current context.
- Service-level permissions: Service-level permissions are credentials and access rights granted to automated systems so they can act without direct user involvement. They are operationally useful, but in agentic environments they can turn an isolated execution path into a broad blast-radius event if the agent is misled or compromised.
- Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It is designed for practitioners who need to connect identity controls to modern runtime risk.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org