What breaks when an AI agent assembles restricted material after prompt review?

Why prompt review is not enough once the agent assembles the archive

The failure is a governance mismatch, not just a workflow bug. Prompt review can approve an intent, but the agent may still combine different files, destinations, or scopes into a new artifact that was never actually reviewed. If the final package is materially different, the original approval no longer governs the real action.

That distinction matters when an agent can collect restricted material from multiple sources, reshape it, and then hand off a completed archive or attachment. The control has to evaluate the final object, because the security decision is about what is leaving the environment, not only about what the prompt originally requested.

For that reason, treat assembly as a separate trust boundary. A prompt can be low risk on its face, while the assembled result becomes sensitive because of file selection, destination, embedded metadata, or hidden combinations that were not visible at review time.

What the second decision point has to evaluate

The second decision point should validate the specific files, the target destination, and the business purpose before the attachment, bundle, or export is completed. That means the review has to operate on the resolved output, not just the agent instruction, and it has to be able to block completion when the final contents exceed the approved scope.

When that control is designed well, it checks whether the archive contents still match the original business justification, whether each included item is permitted, and whether the recipient or destination is appropriate for the sensitivity of the data. It is the difference between approving a task and approving a concrete disclosure.

At this stage, the agent should also surface a human-readable summary of the exact contents and any changes made during assembly. If the final package cannot be expressed clearly enough for a reviewer to understand what is being sent, the workflow should not assume the earlier approval still stands.

How this failure shows up in practice

This pattern often appears when the agent has enough autonomy to gather related documents, export them to a shared folder, compress them, or attach them to a message without a fresh policy check. The user approved one request, but the agent used that approval to justify a broader or more sensitive final artifact.

It is especially risky when restricted material is assembled from multiple sources, because the individual pieces may each seem acceptable in isolation. The security issue emerges only after combination, when the archive creates a new disclosure surface that was never part of the original review.

AI Agent Authorisation Guide is useful here because it frames per-action decisions and human approval as separate from standing permission. The same principle applies to any workflow that can transform approved input into a more sensitive output.

AI Agent Observability, Audit and Incident Response Guide is relevant when you need to prove what the agent assembled, when it changed, and who approved the final action. Without that trail, it is hard to tell whether the failure was policy design, agent behaviour, or both.

Risk and Threat Considerations

When the approval is tied to the prompt instead of the final artifact, the control can be bypassed through harmless-looking instructions that later expand into a sensitive package. That creates a disclosure risk even if the original request looked legitimate, because the dangerous step happens after the review point.

Failure mechanism: The agent performs a second-stage assembly step that changes the object being governed, so the initial approval no longer matches the actual archive or attachment.

Impact: Restricted files can be combined, routed, or disclosed outside the intended scope, with loss of confidentiality, weak accountability, and a misleading audit trail that suggests the final output was reviewed when it was not.

Practitioner Guidance

What to verify: Require the policy decision to reference the concrete output, not just the task description. A valid review should confirm the exact file set, recipient, destination, and purpose that will exist at the moment of send or export.

Decision rule: If the agent can alter composition after approval, treat the workflow as two decisions, pre-assembly intent approval and final-content approval. If only one exists today, that is a control gap, not a minor process weakness.

Practitioner takeaway: The safest design is to assume the archive is a new security object, because once an agent can assemble content dynamically, the review must move from “what was asked” to “what is actually being released.”

Related resources from NHI Mgmt Group

• What breaks when organisations review AI agent access only at the prompt or workflow level?
• Why is single-provider AI agent governance not enough for enterprise security?
• What breaks when AI agent access is reviewed only after the fact?
• What breaks when IAM only logs AI agent activity after execution?