Generative AI and agentic AI often run on the same model, yet one produces content for a person to use and the other takes actions in your systems, and most governance programmes still approve them as if they were the same thing. The difference is not the model but what surrounds it: tools, credentials, memory and a loop that lets the system decide its next step without asking. That shift changes who is accountable, which frameworks apply, how you budget and test, and what an identity team has to issue. This guide sets out the definitions used by government and standards bodies, the architectural and operating differences, how the main frameworks and the EU AI Act treat each, and the governance artefacts each tier needs. It is for AI platform owners, architects, risk and governance leads and identity teams deciding what to build or approve. The step-by-step spectrum from chatbot to multi-agent system is covered in AI Agents vs Agentic AI, and the security programme changes in Agentic AI Security vs LLM App Security; this page does not repeat them.
Key takeaways
- Generative AI produces; agentic AI acts. The joint Five Eyes guidance describes generative AI as creating content for people to use, and agentic AI as building on it by connecting to software systems so it can reason, plan and act.
- Agency is a property of the system, not the model. The same foundation model can sit behind a drafting tool and an agent that changes production; classify the deployment, not the model.
- The frameworks diverge. NIST AI 600-1 was written for generative AI and focuses on content risks; OWASP's agentic Top 10 (December 2025) and the Five Eyes agentic guidance (April 2026) focus on privilege, autonomy and accountability.
- Identity becomes a deliverable. A generative app needs an API key and user session controls; an agent needs its own identity, an owner, scoped short-lived credentials and a record of whose authority each action carries.
- Govern by tier. Generate, recommend, act with approval and act autonomously need different artefacts: register entry, risk assessment, identity, approval design, logging and kill switch.
The short answer and the definitions
If a system's output is read by a person who then decides what to do, it is generative AI, however capable. If the system can call tools that change data, send messages, spend money or alter configuration, and can choose which tool to call next based on what it observes, it is agentic. Many enterprise deployments sit between the two: an assistant that drafts an action and asks a person to confirm it.
| Source | Generative AI | Agentic AI |
|---|---|---|
| NIST AI 600-1 (July 2024) | Uses the US Executive Order 14110 definition: models that emulate the structure and characteristics of input data to generate synthetic content such as text, images, audio and video; in the profile, generally generative foundation models | The profile does not use "agentic"; "autonomous agents" appears once, in a list of security threats to assess (MS-2.7-001) |
| Five Eyes "Careful adoption of agentic AI services" (announced 30 April 2026) | Creates content such as text, images or audio for people to use | One or more agents relying on an LLM to interpret situations, make decisions and take actions, often without continuous human input; an LLM core plus tools, data sources, memory and planning |
| OWASP Top 10 for LLM Applications 2025, LLM06 | An LLM-based system without delegated function calls | Agency is the ability to call functions or interface with other systems via extensions, with the choice of extension possibly delegated to the LLM; agents make repeated LLM calls grounded on earlier outputs |
| OpenAI, "Practices for Governing Agentic AI Systems" | Not defined separately | "Agenticness" is a matter of degree across goal complexity, environmental complexity, adaptability and independent execution |
| EU AI Act, Article 3 | General-purpose AI models and systems are defined by generality, not by output type | No separate agent category; an AI system is machine-based and designed to operate with varying levels of autonomy |
Two consequences follow. First, "agentic" is a spectrum, so a binary label hides most of the risk; the AI Agent Autonomy Levels Framework gives a working scale. Second, the EU AI Act regulates by use and role (provider, deployer, high-risk purpose), so an agent is regulated through the purpose it serves and the general-purpose model inside it, not through a dedicated agent regime. See EU AI Act for AI Agents.
Side-by-side comparison
| Dimension | Generative AI deployment | Agentic AI deployment |
|---|---|---|
| Unit of work | One request, one response | A goal pursued over many steps, often many model calls |
| Who acts on the output | A person, or fixed code that the developer wrote | The system itself, through tool calls it selects |
| Interfaces | Chat UI, API, retrieval store | All of those plus tools (APIs, MCP servers, browsers, shells), other agents and schedulers |
| State | Mostly per conversation | Persistent memory, task queues and long-running sessions |
| Credentials | Model provider API key; the user's own session | Agent identity, delegated user tokens, tool credentials, sometimes credentials for other agents |
| Worst realistic outcome | Wrong, harmful or leaked content that a person relies on | Whatever the agent's permissions allow, executed at machine speed and possibly repeated |
| Cost profile | Roughly proportional to user requests | Variable and harder to cap: loops, retries and fan-out multiply tokens and tool calls |
| Testing focus | Prompt and response quality, safety filters, data leakage | Whole trajectories: tool choice, parameters, approvals, recovery from errors |
| Accountable owner | Product owner of the application | Product owner plus the owner of each system the agent can change |
| Key ATLAS techniques | AML.T0051 LLM Prompt Injection | AML.T0053 AI Agent Tool Invocation, AML.T0101 Data Destruction via AI Agent Tool Invocation |
Architecture in words
Generative AI
A user or application sends a prompt. The application adds a system prompt and, often, documents retrieved from a vector store or search index. The model returns text, an image or structured output. The application shows it to a person or passes it to a parser that the developer controls. The trust boundaries are user input, retrieved content and the output handler. Any action in the world happens because a person, or deterministic code, chose to take it.
Agentic AI
The system receives a goal, asks the model for a plan or next step, selects a tool, calls it with credentials, reads the result back into context and repeats until the goal is met or a limit is reached. Results and memory feed later decisions, and work may be handed to other agents. In the Model Context Protocol, tools are described as model-controlled: the model discovers and invokes them based on context. The MCP specification (version 2025-11-25) says there SHOULD always be a human in the loop able to deny tool invocations, that clients MUST treat tool annotations as untrusted unless they come from trusted servers, and that servers MUST validate inputs, enforce access controls and rate limit tool calls. Every tool call is therefore an authorisation decision, and every tool result is new untrusted input. See the MCP Security Guide.
How the risk model shifts
Generative risk is mostly about content. NIST AI 600-1 lists twelve risks, among them confabulation, data privacy, information integrity, information security, intellectual property, harmful bias and homogenisation, human-AI configuration, and value chain and component integration. Its four primary considerations are governance, content provenance, pre-deployment testing and incident disclosure. The Air Canada Chatbot Ruling shows the generative failure mode in practice: no system was breached, but a wrong answer about a fare policy left the airline liable after a tribunal rejected the argument that the chatbot was responsible for its own statements.
Agentic risk keeps those content risks and adds consequences. The Five Eyes guidance groups agent risks into inherited LLM risks, an expanded attack surface, privilege risks (over-privilege, scope creep, confused deputy misuse, identity spoofing), design and configuration risks, behavioural risks (goal misalignment, specification gaming, deceptive behaviour), structural risks (tool misuse, rogue agents, resource exhaustion) and accountability risks (opaque decisions, incomplete logs). The UK NCSC argues that LLMs are "inherently confusable", that prompt injection may never be fully mitigated, and that the answer is to limit what the system can do with deterministic safeguards, so that content from an untrusted source never carries privileges. The Replit AI Agent Database Deletion case shows the agentic failure mode: no attacker was involved, the agent simply used write access it already held during a declared code freeze, because the freeze was an instruction in a chat rather than a technical control.
OWASP's LLM06 Excessive Agency names the hinge between the two: damaging actions performed in response to unexpected, ambiguous or manipulated model output, with excessive functionality, permissions and autonomy as its root causes. The OWASP Top 10 for Agentic Applications Guide covers the ten agent risks, from ASI01 Agent Goal Hijack to ASI10 Rogue Agents.
Tools, credentials and identity
A generative deployment usually has one machine credential worth worrying about: the API key to the model provider, plus whatever service account reads the retrieval store. An agentic deployment can have dozens, and the question changes from "who can use this app?" to "whose authority does each action carry?".
| Credential pattern | Typical in | Main risk | Preferred practice |
|---|---|---|---|
| Shared model provider API key | Generative apps and prototypes | Leakage and cost abuse (LLMjacking) | Gateway brokering, per-app keys, spend limits; see the LLMjacking Guide |
| User's own session passed through | Assistants inside productivity suites | Assistant sees and does everything the user can | Respect existing permissions; label data; limit connectors |
| Delegated user token (on-behalf-of) | Assistants that act with approval | Token scope wider than the task; long-lived refresh tokens | Task-scoped, short-lived tokens; per-action consent for high impact |
| Agent's own workload identity | Autonomous and scheduled agents | Over-privilege and orphaned agents after the project ends | Distinct identity, named owner, registry entry, short-lived credentials |
| Borrowed human or shared service account | Early agent pilots | No attribution; actions indistinguishable from a person's | Retire; replace with agent identity or delegated tokens |
The Five Eyes guidance recommends a distinct, cryptographically anchored identity for each agent, a trusted registry, short-lived credentials, and least privilege re-verified on each request. OpenAI's governance paper makes the same point as "attributability": each agent instance should carry an identifier that links it to an accountable human principal. For the access patterns themselves, see the Agent Identity and Access Guide and AI Agent Service Accounts vs On-Behalf-Of Access.
How frameworks and regulation treat each
| Framework | Written for | Use it for | Gap to fill for agents |
|---|---|---|---|
| NIST AI 600-1 Generative AI Profile | Generative AI | Content risks, provenance, pre-deployment testing, incident disclosure | Tool permissions, delegation, autonomy limits and action logging |
| OWASP Top 10 for LLM Applications 2025 | LLM applications, with LLM06 bridging to agents | Prompt injection, output handling, disclosure, unbounded consumption | Multi-step and multi-agent behaviour, memory poisoning |
| OWASP Top 10 for Agentic Applications 2026 | Agentic systems (published 9 December 2025) | Agent-specific risks from ASI01 Agent Goal Hijack to ASI10 Rogue Agents | Pair with the LLM list, which still covers the model layer |
| Five Eyes "Careful adoption of agentic AI services" | Agentic systems | Identity, privilege, human oversight, logging, staged deployment | Detailed testing methods; use alongside OWASP and ATLAS |
| EU AI Act | AI systems and general-purpose AI models by role and use | Article 50 transparency for systems that interact with people or generate synthetic content; high-risk duties by purpose | No agent-specific category; Article 14 human oversight matters where an agent serves a high-risk purpose |
| Model Context Protocol specification | Tool interfaces used by agents | Human ability to deny tool calls, untrusted annotations, server-side validation | Organisational governance, ownership and approvals |
The EU AI Act Article 50 obligations (disclosing AI interaction, machine-readable marking of synthetic content, deepfake disclosure) apply from 2 August 2026 under Article 113, and the Digital Omnibus has amended parts of the Article; check the current consolidated text. They bite on generative output whether or not an agent produced it. See the EU AI Act Article 50 Transparency Obligations Guide and the NIST AI 600-1 guide.
Governance controls per tier
Four tiers are enough for approval decisions. Controls are cumulative. Apply the tier per action class, not per product: one assistant can generate freely, act with approval on tickets and be barred from payments.
| Artefact | T1 Generate | T2 Recommend actions | T3 Act with approval | T4 Act autonomously |
|---|---|---|---|---|
| AI register entry | Use case, model, data sources | Plus which systems it can read | Plus every tool and its blast radius | Plus triggers, schedules and spawned sub-agents |
| Risk assessment | Content risks (NIST AI 600-1) | Plus reliance risk on recommendations | Plus privilege and delegation risks | Plus behavioural and runaway-cost risks; senior risk owner sign-off |
| Identity | User session; app API key via gateway | Read-only service identity | Delegated, task-scoped tokens; approver authenticated with MFA | Own workload identity, short-lived credentials, owner and registry record |
| Human oversight | Person reviews output | Person decides and executes | Approval enforced outside the model for each consequential action | Post-hoc review, anomaly alerts, interrupt and kill switch |
| Logging | Prompts and outputs, subject to privacy rules | Plus data accessed | Plus tool calls, parameters, approver and outcome | Plus full trajectories and identity or privilege changes |
| Testing | Red teaming for content and leakage | Accuracy of recommendations | Trajectory tests in a sandbox, approval bypass tests | Staged rollout, failure injection, rollback rehearsal |
Set the tier by the most consequential action available. Irreversible actions, money movement, privilege changes and sending data outside the organisation should default to T3 unless a named risk owner signs off T4. The Five Eyes guidance adds that decisions about when approval is needed should be made by people, not by the agent. See the Human-in-the-Loop for AI Agents Guide and the Identity Governance for AI Agents Guide for owner, lifecycle and recertification processes.
Decision criteria: when generative is enough
- Does a person already act on the output reliably? If the value is in drafting, summarising or searching, stay generative. Adding actions adds cost and accountability without adding much value.
- Is the action reversible and low impact? Agents fit tasks such as triaging tickets or gathering evidence. Irreversible or high-value actions should stay behind approval.
- Can you scope the credential to the task? If the only available credential is broad (an admin API key, a shared service account), fix that first; an agent with broad access is the risk.
- Can you observe and stop it? Without tool-call logs, an owner, an interrupt and a rollback path, do not move beyond T2.
- Would a deterministic workflow do? If the steps are known in advance, fixed code calling a model at one step is easier to test and audit than an agent choosing steps. See Agent Frameworks vs Workflow Orchestration.
- Small or large organisation? Small teams get most value from generative tools and vendor-hosted assistants with tight connector settings. Large organisations running T3 and T4 need an agent registry, a platform team that issues agent identities, and a central gateway for model and tool access.
Worked scenario: an HR policy assistant gains actions
An HR team runs a generative assistant that answers policy questions from the handbook (T1). Its risks are wrong answers and leaking personal data from retrieved documents; controls are approved sources, retrieval scoped to policy documents and output review for high-stakes topics such as leave entitlements. The business then asks it to book leave and update bank details. Leave booking becomes T3: the assistant prepares the change, the employee confirms it in the HR system's own interface, and the assistant uses a delegated token scoped to that employee's leave record only. Bank detail changes stay out of scope entirely, because a manipulated conversation could redirect salary; the assistant links to the existing verified self-service flow instead. The register entry is updated with both tools, a risk owner from payroll signs off, tool calls and approvals are logged to the HR audit store, and a trajectory test suite includes attempts to book leave for another employee. Six months later a proposal to let the assistant approve leave for managers automatically (T4) is assessed against the same artefacts before anything changes.
Detection and measurement
- Tier coverage: percentage of AI deployments in the register with an assigned tier per action class. Target 100%.
- Attribution: share of agent tool calls carrying a distinct agent identity and, where delegated, the user on whose behalf they ran. Shared or borrowed credentials should trend to zero.
- Approval integrity: consequential actions executed without a recorded approval. Target zero.
- Cost per completed task: tokens and tool calls per goal, with alerts on loops; a sudden rise often signals runaway behaviour or abuse.
- Owner coverage: agents with a named, active owner; orphaned agents found per quarter.
- Interrupt readiness: time to stop an agent and revoke its credentials in a drill.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02; GV.RR-02; PR.AA-01; PR.AA-05; DE.CM-09; GV.SC-07 | AI register; owner accountability; agent identities; least privilege; runtime monitoring; model and tool supplier risk |
| NIST SP 800-53 Rev 5 | AC-6; IA-9; CM-7; AU-2; AU-12; RA-3; SR-3 | Least privilege and least functionality for tools; service identification; tool-call logging; risk assessment per tier; supply chain for models and MCP servers |
| NIST AI 600-1 | Twelve GAI risks; four primary considerations | Baseline content risks for every tier |
| MITRE ATLAS | AML.T0051; AML.T0053; AML.T0101 | Prompt injection in both; tool invocation and destructive tool use for agents |
| OWASP | LLM Top 10 2025 (LLM06); Agentic Top 10 2026 (ASI01 to ASI10) | Risk catalogues for each side and the bridge between them |
Common failure patterns
- Approving the model, not the deployment: a model cleared for drafting is reused in an agent with write access, with no new assessment.
- Instructions as controls: "do not touch production" in a system prompt is not a permission boundary, as the Replit case showed.
- Borrowed credentials: pilots run under an engineer's account or a shared service account, so actions cannot be attributed and access outlives the pilot.
- Generative governance applied to agents: content filters and output review are kept, but nobody logs tool calls or scopes tokens.
- Silent tool growth: new MCP servers or connectors are added without updating the register or tier, so an assistant drifts from T2 to T4.
- Unbounded loops: no step, time or spend limit, so a confused agent repeats an action or burns budget for hours.
Practitioner checklist
- Classify every AI deployment as generate, recommend, act with approval or act autonomously, per action class.
- Record each agent's tools, the systems they touch and the most consequential action available.
- Issue agents their own identities with named owners; retire borrowed human and shared service credentials.
- Scope delegated tokens to the task and keep them short-lived.
- Enforce approvals for irreversible, financial, privilege and external-data actions outside the model.
- Log tool calls, parameters, approvers and outcomes, and keep logs independent of the agent's own reporting.
- Set step, time and spend limits, and rehearse interrupting an agent and revoking its credentials.
- Apply NIST AI 600-1 content controls to every tier and add OWASP agentic and Five Eyes controls from T3 upward.
- Reassess the tier whenever a tool, connector or sub-agent is added.
Standards and references
- NIST: AI 600-1 Artificial Intelligence Risk Management Framework, Generative Artificial Intelligence Profile
- Canadian Centre for Cyber Security and partners: Careful adoption of agentic AI services
- OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications for 2026
- OWASP GenAI Security Project: Top 10 for LLM Applications 2025
- UK NCSC: Prompt injection is not SQL injection (it may be worse)
- Model Context Protocol: Specification 2025-11-25, Tools
- EU AI Act: Article 50, Transparency obligations
- OpenAI: Practices for Governing Agentic AI Systems
Related NHI Mgmt Group resources: AI Agents vs Agentic AI, Agentic AI Security vs LLM App Security, AI Agent Autonomy Levels Framework, Agentic AI Identity Guide.