Notifications
Clear all
Topic starter
01/08/2026 9:00 pm
TL;DR: AI agents now execute multi-step actions, attach tools at runtime, and carry memory across sessions, which makes prompt injection, tool abuse, and indirect exfiltration live identity risks rather than pre-deployment defects, according to Akto. Runtime security is becoming the control plane that decides whether an agent is allowed to act, not just whether it can reason.
NHIMG editorial — based on content published by Akto: LLM runtime security for AI agents and enterprise guardrails
Questions worth separating out
Q: How should security teams govern AI agents that choose tools at runtime?
A: Security teams should treat runtime tool choice as a governed access event, not a normal application call.
Q: Why do AI agents complicate traditional access reviews?
A: AI agents complicate access reviews because they can accumulate permissions across tools and environments faster than manual certification cycles can observe.
Q: What breaks when prompt injection reaches an AI agent's memory?
A: The attack stops being transient.
Practitioner guidance
- Separate instruction and data channels Treat prompts, retrieved documents, tool output, and memory as different trust classes.
- Require per-call authorization for every tool action Check each agent tool call at runtime against current task scope, permissions, and data sensitivity.
- Limit dynamic tool discovery Restrict which MCP servers or registries can be added to an agent session, and validate tool descriptions before they are accepted into context.
What's in the full article
Akto's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step runtime control architecture for prompts, memory, tools, monitoring, and outputs
- Detailed explanation of MCP-specific discovery and authorization risks in production
- Examples of runtime policy enforcement, session risk scoring, and human approval workflows
- The article's full FAQ covering prompt injection, tool validation, and agent observability
👉 Read Akto's guide to LLM runtime security for AI agents →
LLM runtime security for AI agents: are your controls keeping up?
Explore further
01/08/2026 9:06 pm
LLM runtime security is an identity control problem, not just an application-layer safety problem. The article's core point is that the agent's danger emerges after deployment, when identity, memory, tools, and outputs are all active at once. That shifts the governance question from model quality to runtime authority. Practitioners should treat agent identity as a live security boundary, not a static setup step.
A few things that frame the scale:
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent takes action through an MCP server?
A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.
👉 Read our full editorial: LLM runtime security for AI agents is now an identity problem
