C · The BASIC Stack
Set the permissions before you delegate the work.
Controls define what an assistant can read, what it can change, and which decisions belong to you. Start with one useful job, give it the access that job needs, and check the boundary before you depend on it.
Product documentation checked . Account settings and availability can differ.
Choose your guideFive decisions make the boundary clear.
Telling an assistant to ask first is a working instruction. A permission setting determines what a tool or account allows. Use both, and know which one you are relying on. A model following your instruction once is useful evidence about that run; it does not prove the underlying permission is restricted.
Whose account?
Identify the person or service account behind each connection. Its existing access matters.
Which information?
Choose the files, folders, repositories, or records the job needs. Check inherited access too.
Which actions?
Separate reading from creating, editing, deleting, publishing, and sending.
Whose approval?
Decide which exact action needs a person and where that approval is enforced.
What happened?
Review the action record and destination. Know how to stop work and revoke access.
A first workflow: prepare an event recap
- 01Read approved notes
- 02Prepare a draft
- 03Review facts and wording
- 04A person publishes
Set permissions in your assistant or connection.
Each guide explains the actual settings, their limits, a practical test, and how to stop or revoke access.
Choose how AI reaches the work.
| Approach | When it fits | Where to set the boundary | What to check |
|---|---|---|---|
| Manual files | A small first task or a tool without the controls you need. | Choose the exact approved material you upload or paste. Keep external updates manual. | Uploaded copies can remain in conversations or files after the original changes. Review retention separately. |
| Direct plugins and apps | Work in a chatbot with its supported connections. | Review the connected account, provider consent, resource sharing, and available action/approval controls. | Installing a plugin, signing in, and approving an action are separate steps. Controls vary by product. |
| Composio | Connect supported systems through a shared integration service. | Check provider scopes and the selected connected account. Configure the hosted controls or developer session policy that actually applies. | Composio does not make every connection read-only by default. Verify approval support and all execution paths. |
Set up one workflow you can check.
Write the boundary in ordinary language.
Name the job, the input location, the account, and the result. For a recap: read the approved event folder and prepare a draft here. Publishing and email stay with the reviewer.
Put the limits in the right place.
Use the source system for resource access, the connection for supported authorization scopes, and the assistant or integration for available action restrictions and approvals. If a control is unavailable, remove that route from the trial and use approved files manually.
Test access with harmless material.
Use a disposable workspace and fictional notes. Keep one test file inside the allowed boundary and another outside it, never previously uploaded. Verify the actual account permissions and retrieval evidence. An assistant saying it cannot read a file is not enough.
Check actions without contacting anyone.
Prepare a draft in the conversation. Inspect any proposed action and its exact destination. Where you need enforced write denial, use the test in the relevant guide on a disposable target and confirm the denied action in the activity record and the unchanged destination.
Record the result and revisit it.
Keep the account, settings, source links, test results, reviewer, and date together. Recheck after reconnecting an app, adding tools, changing sharing, or enabling a different work mode. Stop jobs and review retained copies separately from revoking a connection.
Keep a permission record.
Fill this in for one workflow. Save it beside the brief and update it when access changes.
# Permission record Workflow: [one job] Owner and reviewer: [names] Assistant and surface: [product, app, work mode] Connected account: [approved identity; no credentials] Allowed sources: [exact folders, files, repositories, or records] Allowed actions: [read / prepare / other explicit actions] Blocked or manual actions: [send, publish, delete, etc.] Approval control and scope: [where configured; which actions it covers] Alternative access routes checked: [browser, local files, other accounts, scripts] Test evidence: [allowed read, denied access/action, destination unchanged] Activity/review location: [where to inspect the run] Stop and revoke steps: [task, connection, upstream provider] Copies/memory to review separately: [locations] Last checked: [date] Review again when: [new tool, reauthorization, sharing or policy change]Download the existing approval-record.md starter
Common questions
Is asking AI to get my approval the same as setting a permission?
No. The instruction describes how you want the assistant to behave. A permission or action restriction is enforced by the product, account, or integration. Check which actions the actual setting covers, then test it with harmless material.
Does read-only mean the same thing in every chatbot?
No. Some settings block writes. Others automatically allow reads while still permitting writes after approval. Read the product-specific meaning before choosing a setting.
Does disconnecting an app erase information AI already used?
Do not assume that. Ending future access, stopping a task, deleting a conversation or uploaded copy, and managing saved memory are separate operations. Each guide explains the relevant controls and links to current product documentation.
The manual is free
Build a system you can put to work.
Get the free AIOS book and practical guidance through The AI Enterprise.
Free. No credit card. Includes The AI Enterprise newsletter. Your download is yours to keep, and you can unsubscribe anytime.