# How to risk-classify AI agent actions (and who approves what)

> Classify each operation by its consequences, the data it touches and the authority it needs. This guide offers an example policy to adapt, then explains what to test before relying on it.

Published 2026-09-02 · Updated 2026-09-08 · Genaima AI

## Classify actions, not agents

The same agent can prepare a private draft, post to a shared channel or change a customer record. Those operations have different consequences. A useful policy lists the operations the workflow may perform, the conditions under which they are allowed and who can authorise them.

Include reads as well as writes in the access review. Retrieving a confidential document, sending its contents to a model or exposing it in a draft can affect privacy even if the source record is unchanged. Read-only does not mean permission-free, and producing a draft can still incur processing and storage costs.

## Three example review levels

**A starting framework, not a universal risk standard**

| Level | Possible treatment | Example with conditions |
| --- | --- | --- |
| Bounded routine operation | May run under an approved policy with scoped access and monitoring. | Prepare a private draft from authorised records for its intended reviewer. |
| Shared operational change | Require the designated record or workflow owner to review. | Suggest a CRM field update with its current value and supporting evidence. |
| Consequential action | Require explicit authority and the controls appropriate to the consequence. | Send to a customer, commit resources, delete records or change permissions. |

The classification depends on the actual data and context. Posting internally can expose sensitive information to the wrong team. A reversible field change can trigger another system before it is reverted. A small transaction can still require authorisation. Your organisation's existing policy should determine the final rules.

## Test reversibility, commitments and visibility

1. **Reversibility** — Can the organisation undo the practical effects, including downstream events and copies already seen by someone else?
2. **Commitments** — Does it authorise spending, change availability, promise delivery or alter a business obligation?
3. **Visibility** — Who receives the information, and are they authorised to receive those particular records?

Also consider scale and frequency. One incorrect update and the same update repeated across many accounts have different impact. Evaluate a workflow at the volume and permissions it will actually use, with limits that can be enforced.

## A copyable policy table

**Example policy fields to complete with your team**

| Operation | Review requirement | Checks to define |
| --- | --- | --- |
| Read source records | Authorised access under the workflow policy. | Permitted accounts, fields and handling of removed access. |
| Prepare a private draft | Review before using the output for a consequential task. | Correct recipient, source references and visible missing information. |
| Update a shared record | Record owner or another authorised reviewer. | Old and new values, current record state and downstream effects. |
| Send externally | Named authority for the relationship and message. | Recipient, exact approved content, expiry and duplicate prevention. |
| Commit resources | Authority defined by the organisation. | Applicable limits, current availability and additional required approvals. |
| Delete or change access | System owner and the existing change process. | Scope, recoverability and verification of the intended effect. |

Assign an accountable owner and a deputy. A role can define authority, but the operating process also needs to resolve that role to an available person. Record what should happen while the approver is absent or a request is disputed.

## Enforce the policy in the application

A prompt asking an agent to obtain permission is not enough. The tool or application path must check whether the operation is allowed and whether the required approval applies to that exact action. Sensitive inputs must remain data, not instructions that can expand the workflow's authority.

Bind review to a specific output version and destination. Recheck relevant permissions and record state before execution. Handle rejection, expiry and retries explicitly, and record the result. Genaima agrees these controls within the implementation scope; [security and governance](https://genaima.ai/security) describes the review questions.

## Common mistakes

- Treating every read as harmless without checking what information it exposes.
- Approving a draft and then allowing its content or recipient to change before sending.
- Assuming a rejected action cannot be retried through another path.
- Ignoring downstream automation triggered by a seemingly small update.
- Reviewing only successful examples and leaving denied or incomplete cases untested.
- Expanding a workflow's users or volume without revisiting its limits.

## Common questions

### Must every operation wait for a person?

No single policy fits every task. Define which bounded operations may run under prior authorisation and which require a fresh decision. Enforce the boundaries and review their performance.

### How should we test approval?

Try a permitted action, an unauthorised reviewer, a rejection, an expired decision, a changed output and a repeated request. Verify the resulting system state rather than only the message shown to the user.

### Can the policy change?

Yes, through an explicit review of evidence and consequences. Repeated acceptance alone does not prove an action is safe to automate; check failure cases and downstream effects before changing authority.

- [Launch your autopilot](https://genaima.ai/contact) — Bring the operations your workflow needs to perform and the people authorised to approve them.

## Related

- [How a workflow runs](https://genaima.ai/how-it-works)
- [Security & governance](https://genaima.ai/security)
- [Questions to ask AI agent vendors](https://genaima.ai/insights/questions-to-ask-ai-agent-vendors)
- [Finance & operations](https://genaima.ai/solutions/finance-ops)

---

- Canonical page: https://genaima.ai/insights/risk-classify-ai-agent-actions
- More: [Home](https://genaima.ai/) · [About Genaima](https://genaima.ai/about) · [Contact Genaima](https://genaima.ai/contact) · [How a workflow runs](https://genaima.ai/how-it-works) · [The AI operating layer](https://genaima.ai/ai-operating-layer) · [Security & governance](https://genaima.ai/security) · [FAQ](https://genaima.ai/faq) · [Implementation partner](https://genaima.ai/partner) · [Solutions](https://genaima.ai/solutions) · [Industries](https://genaima.ai/industries) · [Compare](https://genaima.ai/compare) · [Insights](https://genaima.ai/insights) · [Glossary](https://genaima.ai/glossary) · [Tech stack & tools](https://genaima.ai/tech-stack) · [Resources](https://genaima.ai/resources) · [Pricing & scope](https://genaima.ai/pricing) · [Selected work](https://genaima.ai/work) · [llms.txt](https://genaima.ai/llms.txt)
- Contact: hello@genaima.ai