The condition where information intended to describe or route a request begins to shape access, execution, or model behaviour as if it were policy. In MCP environments, this happens when tool descriptions or metadata are consumed as trusted instructions.
Expanded Definition
Context-to-control drift describes a failure mode in which descriptive context, such as tool metadata, routing text, or workflow annotations, is treated as if it were enforceable policy. In MCP environments, the line matters because model-facing context can be consumed by an agent, tool broker, or downstream automation as instruction rather than reference data. That distinction is central to NIST Cybersecurity Framework 2.0 style governance, where access decisions should be explicit, testable, and separated from descriptive content.
Definitions vary across vendors because some platforms blur prompt content, tool schemas, and authorization logic into a single control surface. NHI Management Group treats the term as a governance and design flaw: the metadata meant to help an agent understand a service begins to influence what it is allowed to do. That is especially dangerous when tool names, descriptions, or policy hints are embedded in contexts that the model can read but should not interpret as authority. The most common misapplication is assuming that a well-written tool description is harmless when it is actually being parsed by the agent as operational guidance in a privileged workflow.
Examples and Use Cases
Implementing MCP and agent controls rigorously often introduces friction between usability and safety, requiring organisations to weigh richer automation against tighter separation of instruction and policy.
- An agent receives a tool description that says “use only for finance approvals” and then treats that text as an instruction to prioritise finance-related actions, even though no policy engine granted that scope.
- A routing layer exposes metadata about “trusted internal tools,” and the model elevates confidence in those tools instead of verifying authorization through an external control plane.
- During incident response, the agent consumes a context block that includes deprecated access notes, and those notes override current revocation state, creating unsafe execution paths.
- A workflow designer embeds usage guidance inside an MCP schema, and the agent begins following the guidance as if it were an access rule rather than a human-readable hint.
- The pattern aligns with breach lessons such as the Salesloft OAuth token breach, where trust boundaries around contextual signals and tokens became operationally significant.
This is why practitioners often pair agent workflow design with reference material like the Ultimate Guide to NHIs and standards-oriented guidance from NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Context-to-Control Drift matters because NHIs fail in practice when descriptive artifacts become de facto policy. Once an agent can act on tool metadata, the organisation no longer has a clean separation between identity, authorization, and execution. That can lead to privilege inflation, unsafe tool invocation, and hidden dependency on stale configuration. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which makes drift even harder to detect because the systems affected are often already under-observed.
Good governance therefore requires explicit policy enforcement outside the model, strict schema design, and review of every field that a model may infer from. The practical control objective is to ensure that context informs comprehension, not authorization. Teams should treat any text that can influence execution as a potential attack surface, especially in MCP-connected agents where tool descriptions, examples, and fallback notes may all be read as guidance. Organisationally, this becomes visible only after an agent performs an action that seemed “reasonable” to the model but was never actually permitted, at which point context-to-control drift becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 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 | A01 | Addresses prompt and instruction confusion that lets context act like control. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Drift creates unsafe NHI authority when metadata influences execution decisions. |
| CSA MAESTRO | Requires explicit trust boundaries for agent tool use and orchestration inputs. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must be enforced by policy, not by contextual hints. |
| NIST Zero Trust (SP 800-207) | SCM-3 | Zero trust demands continuous verification rather than trusting context as authority. |
Enforce access decisions through control mechanisms and review drift-prone metadata regularly.
Related resources from NHI Mgmt Group
- What is the difference between context-based authentication and static access control?
- What is the difference between static ACLs and context-based access control?
- Who is accountable when a service goes dark because of network control-plane drift?
- How can teams decide whether to use context-based access control for GenAI?
