Why do agentic AI systems require different controls from LLM applications?

Why This Matters for Security Teams

agentic ai changes the security problem because the system is no longer confined to producing text. It can choose tools, chain actions, invoke APIs, write files, open tickets, or trigger downstream workflows. That means the real control point is not just the prompt or the model output, but the authority granted to the agent and the safeguards around each action it can take. Guidance from the NIST AI Risk Management Framework is useful here because it frames AI risk as a lifecycle issue, not a single filter.

LLM applications are often secured with content moderation, prompt filtering, and response validation. Those measures still matter for agentic systems, but they are incomplete if the agent can act independently. Once tool use, persistence, and delegation are introduced, the security model must account for misuse of legitimate authority, unsafe sequencing, and hidden state carried across steps. The difference is operational: a safe-looking response can still be followed by a harmful action.

In practice, many security teams encounter agentic risk only after a workflow has already executed an unauthorised action, rather than through intentional design of action boundaries.

How It Works in Practice

Agentic controls should be built around the full action path: what the agent can see, what it can decide, what it can execute, and what it can remember. A strong baseline is to separate the model from the tool layer and enforce policy at the orchestration boundary. That means each tool call should be authenticated, authorised, logged, and constrained to a narrow purpose. The OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework both reinforce that agentic systems need threat modeling beyond prompt injection alone.

• Limit tool scope with explicit allowlists for functions, APIs, and data domains.
• Use step-level approvals for high-impact actions such as payment, deletion, or privilege change.
• Apply short-lived credentials and separate identities for each agent, workflow, and environment.
• Constrain memory so the agent cannot reuse sensitive context outside its intended task.
• Monitor for anomalous action chains, repeated retries, and unexpected delegation patterns.

Runtime monitoring should look for behaviour, not just content. A benign prompt can still lead to harmful sequencing if the agent is manipulated into making an unsafe decision tree. The MITRE ATLAS adversarial AI threat matrix is useful for mapping these attack paths, and the NIST AI 600-1 Generative AI Profile helps translate that risk into governance and validation expectations.

These controls tend to break down when agents are embedded in legacy automation with broad service accounts and weak workflow segregation, because the agent inherits too much authority from the surrounding system.

Common Variations and Edge Cases

Tighter control often increases latency and operational overhead, so organisations have to balance autonomy against the risk of uncontrolled execution. There is no universal standard for how much autonomy is acceptable yet, and current guidance suggests that the answer depends on task criticality, data sensitivity, and the blast radius of a mistaken action.

Some environments can tolerate limited autonomy with strong guardrails, while others need human approval before any external side effect. In regulated workflows, such as finance, health, or identity verification, agent actions may also need auditability, provenance, and clear accountability for every tool invocation. Where the agent uses identity data or administrative privileges, the intersection with IAM and NHI governance becomes material: each non-human identity should have a defined purpose, least-privilege access, and revocation procedures tied to the workflow lifecycle.

Best practice is evolving for memory management, shared context, and delegation chains. In some deployments, persistent memory is helpful for continuity; in others it creates hidden risk because stale or poisoned context can influence later actions. The safest pattern is to treat memory as a governed data store, not an invisible convenience layer. For broader governance alignment, the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026 provide a practical basis for scoping controls without assuming that LLM app safeguards are enough.

Related resources from NHI Mgmt Group

• Why do AI agents create a different access-risk profile than traditional applications?
• Why do agentic AI systems create a different security problem from static applications?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• How should security teams govern machine identity credentials in agentic AI environments?