Agents that only watch: building the supply side of context

At a glance

What this is: This is a blog post arguing that enterprise AI security agents need dedicated background systems to continuously build context, not just task agents that retrieve it on demand.

Why it matters: It matters because AI agents with broad system access can only be governed safely when their context, entitlements, and decision inputs are continuously maintained across identity, data, and operational sources.

👉 Read Cogent's analysis of supply-side agents and context engineering

Context

Enterprise AI agents often connect to many internal systems, but access without environmental understanding creates governance risk. The primary gap is not whether an agent can retrieve data, but whether it can interpret which data, relationships, and changes actually matter in the current operating context. For NHI governance, that is the difference between a connected workload and a controllable one.

Cogent’s argument is that context must be built continuously, not only assembled at prompt time. That intersects directly with NHI, because agents themselves are non-human identities with credentials, permissions, and runtime behaviour that need lifecycle control. It also intersects with IAM and PAM, since the quality of downstream authorisation depends on the quality of the identity and access context feeding the agent.

Key questions

Q: How should security teams govern background AI agents that only observe systems?

A: Treat observing agents as governed non-human identities with bounded read access, separate ownership, and explicit source approvals. Their job is to build context, but that context becomes trusted input for other systems, so observation rights, validation rules, and revocation paths must be defined before deployment.

Q: Why do AI agents struggle in fragmented enterprise environments?

A: They often have access to many tools but no durable understanding of what matters across those tools. In fragmented environments, the useful context is spread across inventories, logs, and human knowledge, so agents need sustained correlation and validation rather than isolated retrieval at prompt time.

Q: What breaks when context stores are not validated before reuse?

A: Bad mappings, stale ownership, and incorrect dependency assumptions can become trusted inputs for every downstream agent. Once that happens, one error scales into repeated misprioritisation, unsafe automation, or missed incidents because the system is acting on false context.

Q: How do organisations know if agent context is actually working?

A: Look for lower rework, fewer false priorities, and better alignment between what agents surface and what operators confirm as real. If agents keep rediscovering the same environment or repeatedly misclassify critical issues, the context layer is not yet reliable enough for governance use.

Technical breakdown

Why runtime retrieval fails without a context supply chain

Retrieval-Augmented Generation and other runtime optimisation patterns assume the right information already exists somewhere to be fetched at inference time. In fragmented enterprise environments, that assumption breaks down because the meaningful context is distributed across inventories, logs, cloud controls, and operational knowledge that are not aligned by default. The result is an agent that can query many systems but still lacks the connective tissue needed to decide what matters. Background context building shifts work upstream so the agent starts with a usable operating picture rather than rediscovering the environment on every run.

Practical implication: treat context as a governed input to agent authorisation, not just a prompt assembly problem.

How supply-side agents build persistent organisational memory

The supply-side model uses dedicated background agents to observe systems continuously, correlate changes, and populate layered context stores. Hot context serves fast summaries, cold context preserves structured detail, and deep storage keeps the full reasoning trail for audit and review. A validation layer checks proposed updates before commitment, which matters because context itself becomes a security asset. If the mapping between services, owners, and dependencies is wrong, downstream task agents inherit that error at scale.

Practical implication: implement review and validation controls for context stores the same way you would for sensitive configuration data.

Why background agents change the identity risk profile of AI systems

An agent that watches but does not act is still an identity-bearing system because it holds credentials, queries protected data, and builds an operational picture that other agents will trust. That makes the context layer part of the attack surface. If an attacker can poison the background agent’s observations, manipulate its source trust, or over-extend its access, the resulting context becomes a false authority for every downstream task agent. In identity terms, this is a governance problem about who can observe, enrich, and publish trusted machine context.

Practical implication: bind observation rights, data access, and publish permissions to explicit machine identity controls and least privilege.

Threat narrative

Attacker objective: The attacker wants to corrupt the context layer so that other agents make consistently wrong decisions while appearing to rely on trusted internal intelligence.

1. Entry occurs when a background or supply-side agent is given broad read access across internal systems to build context.
2. Escalation happens if that agent can write trusted context back into shared stores without strong validation and source trust checks.
3. Impact follows when poisoned or incorrect context is reused by downstream task agents, causing misclassification, bad prioritisation, or unsafe actions at scale.

NHI Mgmt Group analysis

Context is becoming a governed security asset, not a convenience layer. Enterprises are now asking AI systems to build understanding across fragmented environments, which means the context layer starts to behave like an identity-dependent control plane. If that layer is wrong, every downstream agent inherits the error. The governance implication is simple: context quality must be measured, reviewed, and bounded like any other privileged system input.

Supply-side agents create a new class of non-human identity risk. These agents do not just consume access, they continuously exercise it to observe, correlate, and publish trusted context. That places them squarely in NHI governance territory because their credentials, source permissions, and output authority all need lifecycle control. The practical conclusion is that machine identity policy now has to cover observers as well as actors.

Persistent context exposes a verification trust gap. In fragmented enterprises, the danger is not only missing data, but stale or incorrect data becoming authoritative because it was curated by automation. This is a named failure mode worth tracking because it shifts risk from a single bad query to a compounding trust problem across the agent stack. Practitioners should treat validation, source attestation, and change review as first-class controls.

Background agents will amplify existing IAM and PAM weaknesses if they are layered on top of weak entitlements. The article’s model only works when the underlying access model is already disciplined, because broad read access without clear separation of observation and action creates an easy path to misuse. This is where identity programmes need to re-evaluate workload entitlements, service ownership, and escalation boundaries.

The market is moving from prompt engineering toward context governance. That shift matters because the competitive edge in enterprise AI security will increasingly come from how well systems maintain trustworthy context over time, not just how well they answer in the moment. For practitioners, the implication is to prioritise controls that make context auditable, attributable, and revocable.

What this signals

Context governance is becoming a programme-level control issue, not just an AI engineering concern. As agents start building and consuming shared context, security teams will need to decide which context sources are authoritative, which are reviewable, and which are never reusable outside a narrow workflow. That is especially relevant where static vs dynamic secrets determine whether machine context can be revoked quickly enough to matter.

The emerging failure mode is stale context masquerading as operational truth. Once that happens, incident response, access decisions, and prioritisation all begin from a false starting point. Practitioners should expect more pressure to align AI observability with machine identity controls, source validation, and change management.

The practical test is whether your agent stack can explain where its context came from, who approved it, and how quickly it can be withdrawn. If the answer is unclear, the programme has a governance gap even if the underlying model performance looks strong.

For practitioners

• Define machine identities for background agents Assign each observing agent a distinct identity, scoped read permissions, and explicit source boundaries so context collection is separable from task execution. This avoids collapsing every agent into one shared trust domain and makes revocation possible when a single source or workflow misbehaves.
• Validate context before it becomes shared truth Route proposed context changes through a review layer that checks source agreement, freshness, and conflict handling before publication to downstream agents. This is the control that prevents one poisoned observation from becoming a systemic error.
• Separate observation rights from action rights Ensure agents that gather context cannot also execute privileged changes in the same identity context. The best boundary is between read-only enrichment and any workflow that can alter configuration, tickets, or security posture.
• Track stale context as an operational risk Measure how often environment, dependency, or ownership data changes after it has been cached, and treat drift as a governance signal rather than a tuning issue. If the environment changes daily, stale context is a recurring control failure.

Key takeaways

• Enterprise AI agents are only as governable as the context they inherit, and that context now needs explicit controls.
• Background agents expand the NHI attack surface because they collect and publish trusted machine context, not just data.
• The organisations that win here will validate context, separate observation from action, and treat machine identity as part of the context layer.

Key terms

• Supply-side Agent: A supply-side agent is a background AI system whose job is to observe, correlate, and enrich context for other agents rather than perform end-user tasks. It behaves like a machine analyst, building trusted background knowledge that downstream workflows consume and reuse.
• Contextual layer: An intermediate governance layer that adds visibility and control across systems not fully covered by the primary IGA stack. It matters when organisations need immediate insight into drift, exceptions, and coverage gaps while they work toward a more mature governance architecture.
• Activation Trust Gap: The activation trust gap is the difference between trusting data because it is protected and governing it because it is being reused. It appears when organisations move data from backup or archival systems into AI pipelines without reapplying access, sensitivity, and consumer controls.

What's in the full article

Cogent's full blog covers the operational detail this post intentionally leaves for the source:

• How the context router assembles hot, cold, deep, and raw stores into task-specific packages
• The validation queue design that checks proposed context updates before they are committed
• The role of filesystem-backed storage in preserving reasoning trails and auditability
• The practical division between task agents, supply-side agents, and human review

👉 Cogent's full post covers the context architecture, storage tiers, and validation flow in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader operational models their programmes depend on.