How to Keep AI Under Control When It Helps With Your Work

To keep AI under control, define its job, restrict the information and tools it can reach, and require human approval before consequential actions. Test how to stop it before starting real work. fenbs can keep the approved rules and an attributed record of project changes, while the connected applications must enforce their own access boundaries.

1. Choose one bounded task with an observable finish point.
2. Give the assistant only the accounts, files, and actions that task needs.
3. Specify which exact actions require a person’s approval.
4. Test the boundaries with harmless examples and a deliberate refusal case.
5. Work in small steps, review actual changes, and save the next step before stopping.

This applies whether you use an assistant to prepare a proposal, organize research, or help with a software change. The goal is a workflow you can inspect and interrupt. Confidence in the assistant’s wording is a poor substitute for knowing what it can actually reach.

What is the assistant allowed to finish on its own?

Write the outcome and the boundary together. “Draft a reply using these three approved documents; leave it unsent” is a bounded job. “Handle the client” leaves the assistant to infer which documents, promises, and actions belong to the task.

Include the destination of the result and the point where work should stop. An assistant preparing a spreadsheet summary might stop when it finds a missing source figure. Continuing by guessing would make the result look more complete while weakening the evidence behind it.

Goal: Draft a response to the selected request.
Inputs: The request and the approved reference documents.
May do: Compare sources and prepare a draft.
Must ask: Before using another account or changing shared files.
Must not do: Send, publish, spend, or promise a delivery date.
Stop when: The draft is ready, sources conflict, or required information is missing.

Have the assistant restate the boundary before working. Correct misunderstandings at that point, while nothing has changed. This is a comprehension check; it does not prove the application will prevent a forbidden action.

Which access should you remove before starting?

Review connections and permissions rather than merely adding another warning to the prompt. A drafting task may need selected source documents and no write access. A task that updates a draft still does not necessarily need the ability to publish it or change other people’s access.

The OWASP guidance on excessive agency↗ (opens in a new tab) separates excess functionality, permissions, and autonomy. Check each dimension: what tools exist, what those tools can reach, and which actions can proceed without a person. Removing an unnecessary tool can be clearer than asking the assistant to avoid it.

• Select the project folder or account that actually belongs to the job.
• Prefer read access when the deliverable is advice or a draft.
• Disconnect unused services and remove unnecessary write or management access.
• Keep secrets and unrelated personal information outside the accessible material.

Implementation details for terminals and code repositories belong in AI coding agent security controls. For task-board permissions specifically, see how to keep an AI agent from wrecking your board.

When should it ask for human approval?

Choose approval points by consequence. Sending a message, publishing a page, deleting a record, spending money, or changing access can affect other people before you notice a mistake. Ask for a concrete preview of the proposed action rather than approving a vague intention.

Make approval specific to the reviewed action. If the destination or content changes, check whether the approval still covers it. Put lasting approval requirements in fenbs Decisions and rules, with the person who chose them and the scope where they apply.

How do you check the controls before trusting them?

Use a small test area with harmless information. Confirm that an allowed read succeeds, an unrelated read is refused, and a restricted change cannot proceed. Inspect the destination system rather than relying only on the assistant saying it was blocked.

Also test ambiguity. Put two conflicting sample documents in the approved set and ask the assistant to draft a conclusion. It should surface the conflict and request a decision where needed. Our separate guide to keeping AI from hallucinating covers answer verification in depth.

Choose checks that match the cost of failure. The NIST AI Risk Management Framework↗ (opens in a new tab) offers a voluntary structure for evaluating and managing AI risks. A successful sample is evidence for that sample, so repeat relevant checks when access, tools, or the workflow changes.

How can you stop the assistant if it goes off course?

Learn the stop control in the application you are using, then find where its connected access is revoked. Stopping a conversation and stopping an external job are different operations. A queued message, running script, or scheduled action may need to be stopped in its own system.

1. Stop the active run through the application’s controls.
2. Check connected systems for running or queued work and stop it where possible.
3. Revoke the affected connection if continued access is unsafe.
4. Preserve the relevant action records, then review and correct what changed.

Test this procedure before granting consequential access. If sensitive information may have been exposed, follow your organization’s incident process. NIST’s incident response guidance↗ (opens in a new tab) treats response as part of broader risk management; do not assume a revoked connection removes information already sent elsewhere.

What should remain in the record after each session?

Record what changed, what was checked, what failed, and the next permitted step. Distinguish “draft prepared” from “approved” and “approved” from “sent.” The next assistant needs those differences to avoid repeating an action or treating an unfinished review as complete.

An outside AI brain can preserve that selected work context between sessions. In fenbs, History records changes with the person or assistant responsible. It covers the work recorded there; it does not observe every action an assistant takes in other applications.

How to do this with fenbs

1. Create a free account and add a project for one bounded piece of work.
2. Record the rules a person approved: allowed inputs, actions that require approval, and the conditions for stopping.
3. Add the task and its plan, including the expected deliverable and checks. Use a team kanban board with appropriate member roles when colleagues need access.
4. Connect a supported assistant through Integrations, ask it to read the project context, and have it save progress before the session ends.

fenbs is free for one person, no credit card. It is useful for retaining shared rules and progress; it is not a system for controlling all activity on your computer. If you need to enforce file, network, or publication restrictions, configure those controls in the applications and infrastructure involved.

Start with one task and widen access only after checking a real need. The AI governance hub offers further guidance as the workflow grows. A clear stop point and a reviewed record make the next small step easier to authorize.