Because it adds more subjects, more delivery paths, and more policy decisions around the same business content. When context can be requested by humans, workloads, and AI agents, the access model must handle delegation, discovery, and consumption accountability at the same time.
Why the context economy turns identity from a setup task into an ongoing control problem
The risk rises because context is no longer a static document or a single app permission. It becomes something requested, assembled, shared, and consumed by multiple actors over time, which means identity decisions now shape who can discover it, retrieve it, delegate access to it, and use it without losing accountability.
That changes the governance burden in two ways. First, the same content may need different access paths for people, workloads, and AI agents. Second, the organisation has to keep policy, ownership, and approval logic aligned as context moves across systems instead of sitting behind one well-defined boundary.
When that happens, identity governance stops being about a single account review and starts becoming about controlling the relationship between subject, purpose, and delivery path. A context object may be harmless in isolation, but once it can be requested at scale, the access model must explain identity and access governance basics across authentication, authorization, and entitlement management.
Where the governance load comes from
The first source of risk is multiplicity. More subjects means more identities to classify, more entitlements to provision, and more lifecycle states to track. If a human can request context, a workload can fetch it, and an agent can consume it, the same governance policy must distinguish among delegated access, direct access, and machine-mediated access without flattening them into one control.
The second source is delivery-path sprawl. Context is often pulled through APIs, chat interfaces, retrieval layers, or workflow tools, which creates more places for policy drift, overbroad access, and inconsistent revocation. That is why lifecycle control matters: the same content may be correctly governed at creation time and still become risky later if the consuming identity changes, the workflow expands, or the permission is never removed.
The third source is accountability gaps. Context economy systems make reuse attractive, but reuse blurs ownership unless teams can answer who approved the access, who consumed the content, and whether the consumption stayed within purpose. Identity governance has to be able to prove not only that access existed, but that access remained appropriate as the request moved between actors and channels.
What breaks first when context becomes shareable
The most common failure is privilege creep, especially where access is granted for convenience and then inherited by adjacent use cases. Another is entitlement ambiguity, where a role or policy was designed for a person but is later reused for a workload or agent without revisiting the underlying trust assumptions. Over time, the problem becomes harder to see because the access path looks normal even when the governance logic is no longer accurate.
A practical way to frame this is through the lifecycle controls that keep identities and entitlements bounded. NHIMG’s NHI lifecycle management guidance is useful here because the same patterns that govern provisioning, rotation, and offboarding apply when context is delivered through non-human consumers. The governance question is whether every requester still has a valid business reason and whether every pathway has a matching end state.
That is also why review controls matter more in a context economy than they do in a simple access model. Access reviews and certification become a control over actual usage paths, not just over nominal membership, because stale access to context can survive long after the business need has changed.
Risk and Threat Considerations
Context sharing increases exposure because the same content can be reached through more identities, more integrations, and more automation layers. The result is a larger attack surface for misuse, accidental overexposure, and privileged reuse, especially when teams treat context delivery as a convenience feature instead of a governed access pathway.
Failure mechanism: A requester gains legitimate access to context once, then the access is reused, propagated, or inherited into broader workflows without revalidation of purpose, scope, or revocation.
Impact: Sensitive business context can be disclosed beyond its intended audience, and the organisation may lose the ability to prove who accessed what, through which path, and under which policy decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Context delivery depends on controlling lifecycle and reuse of access material. |
| AC-6 — Least Privilege | The topic centers on limiting who can consume shared context and how broadly. | |
| AU-6 — Audit Review, Analysis, and Reporting | The question hinges on accountability for who accessed context and through which path. | |
| Recommendation — Rotate and revoke access material on a defined lifecycle before shared context paths accumulate stale privilege. Constrain context access to the minimum set of identities and pathways needed for the task. Log and review context access so consumption can be attributed and investigated. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared context requires defined access rules across people, workloads, and agents. |
| A.5.16 — Identity management | The issue is driven by more subjects needing governed identities and ownership. | |
| Recommendation — Define and enforce access rules for context delivery channels and consumers. Assign and maintain ownership for every identity that can request or consume context. | ||
Practitioner Guidance
What to prioritise: Treat context like a governed resource, not a passive artifact. Define the identity types that may request it, the delivery channels they may use, and the revocation point for each channel before expanding distribution.
What to verify: Check that every context path has an owner, a purpose, an expiry or review trigger, and a way to distinguish direct human consumption from delegated or automated consumption. If any of those are missing, the control is not ready for scale.
Common mistake: Teams often secure the source content but ignore the delivery layer. In practice, governance fails when the same context is made reachable through new workflows faster than approvals, recertification, and offboarding can keep up.
Practitioner takeaway: The context economy increases identity governance risk because it multiplies not just access, but the number of policy decisions needed to keep access attributable, bounded, and removable.