What is Agentic AI and how does it differ from traditional generative AI?

Why This Matters for Security Teams

Agentic AI changes the security problem from “what did the model say?” to “what can the system do next?” That shift matters because autonomous agents can plan, chain tools, and act across services without waiting for a human after each step. Traditional generative AI is usually prompt-response; agentic AI is execution-oriented, which means identity, authorisation, and audit controls become the real control plane. This is why current guidance such as the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework treat autonomy as a distinct risk category, not just a model-quality issue.

NHI teams should also view agentic systems as a new class of workload identity problem. Agents need scoped access to APIs, data, and code execution, but they do not follow static human access patterns. That makes role-based access alone too blunt for many deployments, especially where the agent can self-select tools based on context. In practice, many security teams encounter over-privilege only after an agent has already called the wrong API, touched sensitive data, or taken an unintended action.

The operational signal is clear: SailPoint reports that 80% of organisations say their AI agents have already acted beyond intended scope, including unauthorised system access and sensitive data exposure, as documented in AI Agents: The New Attack Surface report.

How It Works in Practice

Security for agentic AI starts with intent-based authorisation, not fixed entitlements. The agent should present a workload identity, then request only the capability needed for the current task. That identity can be backed by standards such as SPIFFE/SPIRE or OIDC-bound service tokens, so the system can prove what the agent is, rather than relying on a shared secret that never changes. For implementation claims, the MITRE ATLAS adversarial AI threat matrix is useful for thinking about how those identities are attacked once adversaries observe agent behaviour.

In practice, the safest pattern is short-lived, JIT-issued credentials with policy evaluated at request time. That means per-task tokens, explicit scope, and automatic revocation when the workflow completes. Static IAM roles fail here because an agent’s behaviour is dynamic: it may decide to read a file, call a browser tool, write to a ticketing system, then chain into a code repo or payment API. The policy engine must understand task context, data sensitivity, and environment state before approving the action.

• Use workload identity for the agent, not a human proxy account.
• Issue ephemeral secrets with tight TTLs and automatic revocation.
• Evaluate authorisation at runtime with policy-as-code, such as OPA or Cedar.
• Separate tool permissions from data permissions so a task does not inherit broad access.
• Log every tool call, token exchange, and data read/write for investigation.

NHIMG research on OWASP NHI Top 10 and the Ultimate Guide to NHIs — What are Non-Human Identities frames this well: an agent is not just a model, it is a privileged workload with identity, scope, and revocation requirements. These controls tend to break down when agents are allowed to self-discover tools in loosely governed SaaS and cloud environments because the runtime cannot reliably distinguish experimentation from authorised execution.

Common Variations and Edge Cases

Tighter runtime controls often increase operational overhead, requiring organisations to balance safety against latency, integration complexity, and developer friction. That tradeoff becomes sharper in multi-agent systems, where one agent may delegate to another, or where the workflow spans chat, code execution, and external SaaS. There is no universal standard for handling every agent delegation pattern yet, so current guidance suggests starting with the highest-risk actions first: data export, credential use, infrastructure changes, and payment or admin workflows.

One common edge case is “semi-agentic” tooling, where a product looks conversational but quietly executes actions behind the scenes. Another is human-in-the-loop approval that exists in policy but not in real operations because the approval step is bypassed for speed. A third is long-lived secrets embedded in agent configs or environment variables, which undermines the value of JIT access. The recent NHIMG analysis in DeepSeek breach and Moltbook AI agent keys breach reinforces a simple point: secrets sprawl turns agent autonomy into an exposure multiplier.

For governance, best practice is evolving toward ZTA-style segmentation, least-privilege tool access, and measurable agent accountability. The NIST AI 600-1 Generative AI Profile can help anchor documentation, but agentic systems need stricter operational proof than model governance alone. Where agents touch production data or production infrastructure, static RBAC should be treated as a starting point, not the end state.

Related resources from NHI Mgmt Group

• What NHI types do Agentic AI systems typically use?
• Why does Agentic AI dramatically increase identity sprawl?
• What is identity spoofing in Agentic AI and how does it work?
• What is supply chain amplification in Agentic AI security?