By NHI Mgmt Group Editorial TeamBased on Cycode: “What Is Agentic AI Security?” (June 8, 2026)

TL;DR: Agentic AI security now spans identity, memory, tool access, and runtime enforcement, because agents can plan, call APIs, write data, and persist instructions across workflows without constant oversight, according to Cycode. The governance problem is that access review models assume stable, reviewable behaviour, but autonomous action can create privilege use and leakage before any human sees it.


At a glance

What this is: This is a Cycode analysis of agentic AI security, arguing that autonomous agents create identity, memory, tool, and runtime risks that traditional output-focused AI controls do not fully cover.

Why it matters: It matters because IAM, PAM, and NHI programmes must now govern agent identities, tool scope, and memory persistence before autonomous actions outpace human review.

By the numbers:

  • 88% of organizations experienced confirmed or suspected AI agent security incidents in the last year.
  • Only 22% of teams treat agents as independent identities, breaking audit trails and accountability.

Context

Agentic AI security is the discipline of governing autonomous AI agents as identities that can reason, call tools, read and write data, and persist instructions across workflows. That changes the control problem from filtering outputs to governing runtime behaviour, identity, tool scope, memory, and observability.

The governance gap is that many current controls still assume deterministic software, human-paced review, or service accounts with stable boundaries. When an agent can act at machine speed across multiple systems, the meaningful control point shifts to issuance, authorization, and runtime enforcement rather than post-hoc review.

Cycode’s article frames this as a production security problem, not a theoretical model risk issue. That framing is typical for enterprises now trying to move agents beyond pilots while security teams are still adapting identity and policy models.


Key questions

Q: How should security teams govern autonomous agents that use backend tools?

A: Treat autonomous agents as identities with their own scopes, policies, and revocation paths. The important control is not whether the workflow runs, but whether the agent can only call approved tools, obtain the minimum downstream access needed, and leave a reliable audit trail for each action it takes.

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. A review process built for stable human accounts does not fit an executor that can act across systems, create new access paths, and complete work before the next review window begins.

Q: What breaks when agent memory is shared across users or workflows?

A: Shared memory turns prior interactions into a hidden input to later decisions, which means one poisoned or sensitive context can influence other sessions. This breaks isolation assumptions and makes later actions hard to attribute. The result is a stateful attack surface that can survive long after the original prompt is gone.

Q: What is the difference between prompt-level guardrails and runtime guardrails for AI agents?

A: Prompt-level guardrails inspect what the user asks or what the model says. Runtime guardrails inspect the whole interaction while it is happening, including tool requests, tool responses, and downstream actions. That matters because many agentic attacks are chained and only become visible when the full execution path is evaluated as one session.


Technical breakdown

Why agent identities need their own governance boundary

Agentic systems are not just automated scripts. They make decisions, invoke APIs, and can be given credentials broad enough to change records, send messages, or deploy code. Once an agent is treated as a generic extension of a human or service account, audit trails blur and authorization becomes ambiguous. The key technical issue is attribution: logs may show valid access, but not whether the agent’s action matched the intended scope. That is why identity, privilege, and lifecycle controls have to be defined for the agent itself, not borrowed from adjacent systems.

Practical implication: define distinct identities, scoping rules, and offboarding paths for each agent rather than inheriting human or workload credentials.

How memory and context persistence become a control plane

Persistent memory changes agentic AI from a request-response pattern into a stateful system. Instructions, sensitive context, and poisoned data can survive across sessions, users, and workflows, then influence later decisions in ways that are hard to trace. Context windows, vector stores, and conversation history all become part of the attack surface because the agent can reuse them when planning future actions. That is a different risk model from ordinary application state, where data is usually deterministic and easier to isolate. In agentic systems, memory is not only storage. It is an execution input that can steer behaviour long after the original prompt is gone.

Practical implication: isolate memory by user, session, and workflow, and treat retained context as governed execution input.

Why tool access and runtime enforcement matter more than model output filtering

The article draws a sharp line between output safety and operational safety. Blocking hostile text does not stop an agent from making a privileged tool call, updating a database, or invoking downstream workflows if those actions are already available. The technical failure mode is overexposure to tools and APIs combined with weak runtime policy enforcement. In other words, the model may never produce a visibly unsafe answer, yet still trigger an unsafe action. Effective control therefore depends on the execution layer, where tool inventory, permission scope, approval gates, and observability determine what the agent can actually do.

Practical implication: enforce tool allowlists and runtime gates on the action layer, not only on model prompts or outputs.


Threat narrative

Attacker objective: The attacker wants the agent to perform trusted actions on their behalf so the resulting misuse looks like ordinary machine activity while causing data loss, unauthorised changes, or unsafe execution.

  1. Entry occurs when a manipulated prompt or poisoned input reaches an agent that already has access to tools, APIs, or shared context.
  2. Credential or permission abuse follows when the agent uses its valid access to call privileged tools, update records, or read sensitive data as part of a normal workflow.
  3. Escalation happens when persistent memory, shared channels, or chained agent interactions spread the attacker’s instruction across sessions and systems.
  4. Impact is the exfiltration, modification, or unsafe execution of downstream processes before a human review loop can intervene.

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

Agentic AI security is now an identity governance problem, not just an AI safety problem. The article shows that agents can plan, call tools, and persist memory across workflows, which means the security question is who or what is authorised to act. That pushes governance into identity, privilege, and lifecycle territory that traditional model-centric controls do not address. Practitioners should treat agent behaviour as an access-control issue first.

Identity does not select and combine tools dynamically mid-session; that assumption breaks under autonomous behaviour. The control model behind many IAM and review processes assumes a stable subject, a known purpose, and a reviewable sequence of actions. When an agent decides which tool to call, when to call it, and how to chain actions at runtime, the access decision is no longer fixed at provisioning. The implication is that review cycles cannot be the primary control boundary for autonomous systems.

Persistent memory creates a new kind of governance debt. The article makes clear that memory, context windows, and vector stores can carry forward instructions and sensitive content long after the original interaction ends. That means the organisation is not only managing credentials and tools, but also managing retained behavioural state. Practitioners should treat memory persistence as a first-class control surface in agent governance.

Tool sprawl is the point where agentic risk becomes operational. Each new MCP server, API, or integration expands the number of places where an agent can be manipulated into action. The article’s core warning is that over-privileged, poorly isolated tooling lets normal-looking agent activity become data exfiltration or unwanted execution. Security teams should interpret tool inventory as part of identity perimeter design, not as a sidecar inventory exercise.

Runtime enforcement is the decisive control layer for agentic systems. Policies that exist only on paper do not stop an agent from making a privileged call in production. The field needs controls that can inspect the action as it happens, correlate the agent’s context, and stop unsafe execution before downstream impact. That is the practical line between explainable risk and governable risk.

From our research library:

What this signals

Identity for agents has moved from theory to operating model. Organisations cannot keep treating autonomous systems as borrowed extensions of human or workload accounts, because the control point is now the agent’s own runtime authority. The practical shift is toward issuance-time governance, scoped tool access, and explicit offboarding for machine actors.

Persistent memory is becoming the hidden state that security teams must govern. When instructions and sensitive context survive across sessions, the organisation is no longer securing a single prompt, it is securing a durable behavioural layer. That is why memory isolation and deletion policy now belong in the same conversation as privilege management.

Agentic AI Identity Maturity Model: maturity will increasingly be measured by whether teams can prove who the agent is, what it can touch, and what state it can carry forward. As adoption rises, the weak point will be systems that can act faster than review cycles can certify, especially where tool breadth and shared context are both high.


For practitioners

  • Define agent-specific identities Issue distinct credentials per agent and stop treating agents as extensions of human users or generic service accounts. Make the identity, scope, and accountability model explicit before production rollout.
  • Constrain tool execution paths Inventory every approved tool, API, and MCP server an agent can invoke, then remove anything that is not required for the task. Add approval gates for high-impact actions such as deletion, external transmission, or code execution.
  • Isolate memory and context stores Separate memory by user, session, and workflow so one interaction cannot seed another. Apply retention limits and purge paths to prompts, context windows, and vector stores that hold sensitive instructions or data.
  • Move enforcement into runtime Use policy controls that act at execution time, not just at prompt review or code review. Correlate agent activity across identity, tooling, and workflow layers so unsafe behaviour is blocked where it occurs.
  • Redesign access review for short-lived behaviour Review whether your governance process assumes access persists long enough to be recertified. For autonomous agents, build controls around issuance, scope, and runtime approval rather than expecting periodic reviews to catch misuse.

Key takeaways

  • Agentic AI security is fundamentally about governing autonomous action, not just filtering model output.
  • The article shows that identity scope, memory persistence, and tool access create the main control gaps for agents.
  • The decisive control boundary is runtime enforcement, because policy written outside execution does not stop machine-speed misuse.

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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article centres on agents misusing broad identity and tool permissions at runtime.
ASI02 — Tool MisuseTool access and API invocation are central attack paths in the article.
ASI06 — Memory & Context PoisoningPersistent memory and context carry the attack forward across sessions.
Recommendation — Map agent identities to ASI03 and restrict privileges to the minimum runtime scope. Inventory and constrain agent tools so only approved actions can execute in production. Isolate and purge agent memory stores to reduce poisoned-context persistence.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationAgents need distinct identities rather than borrowed human or shared service credentials.
NHI-05 — Overprivileged NHIThe article repeatedly warns that agents inherit access broader than their task requires.
Recommendation — Issue separate agent credentials and remove shared authentication paths. Trim agent permissions to task-scoped access and remove broad standing rights.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsRuntime access scope and entitlement control are the article's core governance concerns.
Recommendation — Apply PR.AA-05 to validate entitlements before agents can invoke sensitive actions.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe attack patterns include credential use, tool abuse, and movement across connected systems.
Recommendation — Track agent abuse cases against credential access and lateral movement techniques in detections.

Key terms

  • Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority, API access, file writes, workflow triggers, the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
  • Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
  • Memory Poisoning (ASI06): An attack where malicious content is injected into an AI agent's memory or context, causing it to alter its behaviour in subsequent tasks, potentially exfiltrating secrets, escalating privileges, or acting against its intended purpose.
  • Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org