Yes. Support approval confirms the business purpose, but attachment approval must confirm the specific material and destination. Keeping those decisions separate prevents a legitimate request from becoming blanket permission for every file the agent later packages. That separation is especially important when the archive may contain restricted excerpts or sensitive operational data.
Why separate support approval from attachment approval?
Support approval answers a different question from attachment approval. The first establishes that the workflow itself has a valid business need, while the second checks whether the specific file set, archive contents and delivery target are acceptable. In AI workflows, that distinction matters because the agent can assemble new material after the business request is approved.
When those approvals are collapsed, teams often create accidental blanket permission. A reviewer may intend to approve one report or one response pack, but the workflow later bundles in related notes, exports or excerpts that were never individually assessed. Separate approvals preserve a clear boundary between “this task is allowed” and “this exact payload may leave the system.”
That separation also makes governance simpler. Business sponsors can validate the use case, while a second control owner can judge data sensitivity, audience, retention and external exposure. AI Governance Guide is useful here because the control problem is not only model risk, it is also approval design, role clarity and decision scope.
What should attachment approval verify in practice?
Attachment approval should be specific enough to answer what is being released, to whom and under what conditions. Practitioners should treat the payload as the control object, not the conversation that led to it. That means reviewing the material content, the destination, any redactions or exclusions, and whether the attachment changes the risk profile compared with the original request.
This is especially important for mixed archives. A file bundle may combine routine material with restricted excerpts, operational runbooks, customer data, internal commentary or credentials-adjacent artefacts. The approval decision should therefore be tied to the final rendered package, not a generic class of output. If the archive changes, the approval should be re-evaluated.
Security Policy Framework Guide fits this control pattern because approval scope, exception handling and review ownership need to be explicit rather than implied. In practice, the stronger the workflow’s ability to generate or assemble content dynamically, the more valuable that policy clarity becomes.
Attachment approval should also confirm whether the destination is appropriate for the material. Internal distribution, external sharing and automated routing are not equivalent risk states. A file that is acceptable for a limited internal audience may become inappropriate once the workflow packages it for a broader mailbox, ticket, shared drive or downstream agent.
How should teams prevent approval drift in AI workflows?
Approval drift happens when a control designed for one decision starts covering later decisions by habit. In AI workflows, the common failure is to let a request-level approval stand in for content-level approval, or to let a human’s initial yes become a standing permission for the agent’s future packaging choices. That is how a narrow business task turns into broad data movement.
The practical fix is to make each approval step answer one question only. Support approval should confirm the request is legitimate and within programme scope. Attachment approval should confirm the concrete output is safe to release in its final form. If the workflow can add, combine or transform material after support approval, the attachment decision cannot be assumed.
Privileged Identity Management (PIM) Guide is relevant because the same governance logic applies to time-bound authority: approval should be narrow, activatable and reviewable, not silently expanded into a standing entitlement. The underlying lesson is that scope matters more than convenience.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access control | Approval scope and destination control who may receive the final attachment. |
| Recommendation — Define release approval boundaries so only authorised recipients can receive the final package. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Separate approvals limit the agent's authority to only the specific release that was reviewed. |
| AU-6 — Audit Review, Analysis, and Reporting | Two-step approval creates auditable evidence for why the request and the attachment were both accepted. | |
| Recommendation — Constrain workflow authority to the minimum release needed for the approved package. Log both approval decisions so reviewers can reconstruct the purpose and payload authorisation. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | An agent can overstep when a request approval is mistaken for broader content authority. |
| Recommendation — Separate request approval from payload approval to prevent privilege expansion through workflow drift. | ||
| NIST AI RMF | GV.2 — Map context and impacts | This is a governance question about bounding decisions to the actual AI output and its consequences. |
| Recommendation — Define decision scope for the business request and the final artefact as separate governance checks. | ||
Practitioner Guidance
Decision rule: If the workflow can alter the payload after the business request is approved, require a separate attachment approval gate before release. If the final archive can differ from the originally requested artefact, treat the later approval as mandatory, not optional.
What to verify: Confirm that the approval record names the exact material class, destination and any exclusions or redactions. The reviewer should be able to tell, from the record alone, whether the released package could contain restricted excerpts or operationally sensitive content.
What good looks like: The workflow records two distinct decisions, one for purpose and one for payload, and the second decision is re-checked whenever the content set changes. That gives auditors and operators a clear line between justified use and authorised disclosure.
Practitioner takeaway: Separate approvals reduce ambiguity, but their real value is preventing dynamic assembly from becoming implicit data release. If the agent can change what is attached, the attachment decision must be a fresh control point.
Related resources from NHI Mgmt Group
- How should organisations secure high-value payment and approval workflows against AI-enabled fraud?
- When should organisations use approval gates in AI workflows?
- How should organisations verify AI agent actions in real time without creating brittle approval workflows?
- What breaks when organisations launch AI systems without formal risk assessment and approval workflows?