Why generative AI and agentic AI create different security risks

At a glance

What this is: This article distinguishes generative AI from agentic AI and argues that the security risk changes when systems can plan, use tools, and act autonomously across sessions.

Why it matters: Security and identity teams need to treat agentic systems as governed actors, because tool use, memory, and persistent state create access and audit challenges that classic chatbot controls do not cover.

Context

Generative AI and agentic AI are not the same control problem. Generative systems answer prompts and stop, while agentic systems can retain context, invoke tools, and continue acting until a goal is reached, which creates a materially different governance surface for identity, access, and audit.

The security gap is that many programme controls were built for reactive systems, not for software that can decide what to do next. Once an AI system can move from suggestion to execution, practitioners have to govern permissions, state, and accountability as part of the system design rather than as an afterthought.

Key questions

Q: How should security teams govern AI agents that read untrusted text and can act on it?

A: Treat the agent as a privileged runtime with untrusted input, not as a chat interface. Limit tool access, shorten session scope, and remove at least one high-risk property such as external write access or access to sensitive systems. Then add monitoring or enforcement at the action boundary so the control evaluates what the agent actually does, not just what it reads.

Q: Why do generative and agentic AI create problems for traditional model risk management?

A: Traditional model risk management assumes stable inputs, stable outputs, and a bounded decision path that can be validated before deployment. Generative and agentic systems can retrieve data, combine tools, and initiate actions during runtime, which means their behaviour may change in production. That makes explanation useful, but not sufficient for governance.

Q: What breaks when an AI system has memory and tool access but no clear governance?

A: The organisation loses the ability to prove what the system was allowed to do, why it did it, and whether the action stayed inside policy. Persistent memory plus tool access turns a simple chatbot into a workflow actor, so weak governance becomes a control failure rather than a minor design flaw.

Q: What is the difference between generative AI and agentic AI for access control?

A: Generative AI mainly needs controls around input, output, and data handling, while agentic AI needs controls around delegated authority, credential scope, and runtime authorisation. The second model behaves like an operational actor, so access control must be designed around actions and outcomes, not just prompts.

Technical breakdown

Why generative AI stays a bounded inference problem

Generative AI is typically a single-step inference system: it receives an input, predicts an output, and ends the interaction. Even when outputs are fluent and useful, the model does not natively maintain goals, persist state across sessions, or independently invoke external systems. That means the human remains the operational actor, deciding what happens next. Security risk still exists, but it is mostly concentrated in prompt injection, output misuse, and data leakage through the model interface rather than in autonomous execution paths.

Practical implication: Treat genAI primarily as an interaction and data-governance problem, not as an autonomous actor that needs standing operational authority.

How agentic AI turns tools, memory, and orchestration into risk

Agentic AI adds a closed loop of perception, reasoning, action, and feedback. Memory modules preserve context, orchestration layers break goals into tasks, and tool-use protocols let the system act through APIs, databases, browsers, or other services. That combination turns the model from a content generator into a workflow executor. The security boundary therefore shifts from what the model says to what it is allowed to do, when it can do it, and how those actions are recorded and verified.

Practical implication: Govern tool permissions, state persistence, and action logging as core controls for agentic systems, not optional add-ons.

Why MCP and A2A increase the identity challenge

The article’s discussion of unified access protocols and agent-to-agent collaboration shows why identity becomes central. Once multiple agents can exchange context, call tools, and coordinate work without human intervention, each agent needs a trustworthy identity, scoped authority, and clear delegation rules. Otherwise, organisations lose visibility into who or what initiated a sensitive action and whether the action stayed within policy. This is where agentic AI starts to overlap directly with IAM and NHI governance, because the system behaves like a digital actor with credentials and delegated access.

Practical implication: Model every agent, tool, and delegation path as an identity relationship that needs scope, lifecycle, and audit controls.

NHI Mgmt Group analysis

Agentic AI is the first AI pattern that makes governance, not prompting, the primary control plane. Once a system can decide, call tools, and continue across time, the security question changes from whether the output is safe to whether the action path is authorised. That shifts attention toward policy enforcement, delegated access, and traceability. The practical conclusion is that security teams should govern the action envelope, not just the model output.

Persistent memory creates an identity problem as much as an AI problem. A system that remembers context across sessions is no longer just producing a response in the moment. It is maintaining state that can influence future decisions, which raises questions about ownership, revocation, and boundary control. The practical conclusion is that memory must be treated as governed state with clear retention and reset rules.

Agent-to-agent collaboration introduces distributed privilege by design. When several autonomous components coordinate through shared protocols, the organisation is effectively creating a multi-actor workflow with machine identities in the middle. That expands the need for least privilege, delegation boundaries, and assurance over inter-agent trust. The practical conclusion is that multi-agent design should be reviewed as an access architecture, not only an AI architecture.

Identity management must adapt because agentic systems behave like actors, not features. The article’s tool-use and orchestration model aligns with the wider shift in AI security toward verifiable identity, scoped credentials, and auditable action chains. This is exactly where NHI governance becomes relevant: agents that act on behalf of users or processes need lifecycle control, not informal trust. The practical conclusion is to bring IAM and NHI design into AI programme governance early.

Autonomous action creates governance debt if teams keep using chatbot-era controls. Prompt filters and content moderation do little once a system can call APIs, update records, and chain tasks. The article points to the deeper issue: control failure happens at execution time, not at response time. The practical conclusion is to align security review with runtime authorisation, not conversational safety alone.

From our research library:

• Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.
• Read next: Agentic AI Identity Maturity Model

What this signals

Action governance is becoming the relevant security boundary for AI programmes. When systems can plan, call tools, and persist across sessions, teams need to govern permitted actions instead of assuming prompt controls are enough. That means security reviews should move closer to runtime authorisation, delegated access, and event logging.

Agentic AI collapses the line between AI governance and identity governance. Once a system can act on behalf of a user or process, it starts to resemble a machine identity with a lifecycle, scope, and revocation requirement. Programmes that keep AI controls separate from IAM and NHI design will struggle to explain or contain autonomous behaviour.

Model Context Protocol and multi-agent workflows deserve access scrutiny, not just architecture review. Shared context and coordinated execution can create hidden delegation paths that are hard to audit after the fact. The practical response is to treat every handoff and external tool call as a governed trust decision, not a simple integration detail.

For practitioners

• Define the system’s action boundary List every action an agent can take, then separate read-only suggestions from write, delete, and transact capabilities. Use that inventory to decide which actions require approval, step-up verification, or hard denial before deployment.
• Scope delegated access to the minimum viable task Issue credentials and API permissions only for the specific workflow the agent must complete, and expire them when the task ends. Avoid broad service accounts that let the same agent keep operating outside its intended goal.
• Log decisions, tool calls, and state changes Capture which prompt, memory state, tool invocation, and downstream system action led to each outcome. Preserve enough evidence to reconstruct the sequence later, especially where an agent updates records or triggers third-party systems.
• Separate memory from authority Keep long-term context and user preferences distinct from privileged operational permissions. A stored goal should not automatically imply permission to execute it across systems or sessions.
• Review multi-agent workflows as delegation chains Map how one agent hands off to another, what each agent can see, and which shared protocols carry context or credentials. Treat that path as an access architecture that can fail at any handoff point.

Key takeaways

• Generative AI and agentic AI create different security problems because one produces content while the other can execute actions through tools, memory, and orchestration.
• The main risk shift is from prompt safety to governed authority, because autonomous systems can persist state, call APIs, and trigger downstream business actions.
• Security teams should manage agentic systems as access-bearing actors with scoped credentials, runtime controls, and full auditability.

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.
• Generative AI: AI designed to create text, code, images, or other content in response to a prompt. It is usually reactive rather than autonomous, which means the main security concern is output quality, leakage, and misuse of generated content rather than independent action.
• Tool Use Module: A tool use module is the part of an agentic system that connects the agent to external systems such as APIs, search engines, code execution, or browser automation. It is where identity risk becomes operational because the agent can cross trust boundaries and trigger side effects beyond the prompt itself.
• Closed-Loop Control: Closed-loop control is a governance pattern where a finding leads to a decision, the decision leads to action, and the action is verified. In identity programmes, it means access review, remediation and reporting are connected so exceptions do not remain open or undocumented.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and agentic AI identity for practitioners responsible for access, lifecycle, and control design. It helps security and identity teams translate autonomous system risk into governable practice.