How can organisations reduce risk when agents handle large volumes of data?

Move high-volume work into sub-agents that operate in separate contexts, then return only the result needed by the main workflow. That reduces memory accumulation, keeps the primary conversation cleaner, and limits how much sensitive intermediate data is carried forward across the session.

Why This Matters for Security Teams

When agents process large volumes of data, the risk is not just exposure of one dataset. The larger issue is how much sensitive context accumulates across prompts, tool calls, retrieval steps, and agent handoffs. That increases the chance of over-collection, cross-contamination between tasks, and unintended disclosure in logs, traces, or downstream outputs. Current guidance from the NIST AI Risk Management Framework supports limiting unnecessary data exposure and validating outputs against the intended use case.

For security teams, the practical question is not whether an agent can process more data, but whether it should keep that data in one place long enough to create a durable risk. Segmentation through sub-agents helps reduce the blast radius of mistakes, makes policy enforcement easier, and creates cleaner review points for human oversight. It also supports better separation of duties when different data classes, privileges, or tool permissions are involved.

In practice, many security teams encounter agent data leakage only after an over-broad workflow has already copied sensitive content into multiple contexts, rather than through intentional containment design.

How It Works in Practice

The core idea is to break a large workflow into bounded tasks and assign each task to a sub-agent with only the data, tools, and time horizon it actually needs. The main agent should act more like an orchestrator than a memory vault. That means passing in scoped inputs, collecting a narrow result, and discarding intermediate material wherever possible. This is especially important when the workflow touches customer records, internal tickets, source code, incident data, or regulated content.

Operationally, strong implementations use explicit data tiers and context boundaries. A common pattern is to classify the job first, then route it to a sub-agent with a minimal prompt, restricted retrieval scope, and narrowly defined output schema. Logging should capture control signals and decision points, not raw sensitive payloads. Human review is most effective at the handoff points, where the system can validate whether the result is complete without exposing the entire working set.

• Limit each sub-agent to one business function or one data domain.
• Pass only the fields required to complete the task.
• Use output filtering so the main workflow receives summaries, not raw intermediates.
• Separate retrieval indices, tool permissions, and audit trails by sensitivity level.
• Test for prompt injection, data exfiltration, and unsafe tool chaining using the OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix.

This pattern works best when sub-agents can be isolated by identity, permissions, and retrieval boundaries; these controls tend to break down in monolithic agent stacks that reuse one shared context for every tool call because sensitive intermediate data becomes hard to separate from ordinary working memory.

Common Variations and Edge Cases

Tighter context boundaries often increase orchestration overhead, requiring organisations to balance reduced exposure against added complexity and latency. That tradeoff is real, especially in environments where agents need to assemble answers from many systems or handle cases that do not fit cleanly into predefined workflows.

Best practice is evolving for mixed-trust deployments. For example, there is no universal standard for how much intermediate reasoning should be retained, but current guidance suggests retaining only what is needed for auditability and safety review. In highly regulated settings, the decision may also depend on whether the data is personal, financial, or part of a critical service workflow. The CSA MAESTRO agentic AI threat modeling framework is useful where teams need to reason about multi-agent privilege and cross-boundary risk.

Edge cases arise when sub-agents share retrieval sources, when outputs are later merged without validation, or when a single agent is allowed to call external tools with broad authority. In those environments, simple task splitting is not enough. Organisations should pair segmentation with explicit output validation, access scoping, and monitoring aligned to the NIST Cybersecurity Framework 2.0. Where agent behavior can influence security events, the response model should also reflect lessons from the Anthropic report on AI-orchestrated cyber operations, which shows how quickly tool-enabled autonomy can amplify misuse.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of data exfiltration through AI chat sessions?
• How can organisations reduce risk from shadow AI agents already inside the enterprise?
• How can organisations reduce risk from AI agents processing hidden instructions?
• How do IAM teams reduce risk when agents query data through MCP?