The state and data associated with a specific agent job, including messages, artefacts, and intermediate outputs. In A2A-style systems, context can become an exposure path if it is shared too broadly, reused across sessions, or allowed to carry sensitive data without strong isolation.
What Task Context Is
Task context is the working state tied to one specific agent job. It usually includes the messages, artefacts, intermediate outputs, and other execution data the job needs to continue. In agentic systems, that state becomes security-sensitive when it is reused too broadly, copied across sessions, or allowed to carry information that should have stayed isolated.
Why Task Context Matters
Task context is not just a convenience layer for continuity. It is the memory and working substrate that lets an agent preserve intent, carry forward partial results, and coordinate multi-step work. Because it can accumulate prompts, tool outputs, files, and references, it often contains more than the user intended to expose if boundaries are not tightly enforced.
The security significance is that context can function as an exposure path rather than a passive log. If a later job can read an earlier job’s context, or if a shared context object outlives the task that created it, sensitive content can bleed between workflows, tenants, or users. That is especially risky when context includes tokens, embedded credentials, internal instructions, or confidential artefacts.
How Task Context Is Structured and Used
Operationally, task context usually acts like a scoped container for the agent’s running state. It can hold the conversation history, tool results, extracted facts, draft outputs, and any intermediate reasoning artefacts that the system chooses to persist. The exact shape varies by platform, but the core idea is the same: it is the job’s temporary working memory.
Good design keeps the context narrowly bound to a task identity, a session boundary, and a clear retention window. That makes it possible to resume work, audit execution, or hand off between components without turning the context into a shared bucket. When that scoping is weak, context becomes a convenient place for accidental reuse, cross-request contamination, and disclosure.
Security Implications of Shared or Persistent Context
Because task context can carry sensitive material, its controls affect confidentiality, integrity, and trust. A context store that is over-permissive can expose prior user data, stale tool outputs, or hidden system instructions to the wrong job. A context store that is too sticky can also preserve outdated state, causing an agent to act on information that no longer reflects the current task.
Context persistence is useful, but it should be intentional. If a platform preserves artefacts for replay, debugging, or compliance, it needs explicit isolation, access control, and data minimisation. Otherwise, the same mechanism that improves continuity can also preserve secrets, widen blast radius, and make later compromise more valuable to an attacker.
For a broader threat view of agent-state abuse, MITRE ATLAS adversarial AI threat matrix is useful for mapping context poisoning, memory manipulation, and related agent techniques. Where the context is carried through protocol-mediated agent systems, the Model Context Protocol: Authorization specification shows how token handling and audience binding should constrain access paths. For security programmes that need a broader control lens, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control families most relevant to access, audit, and configuration discipline around stored task state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATLAS | Adversarial AI Threat Techniques | Context poisoning and memory manipulation map directly to task-context abuse in agentic systems. |
| Recommendation — Map task-state abuse to ATLAS techniques and monitor for poisoned or cross-task context reuse. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Task context should be accessible only to the job and services that need it. |
| AU-2 — Event Logging | Task context benefits from auditability when sessions, artefacts, and state changes matter. | |
| SC-28 — Protection of Information at Rest | Persisted task context may store sensitive artefacts that need storage-layer protection. | |
| Recommendation — Restrict task-context access to the minimum set of users and services that need it. Log task-context access and mutations so misuse and leakage can be investigated. Encrypt persisted task context and protect stored artefacts against disclosure. | ||
Related resources from NHI Mgmt Group
- What breaks when task IDs are not bound to the original identity context?
- What do teams get wrong when they connect multiple AI agents without shared context or task boundaries?
- What do security teams get wrong when they rely on alerts without task-specific context?
- What breaks when cloud access is built around static roles instead of live task context?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org