Who agreed to let the agent do that? Building a RAID log and decision log with an approver column

OWASP lists Excessive Agency among the LLM risks for 2025, under the code LLM06.

On client projects, this risk rarely surfaces in code review. It usually sits in a meeting: someone nods to let the agent write to the client’s systems, and nobody records the nod.

That is why FDEs need two documents that sound dull but can save a project: a RAID log and a decision log. When an incident happens, they answer three questions: what was foreseen, who accepted the risk, and why.

Both can be set up inside the project repo, provided they have one extra column kept separate from the owner: the approver, meaning the person with the authority to accept the risk.

What you will build, and what you need

The end result is a raid-log.md file and a decisions/ folder, with each decision in its own file. Markdown is a sensible choice: it can be reviewed through pull requests, it has a change history, and the client can read it without installing anything.

If the client insists on their own project management tool, simply keep the set of columns below.

The running example is a hypothetical project: an internal RAG chatbot that answers questions for the customer service department of an insurance company, plus a proposal to let an agent send email replies on its own. All roles and dates in the example are hypothetical.

You need three things: a repo that both the team and the client’s point of contact can read, a list of the people on the client side who have decision-making authority, and half an hour with the tech lead.

Step 1: build the four-part frame, with two columns that must not be merged

According to Process Street, a RAID log is a central repository for tracking risks, assumptions, issues and dependencies throughout a project.

In short: a risk is an event that could delay the project or make it miss its goals; an assumption is something taken to be true but not yet verified; a dependency is work that has to wait for other work or for an external factor; and an issue is something that has already happened.

All four sections sit in one file and share one set of columns, which makes filtering and cross-referencing easy later.

# RAID log — Customer service chatbot (example)

| ID | Type | Description | Impact | Owner | Approver | Status | Updated | Related decision |
|----|------|-------------|--------|-------|----------|--------|---------|------------------|

The Type column takes only one of four values: R, A, I or D. The owner is the person who has to do something about the item. The approver is the person with the authority to accept the risk or close the item. The two columns are separated deliberately: the FDE is often the owner, but rarely has the authority to accept risk on the client’s behalf.

The approver column also lines up with the NIST AI RMF. According to the framework’s Playbook, GOVERN 2 calls for accountability structures so that the right teams and individuals are empowered and responsible for managing AI risk. GOVERN 2.1 requires roles and responsibilities to be documented.

NIST released the framework on 26 January 2023, and adoption is only voluntary. Even so, when a client asks why the log needs this column, citing GOVERN is far more persuasive than “because the team felt it was needed”.

Check: ask yourself whether, if the FDE quit tomorrow, someone reading the log would know who is responsible for each row.

Step 2: write assumptions before risks

Picture the kickoff: the client asserts that the business documentation is in good shape and can simply be indexed. That is not yet a fact; it is an assumption. On a RAG project it is the first assumption worth verifying, because the chatbot can only answer as well as the documents it reads.

Writing assumptions before risks may look like the wrong order, but many risks grow out of an assumption that nobody has checked. Write it down first and you know what ground you are standing on.

| A-01 | A | Business documents are clean and current enough to serve as the RAG source | If false: chatbot answers using outdated procedures | FDE | Head of Customer Service | Not verified — due 2026-10-16 | 2026-10-09 | — |

Each assumption needs a way to verify it and a deadline. For instance, sample 20 documents and mark the outdated ones together with the head of customer service. If verification shows the assumption is wrong, do not delete the row. Create a new R or I row and point it back to A-01.

Check: every A row must say either “Not verified” with a deadline or “Verified” with a date. No row may simply say “OK”.

Step 3: use OWASP as a checklist for thinking up AI risks

When you sit down with the tech lead to list AI risks, the hardest part is the blank page: everyone knows the model can be wrong, but nobody can say where. Open the OWASP LLM Top 10 2025 list as a prompt. For the example project, three items are worth considering: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure and LLM06 Excessive Agency.

| R-01 | R | An employee without sufficient permissions asks the chatbot and receives policyholders' personal information (OWASP LLM02:2025) | Data leak; project could be halted | FDE | Client security representative | Open | 2026-10-09 | DEC-002 |
| R-02 | R | Agent sends an email with wrong content to a real customer (OWASP LLM06:2025) | Complaints, reputational damage | FDE | Customer Service Director | Open | 2026-10-09 | DEC-001 |
| R-03 | R | Content in source documents or questions skews model behaviour (OWASP LLM01:2025) | Wrong answers, limits bypassed | FDE | Client tech lead | Open | 2026-10-09 | — |

Write each risk as a concrete scenario on the client’s system rather than copying the OWASP item name. A row that just says “Prompt Injection” tells nobody what to do. A row that states who does what, with what consequence, gets an owner.

Check: the approver for every AI risk must be someone on the client side, because only they have the authority to accept risk to their own data and customers.

Step 4: dependencies and issues, the two sections often left empty

On a client site, the first thing that blocks you is often not the model but an account that has not been provisioned. Access to the client’s systems is the classic dependency. Use the DEP- prefix so it is not confused with decision codes.

| DEP-01 | D | Need read access to the customer service document store for indexing | Evaluation cannot start without it | FDE | Client head of IT | Waiting | 2026-10-09 | — |

Keep the line between R and I simple: things that might happen belong in R; things that have happened move to I. If DEP-01 slips by two weeks, open a new I row that points back to DEP-01 rather than just changing the date.

Step 5: each major decision gets its own ADR-style file

Engineers already know a suitable format. An ADR records an architectural decision together with its rationale, and according to adr.github.io, the collection of a project’s ADRs is that project’s decision log.

In the example, decision files use the prefix QĐ, from the Vietnamese quyết định (“decision”).

# DEC-001: Agent only drafts emails, never sends them

Date: 2026-10-09 (example)
Status: Approved
Participants: FDE, tech lead, Customer Service Director, security representative
Approver: Customer Service Director
Related risks: R-02

## Context
The agent was proposed to reply to customer emails on its own.

## Decision
The agent only creates drafts; customer service staff press send.

## Rejected alternative
Automatic sending for emails in the "simple question" category.

## Consequences
Slower response times; revisit once evaluation data is available.

QĐ-002 follows the same template, for example: the chatbot retrieves only documents the person asking is allowed to see, and policyholders’ personal records are not indexed. The approver is the client’s security representative, and the related risk is R-01.

Not everything needs a file. Fellow advises keeping a detailed decision log only for high-impact decisions, such as hiring, budgets or major events, rather than recording every minor discussion. On an AI project, you can set the threshold like this: any decision that changes what data the model sees or what actions the agent may take must have a file.

Recording participants’ names is not a formality. Fellow points out that the list is useful when someone later denies having been part of the discussion.

Check: every risk with status Open must point to a decision or a mitigation plan. The approver field of every decision must be a specific person, not “the whole team”.

Step 6: keep the log alive

Process Street recommends updating the RAID log regularly but gives no specific schedule. The most durable approach is to attach it to an existing rhythm, for example spending the last ten minutes of the weekly client meeting reviewing open rows and assumptions nearing their deadline. A log that is never mentioned in any meeting becomes decoration within a month.

Mistakes that make the log useless

The first mistake is putting the FDE’s name in both the owner and approver columns. Do that and you take on risk that belongs to the client. The second is copying the OWASP list wholesale into the log, which makes it look complete while nobody knows what action to take.

The other two mistakes pull in opposite directions. Some teams record every conversation as a decision, until the real decisions are buried under notes. Others keep the log on a personal machine where the client has never seen it. When an incident comes, nobody can claim the client accepted a risk they never read.

Where this skill shows up in FDE work

On a client site, set up the RAID log in the first week and walk through it with the client’s sponsor. Reading each assumption aloud in front of the person with decision-making authority gives you an early chance to spot where the two sides understand things differently. When the client proposes giving the agent more permissions, you already have a place to record who agreed and why.

When reading job descriptions, if phrases such as stakeholder management, risk or governance appear alongside deployment, have an example of your log ready for the interview. On your CV, do not just write “risk management”.

Be specific instead, for example: built a RAID log and decision log for a RAG deployment, linking each LLM risk to an approver on the client side. In interviews, have a story ready about a decision you recorded and what happened because of it.

Models will be replaced and prompts will be rewritten. The line that reads “Approver: Customer Service Director” is what still matters when someone asks why the agent was allowed to do that.