Because they can combine document access, code execution, and local environment visibility in one session. If the assistant reaches secrets, tokens, or keys on the developer machine, an attacker can inherit those permissions through a single malicious interaction rather than a traditional malware chain.
Why This Matters for Security Teams
MCP-connected assistants collapse multiple trust boundaries into one interactive session: they can read files, query code, invoke tools, and sometimes reach local environment variables that hold API keys or refresh tokens. That makes credential theft less about classic malware persistence and more about whether the assistant can be induced to look at the wrong data at the wrong time. Current guidance from the OWASP Agentic AI Top 10 and NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets both point to the same problem: long-lived secrets are high-value targets when an assistant can autonomously chain access across tools.
The risk is amplified because assistants do not follow a stable human workflow. They can be prompted, redirected, or tricked into expanding scope, and they may surface credentials from logs, config files, browser sessions, chat transcripts, or developer tooling. NHIMG’s AI Agents: The New Attack Surface report notes that 23% of organisations have already seen AI agents reveal access credentials, which is a strong signal that this is not a theoretical edge case. In practice, many security teams encounter credential exposure only after an assistant has already copied or exfiltrated sensitive material, rather than through intentional access review.
How It Works in Practice
The core issue is that MCP turns an assistant into an operator with broader context than most single-purpose tools. If the assistant has document access plus shell access plus a path to local secrets, a malicious prompt can steer it toward tokens, SSH keys, cloud profiles, or CI credentials. Static RBAC alone is usually too coarse because it grants access by role, not by the runtime intent of the task.
Best practice is evolving toward intent-based and context-aware authorisation, where the policy decision happens at request time. That means the assistant should only receive the minimum capability needed for the current step, ideally through just-in-time, ephemeral credentials that are automatically revoked when the task ends. This model aligns with zero standing privilege and with the direction of NIST Cybersecurity Framework 2.0, which emphasises governance, access control, and continuous monitoring. For agentic systems, the more precise primitive is workload identity, not a static user account.
Practitioners should favour cryptographic workload identity such as SPIFFE/SPIRE or OIDC-backed machine tokens for the assistant runtime, then pair that with policy-as-code at the tool boundary. In other words, the assistant should prove what it is, ask for only what it needs, and receive short-lived access that is evaluated against the current context, not a pre-approved blanket entitlement. NHIMG’s 52 NHI Breaches Analysis and Guide to the Secret Sprawl Challenge both reinforce how quickly static secrets become enterprise blast-radius multipliers. These controls tend to break down when assistants are allowed to operate on developer desktops with broad file-system access and unmanaged browser sessions, because the secret source and the execution path sit in the same trust zone.
Common Variations and Edge Cases
Tighter control over MCP-connected assistants often increases workflow friction, so organisations have to balance developer productivity against blast-radius reduction. There is no universal standard for this yet, especially in environments that mix local development, cloud consoles, and internal SaaS tooling.
One common edge case is the “helpful assistant” that reads secrets indirectly from logs or pasted snippets rather than from a dedicated vault. Another is a multi-agent workflow where one agent requests data and a second agent executes it, which can obscure who actually accessed the credential. Current guidance suggests treating each agent session as ephemeral and separately authorised, but implementation details vary across platforms and vendors. The NIST Cybersecurity Framework 2.0 can help structure the governance side, while the OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 provide a practical lens for tool misuse, secret exposure, and identity sprawl. NHIMG’s Analysis of Claude Code Security is a useful reminder that code-assist workflows need the same scrutiny as production automation.
In short, MCP increases credential theft risk when convenience outpaces identity design. The safer pattern is short-lived access, narrow tool scopes, runtime policy checks, and separate handling for any secret that an assistant can read, transform, or transmit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Covers tool misuse and agent-driven credential exposure. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret sprawl and weak NHI credential handling. |
| CSA MAESTRO | IAM-02 | Maps to workload identity and agent access governance. |
Replace static secrets with short-lived credentials and rotate anything the assistant can access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
