Your AI Assistant Needs Limits Before It Gets Access

Before you connect an AI assistant to your inbox, files or business tools, decide what it may read, draft, send and change. Start with the smallest permission that makes the task useful. Then test whether the assistant can cross the boundary when a message is confusing, incomplete or deliberately misleading.

This AI Boss guide applies my S4 AI Safety Framework to a practical workplace assistant. You will define its job, challenge its behaviour, enforce its limits and inspect what happens after use. The aim is a useful assistant whose authority you understand, with a person ready to handle the cases it cannot settle.

AI safety and alignment are a personal responsibility. When you choose to use an AI tool, you also accept responsibility for checking what you share, what you approve and who your decision could affect.

Adrian Dunkley, author’s statement

An inbox summary and a sent instruction are different jobs

Consider a hypothetical assistant that reads a manager’s messages and prepares a morning task list. It may correctly identify a supplier invoice and a meeting request. That does not establish that it should pay the invoice or accept a new contractual date. Both actions create commitments that summarising the message does not.

Write the task in ordinary language: identify work that needs the manager’s attention and point to the source message. Keep proposed replies in drafts. If a sender asks for a changed bank account, the assistant should flag the request for an independent check through an established contact route. The email requesting the change cannot also serve as the independent confirmation.

An assistant can also make a subtler mistake by promoting another person’s request into your priority. A strongly worded message may say that an assignment is urgent without having authority over your week. Ask the assistant to distinguish a deadline supported by an agreement from a deadline merely requested by the sender. You can then decide where it belongs.

In a small Caribbean business, the owner may also be the reviewer and the person handling customer complaints. Keep the first version manageable enough for that person to inspect. If checking the assistant creates a backlog, measure the backlog and change the workflow. Time saved in drafting is only part of the work; checking and correction belong in the same comparison.

Build the morning task list around a small set of fields: the requested action, the source message, the stated date and the person who can decide. Leave an item unresolved if the message lacks the information needed to place it. That is more useful than filling the list with confident guesses that you have to unravel later.

Try a forwarded thread in which the newest message changes a meeting time but quotes the old arrangement below it. The expected result should distinguish the update from the quoted history and preserve the time zone. The assistant should prepare a suggestion for your calendar rather than treating the whole thread as a fresh instruction.

Also check what happens after a task is dismissed. If the assistant adds it back every morning from an old message, the list becomes harder to trust. Decide where completion status lives and which source can change it. A request from another sender should not silently reopen an item you have closed.

When the list is working, expand one permission at a time. Access to another mailbox, permission to label a message and permission to send a reply create different opportunities for error. Keep the previous configuration so you can compare the change, and preserve the ability to remove the new permission without losing the useful draft-only service.

Use S4 to connect purpose, evidence and permission

AI safety asks what harm a system could cause and how you can prevent, detect or contain it. Alignment asks whether its behaviour serves the intended purpose within the human constraints agreed for that use. A system can follow a poorly chosen objective and still harm the people it was meant to help. A fluent answer alone establishes neither safety nor alignment.

Consider a hypothetical service assistant assessed only on how quickly it closes enquiries. It could improve that measure by ending difficult conversations early. The dashboard would show progress while some people receive less help. The corrective work starts with the objective, the evidence of a resolved problem and the route for an unresolved case. Polishing the response does not settle those choices.

This distinction connects with Amodei and colleagues’ research on concrete AI safety problems, which separates difficulties involving objectives, supervision and unfamiliar conditions. Here I apply that distinction to everyday decisions about authority. This article offers a proposed working method and illustrative cases. It does not report a trial of these organisations or a measured regional failure rate.

My S4 AI Safety Framework brings four checks into the decision about what an AI system may do: Specify, Stress-test, Safeguard and Scrutinise. I developed it as an educational synthesis drawing on risk management and safety engineering. Each check should leave evidence that someone else can inspect, challenge and use to change the deployment.

S4 sits alongside established guidance. NIST’s AI Risk Management Framework 1.0 uses Govern, Map, Measure and Manage. S4 does not rename those functions or establish equivalent certification. Its narrower practical question is whether the evidence supports the permission being requested for a particular workflow. The answer can be a restricted trial, continued assistance, a redesign or a decision to stop.

Apply S4 to the work you are about to approve

Specify the purpose and the person with authority

For people using AI at work, a useful specification begins with a manageable list of work supported by the messages that created it. Describe what counts as an acceptable result and who could be harmed by a mistake. Identify the source that decides the answer when records conflict. Do not approve an open-ended instruction to improve efficiency and leave the operating team to discover its limits.

The authorised task in this example is creating a task list and preparing unsent replies linked to their source messages. The prohibited action is sending a message, approving an invoice or changing a calendar commitment without separate authority. Write that distinction into the workflow and the permission settings. Name the person who owns the service outcome and the person who can approve a change. They may need different expertise; neither role should be left to a generic team label.

Stress-test the cases that could change your decision

Build the test around a false urgent request, a forwarded attachment with hidden instructions, an ambiguous meeting time and a supplier bank-detail change. Include a straightforward case, a difficult but legitimate request, missing evidence and a deliberately misleading input. Separate the cases used to improve the system from the cases reserved to challenge the revised version. Record the source and expected response before looking at what the model produces.

Ask a knowledgeable reviewer to explain the consequence of each error. A missed deadline can inconvenience the team, while an unauthorised payment or disclosure can affect customers and the business directly. Decide which failures require the affected function to remain disabled. A small test can expose a problem but cannot establish a rare-event rate, and repeated attempts on the same example are not independent evidence of reliability.

Safeguard the action before it reaches another person

The first enforceable boundary should be read-only access to the selected mailbox and draft-only access for proposed replies. Check it at the point where the action becomes effective. A warning in a draft does not prevent a connected tool from carrying out the wrong instruction. Verify the limit with an attempted prohibited action in an authorised test environment, and retain the observed result.

Arrange a fallback in which the owner returns to the original inbox and uses the normal payment and scheduling process. Rehearse who notices the problem, who suspends the relevant access and who carries the unfinished work. If the fallback depends on the same unavailable supplier or the same compromised account, it needs another route. Test recovery without interrupting the live service.

Scrutinise outcomes and decide whether use should continue

After release, inspect missed tasks, false urgency, draft corrections, unintended recipients and the time spent reviewing. Include near misses and corrected drafts as well as completed transactions, because a polished final record may conceal the work needed to repair an unsuitable recommendation. Ask the people handling exceptions which problems the dashboard fails to show. Record disagreements that could affect the decision.

Set a review when the connected mailbox, tool access or workflow owner changes. Define who can authorise restart and what evidence they need. A scheduled review date does not justify waiting when a serious problem appears earlier. Keep an accessible complaint route and check whether the person raising the issue receives an explanation and a correction.

Put numbers on the permission boundary

For a workflow that can commit money, estimate how much direct commitment could accumulate before effective containment. In the simple S4 stress scenario, E = a × t × c: consequential actions per minute, multiplied by minutes until containment, multiplied by the maximum direct commitment per action. The result has currency units. This is a scenario envelope, not an estimate of how frequently harm will occur.

Containment means that further consequential actions have stopped. The clock includes detection, acknowledgement, the intervention itself and any queued work that still executes. Timing only how long it takes someone to press a stop button omits the delay before they notice the problem. Test the whole route with non-sensitive examples and record the conditions under which it was measured.

The scenario assumes a constant rate and the maximum commitment on each action. It excludes recovery and secondary consequences. Those assumptions make it useful for asking whether a permission is too broad, but they do not make it a complete loss model. A disclosure of personal information or an unsafe physical instruction also needs a separate assessment, even when its direct monetary commitment is zero.

A shared, independently enforced cap may reduce the direct commitment envelope. Use the smaller of the scenario envelope and the cap only after checking that all relevant accounts, agents and concurrent requests count towards the same limit. A limit that resets during the containment window needs further modelling. An aggregate cap must prevent excess commitments rather than merely announce them after acceptance.

Keep expected loss separate. Estimating expected direct loss would require a supported harmful-event frequency or probability and a consequence model, with dependence and uncertainty addressed. Do not turn an assumed percentage into a finding about a Caribbean organisation. When the evidence is weak, compare several clearly labelled scenarios and ask which restrictions remain sensible across them.

A hypothetical assistant permitted to approve eight US$150 purchases per minute could commit US$3,600 during a three-minute containment interval: 8 × 3 × US$150. Those figures describe a teaching scenario. A draft-only assistant cannot make those purchases through that workflow, so test the actual connected permissions rather than assuming access follows the wording of your prompt.

Make permissions enforceable and review workable

An instruction such as “do not share private information” expresses a rule. Access controls determine whether the software can retrieve and transmit that information. Both matter, but they perform different jobs. Put consequential permissions in application code, identity settings and approval processes that the model cannot rewrite merely by producing different text.

OWASP describes indirect prompt injection as a risk when instructions arrive through external material such as files or webpages. A supplier attachment can contain words directed at an assistant rather than information intended for the task. Treat that material as untrusted input and prevent it from granting itself authority to send, spend or change records.

Review should show the person what will happen, to whom, using which records and with what consequences. An approval label without the underlying action details makes it difficult to challenge a mistake. For higher-impact decisions, require someone who can assess the substance and has enough time to refuse. Record both the original recommendation and the authorised correction where retention is justified.

Personal responsibility therefore needs institutional support. Staff need approved tools, clear limits, access to a competent reviewer and permission to report uncertainty without being punished for slowing a queue. Leaders remain responsible for the targets, permissions and working conditions they approve. Affected people need a workable correction route, including when they did not choose to use AI themselves.

The difficult boundary is often between a helpful suggestion and a suggestion that gets accepted automatically because you are busy. Reserve attention for decisions that matter and reduce the volume of low-value notifications. If every task carries the same warning, the interface makes it harder to recognise the exceptional case that needs you.

A helpful assistant should make it easier for you to see the decision. It should not make the decision disappear inside a convenient reply.

Adrian Dunkley, author’s statement

Test one workflow before granting more authority

By 10 November 2026, choose one bounded workflow with the inbox owner and the person responsible for payment approval and document its current permission settings. Ask the person doing the work to identify a decision they would refuse to delegate and explain why. Use that answer to define an exclusion, a test or an escalation condition rather than dismissing it as resistance.

Prepare 12 authorised or synthetic cases: four ordinary requests, four with incomplete or conflicting information and four that challenge the permission boundary. These are suggested trial counts, not a statistical safety threshold. For every case, agree the source of truth, the acceptable action and the condition that requires a hold. Keep a copy of the test material and the configuration used.

Measure checking and correction time, unresolved cases and whether a prohibited action became possible. Conduct one controlled stop-and-fallback rehearsal. Have a colleague who did not build the workflow examine the evidence. If the case exposes an unresolved critical failure, leave that function disabled and record the repair needed before reconsideration.

End the review with a written decision about this workflow and its stated limits. The useful output is a permission decision supported by evidence. Training attendance, an attractive demonstration and a completed form do not answer whether the system should receive additional authority.