CIS companion guides bring ai agents and MCP into CIS controls

TL;DR: CIS has published three Companion Guides for LLMs, AI agents, and MCP environments that map AI security back onto the existing CIS Critical Security Controls, highlighting prompt injection, privilege boundaries, and auditable tool use across deterministic systems. The practical shift is governance first: inventory, authorization, and NHI control now define safe AI adoption.

At a glance

What this is: CIS published three Companion Guides that apply the CIS Critical Security Controls to LLMs, AI agents, and MCP environments, with a shared emphasis on inventory, authorization, and auditable actions.

Why it matters: For IAM and NHI practitioners, the value is that AI security is being framed as an identity and control problem, not a separate exception process.

👉 Read CIS's companion guides for LLM, AI agent, and MCP security controls

Context

AI agent governance is now a control-plane problem, not just a model-risk problem. Once an agent can call tools, carry memory, and act through non-human identities, the security question becomes who or what can authorize those actions and under what conditions. That is the core NHI governance gap the CIS Companion Guides are trying to address.

The guides split the problem into three layers: the model, the agent, and the MCP protocol that connects tools to execution. That separation is useful because many failures arise when teams treat all AI behaviour as one category. In practice, the starting point described here is typical for mature security programmes, but many organisations still blur discovery, policy, and action controls.

Key questions

Q: How should security teams govern AI agents with existing IAM controls?

A: Treat each AI agent as a privileged workload with a dedicated non-human identity, explicit ownership, and tightly scoped permissions. Apply inventory, access review, logging, and change control before expanding capabilities. The goal is to make every agent action traceable to a policy decision, not to rely on the model behaving safely on its own.

Q: Why do AI agents create more NHI risk than traditional software services?

A: AI agents can choose actions, chain tools, and operate across contexts, so their credentials often gain broader practical reach than ordinary service accounts. That increases the impact of misuse, prompt injection, or misconfiguration. The risk is not the agent itself, but the combination of autonomous behavior and standing access.

Q: What is the difference between securing LLMs and securing AI agents?

A: LLM security focuses on inputs, outputs, and data leakage at the model layer. AI agent security adds the execution layer, where tool use, privilege boundaries, and identity controls determine what the system can actually do. In practice, agents require both content controls and hard authorization controls.

Q: When should organisations introduce controls for MCP environments?

A: Controls should be in place before MCP is used to reach production tools or sensitive data. Once MCP becomes the path between an AI system and real operational resources, it needs allowlisting, monitoring, and change control. Waiting until after rollout usually means the most sensitive integrations are already exposed.

Technical breakdown

Why AI security breaks when authorization is not deterministic

The shared failure mode across LLMs, agents, and MCP environments is not the specific attack string. It is nondeterministic behavior meeting deterministic access control. Prompt injection, confused deputy issues, and rug-pull tool behavior all exploit the same gap: the system trusts an input or output that should never be treated as authority. In an identity-centric model, the decisive boundary is the NHI attached to the action, not the model output that suggested it. That means system prompts are configuration, tool calls are access requests, and logs are part of the control evidence. If those boundaries are blurred, governance becomes guesswork.

Practical implication: Treat every AI action as an authorization event and enforce policy before execution.

How non-human identities define AI agent privilege

AI agents do not act on their own. They act through API keys, service accounts, OAuth tokens, and other non-human identities that determine what the agent can read, write, and execute. That identity layer is where least privilege either works or fails. If an agent has broad standing access, the model layer becomes a path to enterprise abuse. If access is scoped to task, environment, and duration, the blast radius narrows sharply. This is why inventory and entitlement review matter before you argue about prompts or model quality. The real risk sits in the credentials that give the agent operational reach.

Practical implication: Map every agent to a distinct NHI and constrain it to task-scoped, auditable access.

What MCP adds to the security model

MCP changes the boundary by making tool access a protocol-level concern. That creates a cleaner integration pattern, but it also creates a new place for trust to fail if servers, clients, or tool descriptors are not controlled. The security questions become whether tool invocation is allowlisted, whether interactions are auditable, and whether the server can change behavior after integration in ways the control plane does not detect. For practitioners, MCP is not just another integration layer. It is where model intent meets operational authority, so it needs the same discipline applied to privileged system interfaces.

Practical implication: Apply allowlisting, logging, and change control to MCP endpoints before broad rollout.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI governance must now be read as NHI governance. Once an agent can touch tools, memory, and data through credentials, the security problem stops being theoretical model risk and becomes identity control. The CIS guidance is useful because it places AI back inside the control families security teams already understand. Practitioners should govern agents as privileged workloads, not as chat interfaces.

Identity sprawl will be the first major failure mode of enterprise AI adoption. Every new agent, MCP server, and model integration can create another credential, token, or service account that someone must track. That sprawl is operational debt with security consequences, because unmanaged access becomes the default permission model. Practitioners should expect NHI inventories to become a prerequisite for AI assurance.

Prompt injection is only one expression of a broader authorization problem. The deeper issue is that AI systems can be nudged into acting outside intended policy whenever output is mistaken for authority. That is why system prompts, tool calls, and runtime decisions need separate controls and evidence trails. Practitioners should design for deterministic authorization, not for perfect model behavior.

MCP creates a new control surface, not a new excuse for exception handling. Protocol abstraction can improve integration, but it also concentrates trust in the tool boundary. If teams treat MCP as a special case, they will miss the same identity, logging, and change-control failures that already cause trouble in cloud and SaaS. Practitioners should fold MCP into the existing privileged access model.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a practical control roadmap, see OWASP Agentic Applications Top 10 for a framework-oriented view of agent risk.

What this signals

Identity sprawl is the operational consequence of agent adoption. With 80% of organisations already reporting AI agents that have acted beyond intended scope, the control failure is no longer hypothetical. Security teams should expect their next governance bottleneck to be NHI inventory, not model selection, and they should align that work with OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework.

The policy gap will widen unless agent access is treated like privileged access from day one. Teams that wait for a post-deployment clean-up usually discover that credentials, tool permissions, and audit evidence are already fragmented across environments. The programme-level response is to fold AI into existing identity governance, not to create a parallel exception process.

Runtime governance gap: the next phase of AI adoption will reward teams that can prove who authorised an action, which credential executed it, and whether the tool path was expected. That evidence chain matters more than model accuracy when regulators, auditors, or incident responders start asking questions. Practitioners should prepare to answer those questions with identity logs, not model narratives.

For practitioners

• Inventory AI systems and connected NHIs first Build a complete register of LLMs, agents, MCP clients, MCP servers, API keys, service accounts, and OAuth tokens before expanding use cases. Tie each item to an owner, purpose, and environment so that access review and incident response have a defensible starting point.
• Separate model guidance from authorization logic Ensure prompts, tool outputs, and assistant memory can influence suggestions but never directly approve access, write actions, or privileged tool use. Put deterministic policy checks in front of every sensitive action and log the decision path for audit.
• Apply least privilege to AI agent credentials Issue distinct non-human identities for different agents and scope each one to the smallest workable set of resources, operations, and time windows. Review standing access regularly and remove broad credentials from shared workflows.
• Allowlist and monitor MCP tool access Permit only approved tools, enforce change control on server behavior, and retain audit logs for every tool invocation and response. If the protocol endpoint can change behavior silently, treat it as a privileged interface that needs stronger controls.

Key takeaways

• AI security now sits inside identity governance because autonomous systems act through credentials, not intuition.
• The scale of the problem is already visible: most organisations say AI agent governance matters, but fewer than half have policies in place.
• Teams that inventory NHIs, separate authorization from prompts, and constrain tool access will be better positioned to scale AI without losing control.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity that performs work without a person directly signing in. In practice, this includes service accounts, API keys, tokens, certificates, and AI agent credentials. These identities need ownership, scope, and lifecycle controls because they can read, write, and execute just like human users.
• Confused Deputy Problem: The confused deputy problem occurs when a higher-privileged system is tricked into using its authority on behalf of an untrusted requester. In AI environments, that usually means an agent or tool is nudged into taking an action it was not meant to perform. The fix is deterministic authorization tied to the actual request, not the apparent intent.
• MCP Environment: An MCP environment is the tool-execution layer built around the Model Context Protocol, where AI systems connect to external data sources and actions. Security teams need to treat it as a privileged integration surface because it can expose read and write access, audit gaps, and hidden trust changes after deployment.
• Prompt Injection: Prompt injection is an attack that manipulates model inputs or surrounding context so the system follows attacker-supplied instructions instead of intended policy. The practical risk is not just bad text generation. It is that the model can be pushed toward unsafe data use, tool misuse, or unauthorized actions if outputs are trusted too far.

What's in the full article

CIS's full companion guide covers the operational detail this post intentionally leaves for the source:

• The guide-by-guide mapping of each CIS Control to LLM, agent, and MCP implementation scenarios
• Implementation Group guidance for tailoring controls to different AI risk profiles and maturity levels
• The specific handling notes for prompt injection, confused deputy issues, and rug-pull behavior in MCP servers
• A live walkthrough format that shows how the companion guides fit into existing control programs

👉 The full CIS material includes the control-by-control operational mapping and walkthrough details

Deepen your knowledge

AI agent identity governance, MCP access control, and privileged workflow design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous systems from a similar starting point, it is worth exploring.