MCP security checklist reframes agent risk as lifecycle governance

At a glance

What this is: This is a governance checklist for MCP and agentic AI environments that says the main risk is drift across identity, trust, behaviour, and control rather than a single broken control.

Why it matters: It matters because IAM, PAM, and NHI teams need a way to govern agents that can accumulate privilege and change behaviour without triggering the signals traditional security tooling expects.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Unosecur's MCP security checklist for AI agent governance

Context

Model Context Protocol changes how AI agents reach tools and data, but the bigger issue is governance: once an agent is allowed to act, its access can accumulate silently across sessions, tools, and tasks. That makes MCP security an identity problem as much as a protocol problem, especially when permissions are broad enough to keep the agent working without clear boundaries.

The article’s central claim is that security teams should treat MCP as a lifecycle discipline, not a one-time configuration exercise. For NHI, IAM, and agentic AI programmes, the question is not only whether an agent can authenticate, but whether its ownership, scope, observability, and revocation model remain valid as behaviour drifts over time.

Key questions

Q: What breaks when MCP agents are given broad permissions?

A: Broad permissions turn one compromised or manipulated agent into a wide-blast-radius identity. The agent can read, write, and trigger actions beyond the original workflow, which makes tool poisoning, credential theft, and accidental misuse far more damaging. Least privilege is the control that limits how far the delegation chain can spread.

Q: Why do MCP and agentic AI complicate IAM governance?

A: Because IAM controls are usually built around stable identities, known purposes, and review cycles that assume access remains legible long enough to inspect. MCP agents can operate continuously, chain actions, and change their effective scope faster than those cycles were designed to handle, so governance has to move from static approval to lifecycle validation.

Q: How can security teams tell whether AI agent access is drifting out of scope?

A: Look for agents touching systems, data sets, or tools that are outside the intended task boundary, especially when those actions are not part of the approved workflow. Behavioural baselines, entitlement logs, and cross-system correlation are the key signals. If the agent can act meaningfully outside its original purpose, scope drift is already happening.

Q: Who is accountable when an MCP agent accesses the wrong resource?

A: Accountability sits with the teams that defined consent, token handling, and policy review for the MCP deployment. If token passthrough, weak audience checks, or incomplete client approval allowed the request, that is a governance failure, not an agent anomaly. Frameworks such as NIST CSF and Zero Trust architecture expect explicit access validation.

Technical breakdown

Identity inventory and ownership for MCP agents

An MCP environment is only governable if every agent, server, and tool has a unique identity, a named owner, and a place in inventory. Shared or hidden identities break attribution because actions can no longer be tied to a responsible team. This is the same structural problem IAM has always faced with service accounts, but agentic systems intensify it because the identity can keep operating while its purpose changes. Discovery and ownership are therefore control prerequisites, not administrative niceties.

Practical implication: maintain an authoritative inventory of every agent identity, server, and owner before allowing production access.

Tool permission scoping and runtime privilege reality

MCP does not create privilege by itself. It exposes whether permissions were already too broad. If an agent is granted broad tool access to ‘just work’, then the protocol simply gives that access a more flexible execution layer, which can look normal until the agent begins chaining tools in unplanned ways. Runtime privilege reality means comparing what the agent is actually doing with the permissions it was originally given, then constraining the delta when the two diverge.

Practical implication: scope permissions per tool and client, then review actual agent behaviour against granted access.

Behavior visibility, kill switches, and containment

The operational danger in MCP is not only unauthorised access, but authorised behaviour that becomes unsafe over time. That is why sequence logging, drift detection, and revocation at runtime matter. If the organisation cannot see the order of tool use, it cannot tell whether a pattern is legitimate, risky, or actively abusive. A kill switch is therefore a governance control, not an incident luxury, because the system must be stoppable before cross-tool activity becomes systemic impact.

Practical implication: log sequences and intent, and test mid-execution revocation so dangerous agents can be contained quickly.

NHI Mgmt Group analysis

Lifecycle drift is the real MCP security problem, not a missing control. The article is right to frame MCP as a lifecycle issue because agents do not fail in the classic sense. They remain valid, keep working, and slowly expand their practical reach until the original approval no longer describes reality. That means identity, trust, and privilege have to be revalidated over time, not just at onboarding.

Ephemeral-looking agent access still creates standing privilege if revocation is weak. The critical failure mode is not whether a token is short-lived in isolation, but whether the agent can keep accumulating effective access across sessions, tools, and inherited permissions. When the control model assumes a bounded task but the behaviour model keeps adapting, standing privilege reappears in practice even if it was never intended in design.

Identity blast radius is the right concept for MCP governance. A broad permission set may be acceptable for one workflow, but once an agent can chain tool calls and persist across time, the blast radius becomes a product of identity scope plus behavioural drift. That is why ownership, auditability, and runtime containment belong in the same governance conversation. Practitioners should assess how far one agent can move before review catches up.

Shadow AI and unmanaged MCP servers are now the same governance class as orphaned NHI. Unowned or undiscovered agents create the same operational blind spot as forgotten service accounts, except they can also alter their tool paths and interact with data in ways humans did not anticipate. The implication is that inventory hygiene is no longer enough on its own; teams need continuous discovery tied to behavioural validation.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 48% of organisations say they have a complete blind spot because they cannot track and audit the data their AI agents access, according to the same report.
• For practitioners, the forward move is to pair behavioural telemetry with the OWASP Agentic Applications Top 10 so scope drift becomes a governable signal, not an after-the-fact surprise.

What this signals

Identity blast radius: MCP programmes now need to measure how far one agent can move across tools, data, and sessions before review catches up. That concept is more useful than a simple yes or no on access approval because it captures both privilege scope and behavioural drift in a single operational lens.

Teams that already manage service accounts and secrets should recognise the pattern immediately: discovery without revocation is incomplete governance. The same discipline that limits standing privilege in workload identity now has to extend to agents that can persist, adapt, and outgrow the original access rationale.

When agent behaviour is observable, the governance model can shift from blanket restriction to evidence-based containment. The challenge is to make drift visible early enough that security can adjust access before legitimate but unsafe action becomes normal.

For practitioners

• Inventory every agent identity and MCP server Create a continuously updated register that links each agent to a named owner, purpose, tool list, and permitted data scope. Treat any identity without ownership as an exception requiring approval or removal.
• Scope tool permissions per client and per task Avoid broad server-level permissions when a narrower tool-level boundary is possible. Revisit access when the agent’s role changes, and remove any inherited human-delegated access that is no longer necessary.
• Log sequence, intent, and outcome for agent actions Capture the order of tool calls, the context of the request, and the result so security teams can distinguish legitimate behaviour from drift. Make those logs searchable and accessible for investigation.
• Test revocation and kill switches under pressure Verify that credentials can be revoked mid-execution and that agents can be disabled before cross-tool activity completes. A kill switch that only works after the session ends is not operationally useful.
• Review access against observed behaviour, not just policy Compare what the agent is doing with the access it was granted, then remove permissions that no longer match the current workflow. Use drift as the trigger for review, not the calendar alone.

Key takeaways

• MCP risk is primarily a lifecycle and drift problem, not a single control failure.
• The most useful governance signals are ownership, scope, sequence visibility, and revocation readiness.
• Security teams that can measure identity blast radius will govern agents without slowing the business unnecessarily.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step MCP readiness checklist for pre-production approval and runtime governance
• Practical examples of identity inventory, ownership, and revocation checks across agent environments
• Detailed guidance on logging, containment, and kill-switch behaviour for live MCP deployments
• Question-by-question checklist format that implementation teams can adapt for internal review

👉 Unosecur's full blog covers the readiness checklist, runtime checks, and containment guidance in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.