Notifications
Clear all
Topic starter
24/06/2026 7:29 pm
TL;DR: Enterprise systems are shifting from model centrality to contextual determinism, with Collibra arguing that the LLM is becoming interchangeable while governed context is the real differentiator. That changes the security conversation from model selection to lifecycle control, access boundaries, and operational governance across data, agents, and orchestration.
NHIMG editorial — based on content published by Collibra: Models are commodities, context is proprietary: Why context engineering is the new business standard
Questions worth separating out
Q: How should security teams govern context used by AI systems?
A: Security teams should govern context as an entitlement layer.
Q: Why does too much context increase security risk?
A: Too much context increases security risk because it expands both the information a system can expose and the number of downstream workflows that can act on it.
Q: What do teams get wrong about model choice versus context design?
A: Teams often focus on model selection when the more important control is context design.
Practitioner guidance
- Map context retrieval to identity entitlements Inventory which users, service accounts, and agents can query which data sources, then define those permissions as explicit access paths rather than informal integration logic.
- Set minimum effective context thresholds Define the smallest context bundle needed for each workflow and remove broad default access to historical records, full customer histories, and unrelated telemetry.
- Govern context reuse across workflows Track where the same contextual dataset is reused in support, sales, marketing, and agent orchestration so you can review downstream exposure before it compounds.
What's in the full article
Collibra's full blog post covers the operational detail this post intentionally leaves for the source:
- How the context lifecycle maps to collection, architecture, management, and governance in enterprise environments
- Why context density is different from context volume, including where noise and latency start to outweigh usefulness
- How to think about enterprise memory as a cross-functional asset rather than a model-specific feature
- The article's framing of context as a sovereign layer that should not be locked to a single reasoning engine
👉 Read Collibra's analysis of why context engineering is becoming the enterprise standard →
Context engineering and enterprise memory: what IAM teams should notice?
Explore further
25/06/2026 4:47 am
Context is becoming the new authorization boundary. The article is right that model capability is commoditising, but the deeper governance shift is that decision quality now depends on which identities can assemble context, not just which identities can call a model. In practice, that means retrieval privileges, data joins, and orchestration rights are part of the access model. Practitioners should treat context assembly as a governed entitlement, not an implementation detail.
A few things that frame the scale:
- 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.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: How can organisations tell if context governance is working?
A: Context governance is working when teams can answer who supplied the context, which identity requested it, what was reused downstream, and whether the bundle was truly necessary. If those questions cannot be answered consistently, the programme has observability gaps and the context layer is not under control.
👉 Read our full editorial: Context engineering is the new enterprise control plane
