How do organisations keep multi-agent workflows secure without exposing raw data in prompts?

Why This Matters for Security Teams

Multi-agent workflows change the risk model because each agent can become both a decision point and a data access path. If raw customer records, secrets, or operational context are copied into prompts, those values can persist in logs, be exposed to downstream tools, or be reused in ways the original workflow never intended. That is why secure design focuses on minimising what enters the prompt and constraining what each agent can ask for. Guidance from the NIST AI Risk Management Framework is useful here because it emphasises governance, measurement, and controlled deployment rather than assuming the model boundary is the security boundary.

The practical issue is not only leakage. Untrusted prompt content can also shape agent behaviour, trigger unintended tool use, or steer one agent into disclosing data to another. In agentic AI, the trust boundary must sit around identity, policy, and retrieval, not just model output. Security teams that treat prompts as a safe transport layer usually discover too late that the workflow is effectively a distributed data-sharing system with weak authorization if it is not designed carefully. In practice, many security teams encounter prompt exposure only after a downstream log, plugin, or support trace has already preserved the sensitive data rather than through intentional disclosure review.

How It Works in Practice

The secure pattern is to keep state in systems of record and let agents operate through narrow, authenticated interfaces. Each agent should receive only the minimum context needed to complete its task, ideally as structured fields rather than free text. A request for account status, for example, should return an approved summary object, not a full record dump. This reduces the chance that secrets, personal data, or internal reasoning details are copied into the conversation layer.

Practical controls usually include:

• Using structured schemas for inputs and outputs so agents cannot invent new fields or smuggle data into prompts.
• Placing authorization checks at the API or service layer, not inside the prompt.
• Issuing short-lived, scoped credentials so one agent cannot reuse access across tasks.
• Logging only necessary metadata, with redaction before any prompt, trace, or transcript is stored.
• Separating retrieval from generation so the model can reference approved results without seeing the full underlying dataset.

Threat modelling should also cover prompt injection, tool misuse, and data exfiltration through chained agents. The OWASP Top 10 for Agentic Applications 2026 is particularly relevant because it captures failure modes around excessive agency, indirect prompt injection, and unsafe tool invocation. For more structured control mapping, the CSA MAESTRO agentic AI threat modelling framework helps teams map trust boundaries across planning, retrieval, execution, and memory.

In mature setups, the agent becomes a controlled client of business services, not a container for business data. These controls tend to break down when teams route unreviewed third-party tools, legacy APIs, or shared memory stores into the workflow because the authorization model becomes inconsistent across steps.

Common Variations and Edge Cases

Tighter controls often increase orchestration overhead, requiring organisations to balance reduced data exposure against latency, integration effort, and developer friction. That tradeoff is real, especially when workflows span multiple business units or legacy systems.

Best practice is evolving for long-lived agent memory, shared context stores, and cross-agent delegation. There is no universal standard for this yet, so organisations should treat persistent memory as sensitive infrastructure and apply the same discipline used for production data stores. In higher-risk environments, the safest option is to avoid storing raw content in memory at all and instead store references, summaries, or policy-approved embeddings with strict retention rules.

Another edge case is regulated or high-impact use, where prompt content may indirectly reveal personal data, financial records, or security telemetry. In those situations, the NIST AI Risk Management Framework and NIST SP 800-53 Rev 5 Security and Privacy Controls support stronger governance around access control, auditing, and information flow. Where adversarial behaviour is a concern, MITRE ATLAS adversarial AI threat matrix is useful for planning detections around manipulation, evasion, and extraction attempts.

For organisations building or buying agentic systems, the right question is not how much data the prompt can hold, but how little it needs to hold for the workflow to remain reliable. That design choice usually determines whether secure automation is scalable or brittle.

Related resources from NHI Mgmt Group

• How do organisations keep delegation chains accountable in multi-agent workflows?
• How should organisations secure mobile identity verification without over-sharing personal data?
• How should organisations secure document approval workflows without slowing them down?
• How should organisations verify data subject requests without exposing personal data?