How should security teams apply existing control frameworks to LLMs, agents, and MCP integrations?

Why This Matters for Security Teams

Existing control frameworks still apply to LLMs, agents, and MCP integrations, but the control target changes. An LLM mainly consumes and produces content, so the risk sits in prompt handling, data leakage, and unsafe outputs. An autonomous agent can chain tools and act, so the risk shifts to authorization, escalation, and auditability. MCP connections add another layer because they expose tool access and secrets handling in a way that can silently widen the attack surface. NIST’s NIST AI Risk Management Framework and NHIMG’s AI Agents: The New Attack Surface report both reinforce the same point: teams need to preserve familiar control intent while mapping it to the AI layer that is actually executing.

The mistake many programmes make is treating “AI security” as a brand new discipline and then bolting on generic governance after deployment. That approach misses the fact that agents are already operating with execution authority, and MCP servers can expose credentials and tool scope far beyond what traditional application reviews expect. In practice, many security teams discover control gaps only after an agent has already acted outside scope or an MCP integration has already exposed secrets.

How It Works in Practice

Apply control frameworks by separating the AI stack into three security surfaces: model interaction, agentic action, and tool connectivity. For LLMs, map controls to content safety, data minimisation, logging, and prompt injection resistance. For agents, map controls to intent-based authorisation, just-in-time privilege, and constrained tool execution. For MCP integrations, map controls to secrets management, access scoping, and change control over what tools and resources the server can expose.

This is where existing frameworks remain useful. OWASP Agentic AI Top 10 is a strong reference point for application-layer abuse patterns, while CSA MAESTRO agentic AI threat modeling framework helps teams reason about multi-step execution and trust boundaries. NIST CSF still maps well for identify-protect-detect-respond-recover activities, but it needs to be interpreted at the AI workload level, not just the platform level.

• Use RBAC for human administrators, but do not rely on RBAC alone for agents with dynamic goals.
• Prefer runtime policy checks for agent actions instead of fixed allowlists that age quickly.
• Issue short-lived credentials for each task and revoke them when the task ends.
• Store and rotate MCP secrets as high-risk secrets, not as ordinary application config.
• Log prompts, tool calls, outputs, and policy decisions so audits can reconstruct what happened.

NHIMG’s The State of MCP Server Security 2025 highlights how often MCP deployments still leak secrets or fail to scope tool permissions, which makes the control mapping concrete rather than theoretical. These controls tend to break down when agents are allowed to chain multiple tools across systems because the effective privilege becomes emergent, not pre-approved.

Common Variations and Edge Cases

Tighter control mapping often increases latency, review overhead, and operational friction, so organisations have to balance agility against assurance. That tradeoff is especially visible in development environments, where teams want broad tool access for rapid experimentation but still need to prevent accidental data exposure or destructive actions.

There is no universal standard for every AI layer yet, so guidance is still evolving. Current best practice is to treat high-risk agent actions differently from low-risk content generation. For example, an internal summarisation LLM may only need data-loss prevention and prompt monitoring, while an agent that can open tickets, approve changes, or access production systems needs a much stronger control set. The same framework can apply to both, but the control depth should not be identical.

Edge cases also appear in MCP deployments that broker access between multiple tools or tenants. In those environments, security teams should treat the MCP server as a privileged integration layer and apply stronger review, secret segmentation, and allowlisted tool exposure. NHIMG’s Moltbook AI agent keys breach and the OWASP NHI Top 10 both point to the same operational reality: once machine identities and tool credentials spread across workflows, the control problem becomes one of containment, not just prevention.

Related resources from NHI Mgmt Group

• How should security teams secure MCP servers that expose Kubernetes control to AI agents and local browser traffic?
• How should security teams govern AI agents that use existing NHI credentials?
• How should security teams govern bearer tokens used by AI agents and SaaS integrations?
• How should security teams handle tool discovery for AI agents in MCP environments?