Context Gravity

Expanded Definition

Context gravity describes a structural bias in which the platform hosting an agent becomes the de facto source of meaning, policy, and execution boundaries. In NHI and agentic AI environments, that bias can shape how tools are selected, how data is interpreted, and which actions are considered permitted. The result is not just technical dependence, but semantic dependence.

This matters because agents do not reason in a vacuum. If prompts, memory, routing logic, guardrails, and tool schemas are all controlled by one platform, then enterprise governance can drift toward that platform’s definitions rather than the organisation’s own identity, risk, and access model. That is why context gravity is best understood alongside NIST Cybersecurity Framework 2.0, especially where governance and control consistency are required across systems.

Definitions vary across vendors, and no single standard governs this yet. Some teams use the term loosely to mean “platform lock-in,” but the NHI security meaning is narrower: semantic and operational authority accumulating where the context is hosted. The most common misapplication is treating context gravity as a procurement issue only, which occurs when organisations ignore how platform-owned context alters policy enforcement and agent decision paths.

Examples and Use Cases

Implementing agent governance rigorously often introduces coordination overhead, requiring organisations to weigh faster platform-native automation against the cost of losing neutral control over meaning and policy.

• An AI agent hosted in one workflow platform inherits that platform’s approval schema, so access decisions no longer match the enterprise IAM model.
• A vendor-managed memory layer stores task context, and the agent begins treating vendor labels as authoritative even when internal taxonomy differs.
• A tool-calling system is tuned around one provider’s resource names, making cross-platform orchestration fragile and hard to audit.
• An enterprise attempts to standardise policy across multiple agents, but the platform that owns the context store also controls what the agent can “remember.”
• In a third-party integration review, the team discovers that semantic routing rules are embedded in the platform rather than in governed enterprise controls, a pattern that aligns with concerns raised in the Ultimate Guide to NHIs.

For implementation patterns, context gravity is best compared with identity and access design principles documented in the NIST Cybersecurity Framework 2.0, because both emphasise consistent control boundaries rather than ad hoc platform defaults.

Why It Matters in NHI Security

Context gravity becomes dangerous when an agent’s reasoning, secrets access, and action scope are implicitly bound to a single platform that also defines the policy vocabulary. That can undermine segregation of duties, weaken portability, and hide privilege expansion inside “helpful” defaults. In practice, it can also obscure where service-account context begins and ends, which makes offboarding, rotation, and auditability harder to enforce.

NHI Management Group reports that Ultimate Guide to NHIs finds 97% of NHIs carry excessive privileges, a figure that is especially relevant when platform-owned context quietly broadens agent authority. Once semantic control concentrates in one place, even accurate logging can be misleading if the logs reflect vendor-defined intent rather than enterprise-defined policy.

Organisations typically encounter the risk only after an agent makes an unexpected tool call, exposes a secret, or follows the wrong approval path, at which point context gravity becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the Model Context Protocol (MCP) and why does it matter for security?
• What is MCP in the context of AI security?
• When is it appropriate to implement MCP in the context of AI systems?
• Why is organizational context important for AI agents?