What breaks when LLM and agent security controls are managed in isolation?

Why This Matters for Security Teams

Managing LLM controls and agent controls separately creates a false sense of coverage. An LLM may be constrained at the prompt layer while the agent that wraps it still has broad tool access, weak credential boundaries, and no shared policy view. That split is especially dangerous because autonomous systems do not follow fixed paths; they assemble actions at runtime. Guidance from the OWASP Agentic AI Top 10 and NHIMG research on the OWASP NHI Top 10 both point to the same operational reality: security fails when identity, access, and runtime behaviour are governed in separate silos.

Fragmentation also breaks incident response. If data-flow controls live in one team, access approvals in another, and agent telemetry in a third, no one can quickly confirm whether a given action was permitted, inherited, or abused. That is where audit evidence becomes incomplete and containment slows down. In NHIMG’s AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope, which shows this is not a theoretical gap. In practice, many security teams discover the split only after an agent has already chained access across systems and left inconsistent logs behind.

How It Works in Practice

For LLM and agent security to work together, controls need to be evaluated as one runtime chain rather than as separate point solutions. The LLM layer governs content, prompt handling, and model behavior; the agent layer governs what the system can do with tools, data, and credentials. When those layers are aligned, the organisation can answer three questions at request time: what is the agent trying to do, what data or systems is it touching, and is that action still within policy?

In current guidance, the most workable pattern is a combination of workload identity, context-aware authorisation, and short-lived access. The agent should present a cryptographic workload identity, such as SPIFFE or OIDC-backed identity, and then receive just-in-time credentials only for the task at hand. Policy-as-code engines can evaluate the request dynamically using context such as user intent, data sensitivity, model confidence, environment, and whether the tool call crosses a trust boundary. That approach aligns with the NIST AI Risk Management Framework, the CSA MAESTRO agentic AI threat modeling framework, and NHIMG’s The State of Non-Human Identity Security findings on rotation, monitoring, and over-privilege.

• Use one policy decision point for both model and tool execution, rather than separate approval paths.
• Issue ephemeral secrets per task and revoke them automatically when the task ends.
• Log prompt, tool use, and downstream data access in a shared audit trail.
• Recheck authorization at every tool call, not only at session start.

This guidance tends to break down in multi-agent systems with shared memory and loosely governed plugins because one agent can inherit trust from another without a fresh policy check.

Common Variations and Edge Cases

Tighter joint control often increases latency, policy complexity, and operational overhead, so organisations have to balance enforcement depth against developer friction. That tradeoff is real, especially when teams are trying to ship copilots quickly or extend agents across many internal tools. Best practice is evolving, and there is no universal standard for how much agent autonomy should be centrally mediated versus delegated to application owners.

One common edge case is when the LLM is heavily sandboxed but the agent still has broad network or API reach. Another is when an organisation treats prompt-injection defense as sufficient, even though the real failure occurs later when the agent uses legitimate credentials to perform unsafe actions. The same risk appears in hybrid environments where human identity governance is mature but NHI governance is not, creating gaps in revocation, ownership, and evidence collection. NHIMG research on the Top 10 NHI Issues and the Ultimate Guide to NHIs is useful here because it frames lifecycle management, not just point-in-time access control. For teams building toward stronger governance, the AI Agents: The New Attack Surface report and NIST Cybersecurity Framework 2.0 both reinforce the need for shared ownership, measurable boundaries, and continuous verification.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on endpoint security to govern LLM prompts and agent tool calls?
• What breaks when organisations rely on container isolation alone for AI agent security?
• What breaks when AI agent controls are split across separate data, security, and recovery tools?
• What breaks when Microsoft 365 security is managed only with detection and not posture controls?