Why do AI agents create new risk when authentication and authorization are split between the model and the surrounding application?

Why split authority between the model and the application changes the security picture

When an AI agent can suggest actions but the surrounding application decides what is actually allowed, the risk shifts from simple access control to control integrity. The model may be able to steer intent, choose tools, or shape execution paths without ever being the component that enforces permissions. That creates a larger attack surface because security failures can emerge in the handoff between reasoning, orchestration, and authorization.

This is why agentic systems need to be designed around clear trust boundaries, not around the assumption that the model will behave like a reliable policy engine. The most important question is not whether the model is “smart enough,” but whether the application can prevent the model from turning a normal request into an unsafe operation. Guidance from the OWASP Agentic AI Top 10 is useful here because it frames these systems around agent-specific failure modes rather than generic chatbot misuse. In practice, many security teams discover the real weakness only after tool access, prompt manipulation, or orchestration logic has already been exposed.

How the split creates exploitable gaps in practice

The core issue is that authentication answers “who is this?” while authorization answers “what may this identity do?” In an agentic architecture, the model often influences both the request content and the sequence of tools invoked, but it should not be trusted to make the permission decision itself. If the application checks permissions too late, too broadly, or against the wrong context, the agent can become an indirect path to actions that would never be permitted through a normal user interface.

That risk is strongest when the model can generate structured commands, call tools, or trigger backend workflows with minimal human review. A malicious prompt, a poisoned retrieval result, or a manipulated conversation can cause the agent to request an operation that appears normal at the language layer but is dangerous at the application layer. The surrounding system must therefore bind every sensitive action to explicit policy, context, and session state, rather than relying on the model’s intent or on post-hoc filtering. NIST’s AI Risk Management Framework is relevant because it reinforces governance, mapping, measurement, and management of AI risk across the system rather than treating the model in isolation.

• Keep policy enforcement outside the model, where it can be tested and audited.
• Limit each tool to the smallest action set needed for its function.
• Check the authorization context at the moment of execution, not only at session start.
• Record which request, context, and policy decision led to each sensitive action.

This model breaks down when the agent is allowed to act across multiple systems with shared trust, because a small orchestration flaw can turn one confused request into broad unauthorized reach.

Where the boundary gets blurred and why that matters

Tighter separation between model and application usually improves control, but it also increases integration overhead, making teams balance safety against usability and automation depth. That tradeoff becomes most visible when organisations try to preserve a smooth user experience while still enforcing strong authorization at every step.

One common edge case is delegated action. If the application lets the model draft a request, but then treats that draft as equivalent to user intent, the system may quietly promote suggestions into approvals. Another is tool chaining, where one low-risk action produces context that enables the next, more sensitive action. The individual calls may each look acceptable, yet the sequence creates a privilege expansion path that neither the model nor the application intended. This is also where agent governance differs from conventional API security: the danger is not just an exposed endpoint, but a logic path that lets language output influence access decisions.

That is why agentic security discussions increasingly emphasise explicit policy gates and traceable execution rather than conversational confidence. The question is not whether the model can explain itself, but whether the surrounding system can stop it from asking for more than it should have. For threat-focused context on agent abuse patterns, MITRE ATLAS adversarial AI threat matrix is a useful complement because it focuses attention on adversarial behaviour against AI-enabled systems.

Practitioner Guidance

What to prioritise: Treat execution authority as the control point, not the conversation layer. The first design decision should be which operations are explicitly non-negotiable and must never be inferred from model output alone.

What to verify: Confirm that every sensitive tool call is independently authorised against the current session, current user, and current action context. If the model can influence scope without a fresh enforcement check, the boundary is too soft.

Common mistake: Teams often assume that a well-behaved prompt or a filtered response is enough to protect the workflow. That is fragile, because the real issue is whether the application can resist a persuasive but unauthorized request path.

Practitioner takeaway: The safest agent architecture is the one where the model can recommend, but never silently inherit authority; once suggestion and permission blur together, the system stops being a bounded assistant and starts becoming a delegated control risk.

Related resources from NHI Mgmt Group

• Why do AI agents using Model Context Protocol create new governance risk for compliance programmes?
• Why do AI agents create new authorization risk even when credential hygiene is strong?
• Why do AI coding agents create new risk when they are allowed to handle application infrastructure and configuration?
• Why do AI coding agents create new risk assumptions in application security?