Practical AI operations guide

Write an AI agent permissions and approval matrix your team can use

Giving an agent a task does not settle what it is allowed to do. Answering a question, drafting a reply, sending that reply and changing a customer record are different permissions. A useful approval matrix names each action, the data it may use, the conditions that allow it and the person who can approve an exception.

This guide is a proposed design method, not a claim about a particular product's controls. Start with one workflow and test the permitted and prohibited actions. Keep consequential decisions behind controls your team can inspect, rather than relying on an instruction that the agent should be careful.

Scope my agent approval rules (03) 9003 0111

Permission workflow from identifying the action and checking the boundary to obtaining approval and verifying the result. Select the diagram to view it full size.

Separate these four permissions

Read

Access information

Specify which records and fields may be retrieved.

Draft

Prepare a proposal

Keep the proposal distinct from an approved action.

Change

Modify a record

Define permitted fields, limits and conditions.

Send

Communicate externally

Check the recipient, content and sending authority.

Design around actions rather than job titles

A label such as sales assistant is too broad to describe the access and authority a workflow actually needs.

One task can cross several authority boundaries

An agent handling a service enquiry might read a customer record, create a draft estimate, change a job status and email a customer. Those steps have different consequences. Put them on separate rows even if they appear in one conversation. This lets the business allow useful low-consequence work while keeping a consequential action behind review. It also makes a failed test specific: the issue is an unauthorised status change, not a vague judgment that the agent is too autonomous.

Access and permission to act are different

A connected account may technically be able to read every customer or edit every field. Your approved workflow may need only a small subset. Record both the intended policy and the access actually granted. If the platform cannot enforce the narrower boundary, that gap belongs in the design decision. Do not present a written matrix as an enforced control when the underlying identity retains unrestricted access to the system.

Approval needs a precise object

A person cannot meaningfully approve an unspecified future action. The review should show the exact proposed change, target record, recipient where relevant and the evidence used. If those details change after approval, decide whether a fresh approval is required. Keep an approval tied to the proposal that was reviewed, rather than a general instruction to go ahead that can be reused for different content or a different customer.

The business must own exceptions

A workflow will encounter a request outside its ordinary rules. Define who may decide, what information they need and what the agent says while waiting. The exception path should preserve the request without silently widening permissions. This is especially useful when the requester sounds senior or urgent. Authority comes from the approved process and verified context, not from persuasive language inside an email or a caller's assertion about their role.

Build the matrix one consequential action at a time

Use the following fields as a worksheet, then map them to controls available in the systems you actually run.

Action

Describe the action precisely

Write a verb, an object and a destination: draft a reply to the enquiry, update the internal priority field, or send the approved appointment message. Avoid broad rows such as manage customers. Separate record creation from updates and separate internal notes from external communication. Include actions reached through secondary tools, because a general request function can otherwise become a route around a carefully limited named action.

Boundary

Bound the data and targets

Specify the customer set, records, fields and destinations in scope. Include how the target is selected and what happens when matching is ambiguous. Reading a record should not automatically authorise changing it. Define what information may leave the source system in a draft, notification or log. Keep unnecessary sensitive fields out of the working context where the workflow can perform the task without them.

Conditions

Write the conditions for autonomy

State the conditions under which the action can run without a person. These should be checkable from reliable inputs: an approved status, an exact target match or a defined message type. Avoid conditions such as when the agent is confident unless that signal has been evaluated for the actual decision. Specify the result when a required input is missing. Missing evidence should not be quietly replaced with the most convenient assumption.

Review

Define the approval packet

Show the proposed action, the evidence behind it, the target and any differences from the current record. Give the reviewer an approve, reject or request-changes decision that produces a clear state. Record which version of the proposal was reviewed and how long that decision remains relevant. If the customer cancels the request while approval is pending, the workflow should not treat the old approval as a reason to proceed anyway.

Enforce

Enforce the boundary at execution

Check authority again where the action occurs. A proposal may have been valid when drafted but become invalid before execution because a record changed or an approval was withdrawn. Use dedicated access and action-specific controls where the systems support them. Record any enforcement limitation explicitly. A prompt instruction can explain the policy to the agent, but it should not be the only barrier protecting a consequential destination.

Verify

Test refusals and completion evidence

Run a permitted case, a prohibited case, a missing-input case and a changed-after-approval case. Inspect destination state and the audit record, including whether a rejected action left any partial change behind. Verify the wording reported to the user: a pending proposal should not be described as completed. Retain the test coverage and the unresolved limitations with the matrix so future changes can be assessed against something concrete.

Example rows to adapt to your business

Task	Traditional	A more specific proposed rule	Notes
Read service history	Access the CRM	Read approved fields for the matched customer	Record how the customer is matched and what happens when several records could fit. A broad CRM connection may expose more than the workflow needs; verify the actual access and make any remaining gap visible.
Draft a customer response	Handle incoming emails	Prepare a reply in a review queue	Draft creation does not include sending authority. The reviewer should see the original enquiry and relevant approved source. Keep the proposed recipient and attachments part of the reviewed object, not hidden delivery settings.
Change job priority	Manage urgent jobs	Change only the agreed priority field under defined rules	A requester's use of the word urgent is not necessarily a business priority decision. Write which evidence supports the change and where uncertain requests go. Leave other job fields outside the action's scope.
Cancel an appointment	Manage bookings	Request review unless this exact cancellation is authorised	The action needs an unambiguous booking target and current permission. Decide what the caller is told while approval is pending. The workflow must distinguish collecting a cancellation request from confirming the calendar changed.
Send a quotation	Follow up sales	Send only the approved quotation version to the approved recipient	A revised price, attachment or recipient changes what the person reviewed. Bind sending to the approved proposal and check that it is still current. Do not allow a broad sales role to imply authority to negotiate terms.
Update payment details	Maintain supplier records	Route the request to the existing authorised review process	Treat this as a separate consequential action rather than ordinary data cleanup. The agent may collect the request and supporting evidence without gaining authority to change destination details. Keep the business's verification process explicit.
Publish a knowledge answer	Answer staff questions	Use accessible approved sources and show uncertainty	An internal answer can still disclose information to the wrong staff member. Preserve access boundaries during retrieval and response generation. If the source is missing or conflicting, identify the gap rather than inventing a policy.
Delete a record	Keep systems tidy	Exclude deletion unless separately scoped and approved	Tidying language can conceal irreversible effects. If deletion is needed, define eligibility, retention decisions, related records and recovery limits with the responsible owner. A general cleanup instruction should not silently grant destructive authority.

Where approval designs lose their meaning

A broad credential beneath a narrow policy

The matrix may say read only while the connected identity can write. Record the difference and narrow the access where feasible. If the system cannot restrict the credential sufficiently, consider a constrained intermediary or a different workflow. Do not report least privilege as achieved simply because the intended behaviour has been written down or because ordinary tests did not attempt a prohibited action.

An approval detached from the final payload

A reviewer approves a draft, then the agent changes the recipient or message before sending. The stored approval no longer describes the action. Preserve the reviewed proposal and check its identity at execution. Decide which changes require renewed approval, and make that behaviour visible to reviewers so they understand what their decision actually authorises.

An approver who cannot assess the evidence

A button is not a useful review process if the person sees only a generated summary. Show the source material and the proposed difference at the level needed to decide. Avoid sending every minor item for review just to claim human oversight. Review load matters: a queue that overwhelms staff encourages habitual approval and leaves the consequential cases difficult to find.

Urgency treated as permission

Incoming text may claim a manager has approved an action or demand that normal checks be skipped. Treat that claim as part of the request until authority is established through your agreed process. Keep the exception route usable when time matters, but do not let the agent expand its own permissions in response to pressure or a role claimed by an unknown sender.

Permissions that accumulate after a pilot

Temporary access often becomes the permanent configuration because nobody owns its removal. Give pilot permissions an owner and a review point. Compare the actual granted access with the current matrix after a scope change or staff departure. Remove capabilities no longer required through the approved administration process, and verify the remaining workflow still works within its intended boundary.

A successful tool call reported as the wrong outcome

The action service may accept a request without completing the business change. Define which result authorises the agent to say completed. Preserve pending, rejected and unknown states where needed. Test the language after a timeout or a partial result, because a polished completion message can otherwise hide the exact uncertainty the approval controls were meant to manage.

Worked example: approval for a quotation email

Imagine a fictional service business that wants an agent to prepare quotation follow-ups. Its owner permits draft creation but requires a salesperson to approve the recipient, message and attached quotation before sending. The matrix therefore contains separate rows for reading the enquiry, preparing a draft, reading the approved quotation and sending the approved email. Access to the inbox is not treated as authority to negotiate or revise a price.

The agent prepares a follow-up for Taylor Example using a synthetic enquiry and a test quotation. The review packet shows the target address, message text, attachment version and the source enquiry. The salesperson approves that packet. Before sending, a second customer message arrives requesting a different service address. The system holds the action because the proposal may no longer match the current request. It does not silently rewrite the quotation and reuse the old approval.

The salesperson reviews the change and chooses whether a revised quotation is needed. If they approve a new packet, the sending action checks that exact packet and its current permission. The audit record connects the approved proposal to the resulting delivery request. A delivery failure remains a failure or pending state according to the provider evidence; it is not described as a successful customer contact merely because the draft existed.

The test set also includes an unapproved draft, a changed attachment, a different recipient and an incoming message that says the owner has waived review. None should acquire sending authority on its own. An ordinary approved packet must still send correctly to the test destination. Testing only refusals would produce an agent that looks controlled but cannot carry out the authorised workflow.

The business retains the final matrix, sample review packet and test outcomes. If a later change adds an automatic reminder service, that new sending path must be considered explicitly. It cannot inherit broad authority just because it belongs to the same sales workflow. The useful control is the relationship between a specific approval and a specific action, enforced wherever that action can occur.

How Yes AI can support a permissions review

Translate the workflow into action rows

We can work through one process with its owner and separate reading, drafting, changing and sending. The resulting matrix is written around the business outcomes and exceptions your team actually encounters. It should be specific enough for a builder to implement and an operator to test.

Compare intended policy with actual access

We can inspect the available configuration and identify where the connected account grants more access than the proposed process needs. Controls depend on the systems and permissions available. Any inaccessible or unenforceable boundary remains a stated limitation that needs a decision, not a completed security claim.

Design review packets and refusal tests

We can help define what reviewers see, how approval is bound to a proposal and which negative cases prove the boundary. The goal is a usable review process with evidence. A diagram or a matrix alone does not establish that the running agent obeys it.

Keep the scope proportionate

Some processes should remain draft-only or manual because the consequences, data quality or review capacity do not justify automated action. We can help assess that choice before building. A permissions review does not replace specialist advice or the business owner's responsibility for deciding who has authority.

Put the matrix into use

A short enforced matrix is more useful than a large policy that nobody maps to the running workflow.

List the actual read and action paths

Trace one ordinary request through the systems it touches. Include secondary services, notifications and background retries. Record the current identities and their granted access without placing credential values in the worksheet. This establishes what needs a rule and what can be left outside scope.

Agree the business authority for each row

Assign an accountable owner, allowed conditions and an exception decision. Keep read, draft, modify and send separate. Ask the person responsible for the consequence to confirm the rule, rather than letting an implementation convenience decide who can approve a customer or financial change.

Map each rule to an enforcement point

Identify where the target, conditions and approval will be checked. Record limitations of the available platform and choose a response to each gap. The result might be narrower access, a constrained action service, mandatory review or excluding the action from the pilot.

Run allowed and forbidden cases

Exercise both sides of every consequential boundary using controlled records. Include expired approval, changed payloads, ambiguous targets and an incoming request that claims special authority. Inspect the destination and the user-facing outcome, not just the workflow's internal success status.

Review changes against the current matrix

Keep the matrix with the operating instructions. Revisit it when tools, data sources, approvers or business responsibilities change. Compare the granted access with the approved scope, and retain the evidence that the current version still blocks the actions it is meant to block.

Turn this guide into your next steps

Use these steps to prepare your own review. Tick a step once you have recorded its evidence. Ticks are temporary and are not saved or sent to us.

List the actual read and action pathsAgree the business authority for each rowMap each rule to an enforcement pointRun allowed and forbidden casesReview changes against the current matrix

Bring one example of the process you want to improve. We can help define the scope, checks and next decision. Consultation options and any fee are shown before you book.

Scope my agent approval rules

FAQ

Can the prompt contain the whole permissions policy?

It can explain the policy, but consequential actions need controls at the place where they occur. The prompt does not change the access granted to a connected account. Compare intended behaviour with actual permissions and test prohibited actions. If the platform cannot enforce a required boundary, narrow the workflow or keep that action under a separate approved process.

Does every action need a human approval?

No. Decide based on the action's consequences, the reliability of its inputs and the available controls. A business may allow an internal draft or a narrowly defined update while reviewing an external commitment. The matrix should make those distinctions explicit. Sending every item to an overloaded reviewer can create a weaker process than a small, well-defined autonomous scope.

Who should be the approver?

Choose the person who has authority for the consequence and enough context to assess the proposal. Define an alternate and a process for absence. The original developer is not automatically the right approver for a customer promise or financial change. If nobody can assess the decision from the review packet, improve the packet or leave the action outside the automated scope.

What happens when the approved content changes?

Decide which changes invalidate approval and enforce that decision at execution. Recipient, amount, target record and attachment changes are examples that deserve explicit treatment. Preserve the reviewed version so a later audit can identify what was authorised. Avoid a general approval flag that remains true while the underlying proposal is replaced.

How do we handle emergency requests?

Write a separate exception process with verified authority, a named decision-maker and a record of the action. Urgency should affect routing and attention, not let the agent grant itself additional access. Test a request that falsely claims an emergency or senior approval. Make sure the normal workflow can preserve the request and explain its pending status while review happens.

What should the audit trail contain?

Keep enough to connect the source request, proposed action, approval decision, execution and observed outcome. Include target identifiers and the reviewed version while avoiding unnecessary sensitive content. The exact retention and access decisions belong to your business's requirements. A log that says approved without showing which proposal was approved is not sufficient to reconstruct the decision.

When is this too much work for a small business?

Keep the matrix proportionate to the workflow. A draft-only assistant may need a few clear rows and a straightforward review queue. If an action has significant consequences but the business cannot support the required controls, leaving it manual can be the right outcome. The goal is useful clarity about authority, not an impressive-looking document.

Decide what the agent may do before connecting more tools

Bring one workflow and the actions you are considering. We can help define the allowed scope, approval evidence and tests needed for a useful pilot.