A worked example: AI Risk Disposition for a Copilot Studio procurement agent
Every section of the disposition filled in with real content — decision, rationale, required controls, residual risk acceptance, evidence gaps, re-assessment triggers, and sign-off log. The same system used in the Drel demo dossier.
The first piece in this series described what an AI Risk Disposition contains, section by section. This piece shows one. Every section is filled in with real content from a real assessed system — a Copilot Studio agent built to assist a procurement team with supplier analysis.
The system is representative of the AI features that are actually reaching AI Committees right now: a Microsoft-platform agent, RAG over internal documents, a small set of tools, and a user population that is internal but not technical. The risks are real. The controls are specific. The disposition is the artifact the committee signed.
The system
A Copilot Studio agent deployed to assist a 12-person procurement team with supplier analysis. The agent can look up supplier information, retrieve relevant internal policy excerpts, and draft (but not send) supplier communications. All outputs require human review before any action is taken.
System under assessment — Copilot Studio procurement agent
| Model | GPT-4o via Azure OpenAI | EU data residency |
| Orchestrator | Copilot Studio (Power Platform) | Microsoft-managed |
| Retrieval | SharePoint + internal policy docs | Non-confidential excerpts only |
| Tools | Supplier lookup (read-only), draft email (no send) | No write access to ERP |
| Users | Procurement team (12 people) | Internal only, no external access |
| Autonomy level | Restricted pilot | Human approval required before any supplier communication |
The system was submitted for AI Committee review before the pilot expansion from 3 to 12 users. The committee's question was: can this system operate at this scale, with these tools, under these conditions — and what would need to change before it could do more?
Section 1: The decision
The disposition opens with a single, unambiguous decision state. For this system, the decision was:
Decision
Restricted pilot — approved for the procurement team (12 users) under the conditions stated in this disposition.
“Restricted pilot” is a specific state, not a hedge. It means: the system may operate, but inside a stated boundary. The path to full production is itself a list of conditions — the controls in Section 3. Until those controls are verified, the system stays in restricted pilot.
Section 2: The rationale
The rationale is two or three sentences. It names the headline risk, the headline mitigation, and the headline residual exposure. Here is the rationale from this disposition:
The procurement agent may operate in a restricted pilot scoped to non-binding supplier analysis (no contract approvals, no email send). The agent's retrieval surface is limited to non-confidential policy excerpts, and high-value decisions require a human approval boundary. Residual exposure to prompt injection from supplier-submitted documents is accepted on the condition that the boundary is enforced at the model gateway, not at the UI.
That paragraph names the scope (non-binding supplier analysis), the dominant mitigation (boundary at the gateway), and the residual exposure that everyone has consciously agreed to live with. A reader who was not in the committee meeting can understand the decision and its basis.
Section 3: Required controls
Six controls, grouped by lifecycle gate. Each control has an owner role (not a person — people change roles), a gate, and a verification method that says how we will know the control is working.
Required controls — procurement agent (restricted pilot disposition)
| ID | Control | Owner role | Gate | Verification |
|---|---|---|---|---|
| C-01 | Human approval boundary enforced at model gateway before any supplier communication is sent | Security Architecture | Before pilot | Architecture review + boundary test with mock send attempt |
| C-02 | Retrieval scoped to non-confidential policy excerpts only — no access to contract data or pricing | Data Engineering | Before pilot | Access control test: query for contract data returns empty |
| C-03 | Prompt injection red-team exercise covering supplier-submitted document inputs | Security Architecture | Before production | Red-team report with findings and mitigations attached |
| C-04 | Tool call log retained for 90 days with full invocation detail (tool id, parameters, user session) | Platform Engineering | Before production | Log sample showing all required fields populated |
| C-05 | Quarterly review of retrieval scope against approved data classification | AI Governance | Ongoing | Review schedule + last-run report |
| C-06 | Re-assessment triggered if human approval boundary is removed or scope expanded beyond supplier analysis | AI Governance | Ongoing | Trigger registered in disposition; re-review process documented |
The verification method is the field that most control lists omit. “Implemented” without a verification method is a trust-me. C-02 says “access control test: query for contract data returns empty” — that is a test that can be run, recorded, and attached to the disposition as evidence.
Section 4: Residual risk acceptance
Every disposition has residual risk. The question is whether it has been named, by whom, and on what condition. From this disposition:
Residual risk acceptance
Risk accepted
Prompt injection via supplier-submitted documents. The agent processes documents provided by external parties. Despite retrieval scoping, a sufficiently crafted document could influence the agent's output.
Accepted by
Head of Procurement (business owner) + Security Architecture (technical owner)
Acceptance condition
Accepted on condition that C-01 (human approval boundary at model gateway) remains in place and verified. If C-01 is removed or bypassed, this acceptance is invalidated and the system must be re-reviewed.
The acceptance condition is the critical field. It converts a vague “risk accepted” into a conditional statement: the risk is accepted if and only if C-01 is in place. If C-01 is removed, the acceptance is automatically invalidated — no committee meeting required to recognise that the risk profile has changed.
Section 5: Evidence gaps
Evidence gaps are what we do not yet know at the time of the disposition. They are not failures — they are honest acknowledgements that some controls have not yet been verified, and a commitment to close them.
Evidence gaps at time of disposition
Red-team exercise (C-03) not yet completed
Scheduled for Week 3 of pilot. Results to be attached to disposition before production gate review.
Owner: Security Architecture
Tool call log format not yet confirmed to include all required fields
Platform Engineering to provide log sample by end of Week 1. Disposition to be updated with confirmation.
Owner: Platform Engineering
A disposition with evidence gaps is not a weak disposition — it is an honest one. The alternative is a disposition that claims all controls are verified when they are not. That is the disposition that fails under audit.
Section 6: Re-assessment triggers
Re-assessment triggers are the mechanism that makes the disposition a living document rather than a one-time approval. Five triggers were registered for this system:
Re-assessment triggers — procurement agent
| T-01 | Human approval boundary removed or bypassed | Removes the primary control against autonomous supplier communication |
| T-02 | Email send tool added to the agent's tool manifest | Expands the blast radius from draft to send — fundamentally different risk profile |
| T-03 | Retrieval scope expanded to include contract data, pricing, or supplier financials | Increases data exfiltration risk and changes the data classification of the system |
| T-04 | User population expanded beyond the procurement team | Changes the threat model for misuse and the scope of potential harm |
| T-05 | Model changed to a different provider or version with different capability profile | May change the system's susceptibility to prompt injection or goal manipulation |
T-02 is the most important trigger for this system. Adding an email send tool would change the risk profile fundamentally — from a system that drafts to a system that acts. That change requires a new disposition, not an amendment to the existing one.
Section 7: Sign-off log
The sign-off log records who approved the disposition, in what role, and when. For this system, four roles were required:
| Role | Status | Comment |
|---|---|---|
| Security Architecture | Approved | Controls C-01 and C-02 verified. C-03 pending — see evidence gap. |
| AI Governance | Approved | Scope and triggers reviewed. Restricted pilot boundary accepted. |
| Business Owner (Head of Procurement) | Approved | Residual risk accepted under stated condition. |
| DPO | Approved | No personal data in retrieval scope. DPIA not required at this stage. |
The sign-off log is not a formality. It is the record that answers “who approved this, and what did they know when they approved it?” — the question that comes up in every post-incident review and every procurement due-diligence process.
What changed after the review
The review surfaced two things the product team had not considered:
- The approval boundary was at the UI, not the gateway.The product team had implemented a “confirm before send” button in the Copilot Studio interface. Security Architecture pointed out that this boundary could be bypassed if the agent was accessed via API rather than the UI. C-01 was rewritten to require the boundary at the model gateway. This was a two-day engineering change that would not have been caught without the review.
- The retrieval scope included a SharePoint library with contract summaries. The product team believed this library contained only policy documents. Data Engineering confirmed it also contained contract summaries with pricing information. The library was removed from the retrieval scope before the pilot started.
Neither of these issues would have appeared in a traditional threat model. The first is an implementation detail that only surfaces when you ask “where exactly is the boundary enforced?” The second is a data classification issue that only surfaces when you ask “what is actually in the retrieval scope?” Both are questions the disposition process forces.
Read the full disposition
The full disposition for this system — including the complete threat register, all control evidence, and the framework mapping to OWASP Agentic Top 10, ISO 42001, and EU AI Act Article 9 — is available in the Drel demo dossier. It is ungated and downloadable as Markdown.
If you want to run the same process on your own system, the free trial includes one full assessment end-to-end.
Run this process on your own AI system
Bring one AI system your committee needs to review. Drel walks through the same seven sections — decision, rationale, controls, residual risk, evidence gaps, triggers, sign-off — and produces a disposition memo your committee can actually use.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.