Notifications
Clear all
Topic starter
18/08/2026 2:56 pm
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.
NHIMG editorial — based on content published by Apiiro: Agentic AI code execution risk and runtime workflow exposure
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory agent execution paths Map every place an AI agent can generate code, call a tool, or invoke an interpreter.
- 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.
- Separate retrieved context from execution authority Validate documents, logs, tickets, API outputs, and memory before they can influence tool selection or code generation.
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
👉 Read Apiiro's analysis of agentic AI code execution risk in runtime workflows →
Agentic AI code execution risk: are runtime controls keeping up?
Explore further
18/08/2026 3:39 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Agentic AI code execution risk is moving into runtime workflows
