Standardisation makes integration easier, not safer by default. AI agents can still choose actions at runtime, so the risk comes from dynamic access decisions, not from the protocol itself. If policy does not inspect each call and session length is not bounded, the agent can move from useful automation to uncontrolled machine-speed access.
Why Standardised MCP Still Leaves Identity Risk for AI Agents
Model Context Protocol helps standardise how agents connect to tools, but it does not decide what an agent should be allowed to do at runtime. That distinction matters because the risk is not the protocol alone. It is the combination of autonomous action, broad tool access, and incomplete policy enforcement. NHI Management Group research shows only 52% of companies can track and audit the data their AI agents access, leaving 48% with a blind spot for compliance and breach investigation. The same pattern appears in AI Agents: The New Attack Surface report and in the Ultimate Guide to NHIs, where excessive privilege and weak lifecycle control amplify identity exposure.
For security teams, MCP can make integration more repeatable while still leaving the identity plane under-protected. If the agent can call tools without request-time authorisation checks, bounded session duration, and revocation after task completion, the standard only improves connectivity. It does not constrain misuse, lateral movement, or delegated overreach. In practice, many security teams discover this only after an agent has already accessed data or systems beyond its intended scope.
How Runtime Policy, Ephemeral Credentials, and Workload Identity Change the Model
AI agents increase identity risk because their access pattern is not fixed. A human account can be governed by role and workflow history, but an agent may chain tools, alter plans, and call endpoints in ways that are hard to predict upfront. That is why current guidance suggests intent-based or context-aware authorisation at request time rather than relying on static RBAC alone. The policy decision should inspect what the agent is trying to do, which tool it is invoking, what data is in scope, and whether the session still matches the original task.
In practice, stronger control depends on three linked mechanisms:
- Just-in-time credentials that exist only for one task or one bounded session.
- Workload identity for the agent, so the system proves what the agent is through cryptographic identity, not just a bearer secret.
- Real-time policy evaluation using policy-as-code so every call is checked against current context.
This is where standards such as NIST AI Risk Management Framework and OWASP Agentic AI Top 10 become operationally useful, because they push teams toward governance that treats the agent as an active decision-maker. NHI Management Group also frames this in the context of OWASP Agentic Applications Top 10, where tool chaining, prompt injection, and credential exposure are identity problems as much as application problems.
Static, long-lived secrets are especially risky because an autonomous agent can reuse them across many actions faster than a human reviewer can detect. These controls tend to break down in multi-agent environments with shared toolchains and overlapping permissions because attribution, containment, and revocation become ambiguous.
Where the Standard Breaks Down and What Practitioners Should Watch
Tighter control often increases operational overhead, requiring organisations to balance agility against review depth and credential churn. That tradeoff is real, especially when teams want MCP standardisation to reduce integration friction. Best practice is evolving, but there is no universal standard for this yet, so the practical answer is to govern the agent’s identity lifecycle more tightly than the protocol layer.
Edge cases matter. A low-risk read-only agent may tolerate a simpler policy path, but the moment it can write, approve, trigger workflows, or reach secrets stores, identity risk rises sharply. Shared service accounts, inherited permissions, and long-lived API keys are common failure points because they blur accountability and make revocation incomplete. Where agents operate across vendor platforms or indirectly through copilots, session boundaries can also become opaque, which makes auditability and containment harder.
For that reason, security teams should treat MCP as a transport standard, not a control framework. The control question is whether each action is authorised at runtime, whether the credential expires with the task, and whether the workload identity can be audited end to end. That is the difference between standardised access and governed access. It is also why current research in CSA MAESTRO agentic AI threat modeling framework is increasingly relevant for teams designing agent controls around dynamic behaviour.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Agentic tool abuse and runtime misuse are central to the question. |
| CSA MAESTRO | AI-4 | Focuses on agentic threat modeling and control points for autonomous workflows. |
| NIST AI RMF | GOVERN | Identity risk here is a governance and accountability issue for AI systems. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Long-lived secrets and poor rotation magnify agent identity risk. |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero Trust requires continuous verification of each agent action. |
Enforce request-time checks for every tool call, not trust in the protocol.
