Notifications
Clear all
Topic starter
02/08/2026 11:26 am
TL;DR: AI agents are expanding enterprise attack surfaces through prompt injection, memory poisoning, privilege escalation, and MCP-connected tooling, according to Akto. Static app security controls do not map cleanly to systems that choose tools, recall context, and act at runtime without human approval.
NHIMG editorial — based on content published by Akto: AI Agent Security Risks in 2026: Runtime Protection and Security Best Practices
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern runtime agent choice as an access event, not as a simple application action.
Q: Why do AI agents complicate zero trust architecture assumptions?
A: AI agents complicate zero trust because they make repeated, autonomous access requests after the initial authentication step.
Q: What do security teams get wrong about prompt engineering for AI agents?
A: They often assume better wording is enough to create reliable control.
Practitioner guidance
- Constrain agent tool sets by task Define task-scoped tool allowlists so an agent can only reach the APIs, databases, and external services required for that specific workflow.
- Inspect prompt and memory ingestion paths Review every channel that can influence agent behaviour, including web content, emails, documents, vector stores, and long-term memory.
- Add runtime policy enforcement Apply policy checks at the moment of tool invocation so unauthorised actions can be blocked before execution, not after the session ends.
What's in the full article
Akto's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of direct and indirect prompt injection patterns across agent workflows
- Runtime protection and policy enforcement approaches for blocking out-of-scope tool use
- Testing methods for multi-turn exploit chains, fuzzing, and adversarial red teaming
- Practical handling of MCP connectors, external integrations, and memory-layer exposure
👉 Read Akto's analysis of AI agent security risks in 2026 →
AI agent runtime security risks in 2026: are your controls keeping up?
Explore further
02/08/2026 12:43 pm
Runtime security is now an identity problem, not just an application problem. AI agents do not merely consume access, they decide how to use it inside the session. That shifts the control boundary from login and entitlement issuance to action-time verification, where prompt injection, tool misuse, and context poisoning actually occur. Practitioners should read this as a governance reset for agent identities, not as an incremental hardening task.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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, according to SailPoint.
A question worth separating out:
Q: How can organisations reduce AI agent runtime risk without stopping adoption?
A: By combining continuous red teaming, runtime monitoring, and strict connector governance. The goal is not to eliminate agent use but to ensure the agent cannot freely combine tools, memory, and external data into actions that were never authorised. Runtime control is the practical alternative to blanket restriction.
👉 Read our full editorial: AI agent security risks in 2026 expose runtime control gaps
