Why do LLMs and agentic AI complicate traditional security and access models?

Why LLMs and agentic AI strain old access boundaries

Traditional access models assume a person, a process, or a service account performs a bounded action with a stable identity and a predictable scope. LLMs and agents blur those lines because they can interpret instructions, decide between options, chain actions, and invoke tools on behalf of an operator. That makes the real security question less about who typed the prompt and more about which authority the model can exercise, which data it can reach, and which downstream systems trust its output.

For that reason, the control problem is not just authentication. It becomes a combination of authorisation, workflow integrity, data handling, and monitoring across multiple layers. A model may be permitted to read one source, write to another, and call a third-party API, yet the combined action path can exceed what any single control was designed to police. OWASP Agentic AI Top 10 is useful here because it treats tool use, delegation, and unsafe autonomy as first-order security concerns rather than side effects. In practice, many security teams discover that the access model was sound for humans but too fragmented for agentic execution only after the first uncontrolled cross-system action has already occurred.

The same issue also appears when organisations try to separate “model risk” from “identity risk” too aggressively. If the AI can act, then its permissions, guardrails, and logs need to be judged as part of one chain of trust, not as isolated checks.

How the control path changes when the model can act

Once a system can do more than generate text, security has to treat it as an operational participant. That means the model may influence decisions, trigger actions, and move information in ways that are harder to attribute to a single human request. The practical change is that access is no longer only about what a user is allowed to see. It is about what the model can infer, what tools it can invoke, what context it can carry forward, and what it can expose through a later step.

A useful way to think about this is to separate three layers: the prompt layer, the execution layer, and the integration layer. The prompt layer covers what the model is asked to do. The execution layer covers what logic, policies, and runtime constraints sit around the model. The integration layer covers the APIs, tickets, data stores, and action systems the model can touch. A design can look safe at the prompt layer and still fail at the integration layer if the agent is allowed to call broadly scoped tools or reuse context that was never meant to leave its original system.

• Prompt controls reduce what the model is asked, but they do not on their own constrain downstream execution.
• Tool permissions define what the agent can actually do, so they must be narrower than the model’s general conversational ability.
• Audit logs need to capture the full action chain, not only the initial user request, or accountability becomes fragmented.

That is why AI governance guidance such as the NIST AI Risk Management Framework matters here: it pushes organisations to manage context, control, and accountability together rather than as disconnected technical tasks. The guidance breaks down when teams assume a model-level approval automatically covers each connected tool, because delegated access can become more powerful than the original review assumed.

Where the edge cases and trade-offs show up first

Tighter agent controls often increase operational overhead, so organisations have to balance flexibility against containment. The trade-off is especially visible when the same system needs to support retrieval, summarisation, approval workflows, and tool execution. A single rigid policy can slow useful automation, but a loose policy can make the agent effectively invisible once it starts chaining actions across services.

One common edge case is delegated work that is technically low-risk at each step but risky in combination. For example, a model that can read customer context, draft a response, and open a workflow ticket may seem harmless in isolation. Yet the combined path can leak data, create false records, or trigger real-world action without a human revisiting the full decision. Another edge case is role confusion: the user has one set of rights, the model has another, and the tool has a third. When those rights are not aligned, the environment becomes difficult to reason about and even harder to investigate after the fact. This is where the intersection with non-human identity becomes material, because the agent often behaves like a machine actor with its own standing access pattern rather than like a user session.

There is broad agreement that monitoring must follow the action path, not just the prompt. There is less consensus on how much autonomy is acceptable for high-impact decisions, so teams should treat that as a governance choice rather than a technical default. For operational clarity, the security boundary should be the least trusted point in the chain, not the most convenient one.

Risk and Threat Considerations

LLMs and agentic systems expand the attack surface by combining language understanding, tool use, and delegated authority. That creates exposure to prompt injection, tool abuse, data exfiltration, privilege misuse, and action chaining that exceeds what a traditional access review is designed to detect.

Failure mechanism: An attacker, malicious insider, or compromised input source can manipulate the model’s instructions or context so it selects unsafe tools, reveals sensitive data, or performs an authorised action in an unintended order. The weakness is usually not the model alone, but the trust placed in upstream prompts, retrieved content, and downstream integrations.

Impact: The result can be unauthorised disclosure, corrupted records, unsafe automation, lateral movement through connected systems, or loss of accountability because the final action no longer maps cleanly to a human decision.

Practitioner Guidance

What to verify: Security teams should verify the full decision-to-action chain before trusting an AI workflow, including which identity is acting, which tools are reachable, and which approvals are actually enforced. The key question is not whether the model is “allowed” to help, but whether its delegated scope still makes sense if the model is confused, manipulated, or overconfident.

What practitioners underestimate: The hardest part is usually not blocking obvious bad outputs. It is proving that an apparently harmless sequence of small actions cannot accumulate into a high-impact one. Teams should pay close attention to cross-system side effects, because that is where autonomy becomes operationally meaningful rather than merely conversational.

Practitioner takeaway: Treat agentic ai as a governed actor with bounded authority, not as an interface layer, because the security failure usually emerges at the handoff between reasoning, execution, and inherited trust.

Related resources from NHI Mgmt Group

• Why do agentic AI systems complicate traditional recovery and access review models?
• Why do LLMs complicate traditional access control models?
• Why do AI agents and frontier models complicate traditional security testing?
• Why do AI agents complicate traditional observability and access control models?