List every current grant
Record the agent, connected system, account or workspace, action allowed, data it can reach, credential or delegated path used, date granted, and expiry or review date. Include permissions inherited through another tool.
Cogweft / Permission guide
Define an AI agent's permission boundary before deployment.
Give the agent one clear job—and a human a clear stop button.
A plain-English guide for small-business owners deciding what an AI agent may access, which work needs approval, and how to remove authority safely.
Read this first
General implementation guidance, not a Cogweft product claim.
This guide is general planning advice for a small business considering an AI agent. It does not describe Cogweft's agents, integrations, credentials, controls, outcomes, or customer evidence. Use the ideas with the actual provider and workflow, ask for current written answers, and obtain any legal, privacy, security, or finance review your situation requires. The research findings below are attributed to the supplied snapshot and are not independent verification. [1], [5], [6]
01 / Inventory and ownership
Start with a visible permission ledger.
Before an agent acts, write down what it can read, change, send, approve, or trigger. The inventory should be easy for a business owner to inspect—not hidden in a setup screen or scattered across connected tools. Name one person who owns the decision and can narrow or revoke the authority. [1], [2]
Use the smallest useful scope
Give the agent only the actions and records needed for one bounded workflow. Prefer read-only access, a narrow folder or queue, and proposed changes over direct writes when the job does not require more.
Assign a named owner
The owner checks the ledger, approves exceptions, answers questions about the workflow, and can pause or revoke authority. “The team” is not a revocation plan.
Make authority expire
Use a short pilot window or a review date where the tools allow it. If a grant cannot expire automatically, record the date and the person who must re-confirm it.
02 / Delegation and data scope
Treat instructions from other agents as new authority paths.
An agent may be asked to follow instructions from another agent, an automation, a plug-in, or a message that looks operational. That chain can create authority nobody directly granted. Map the source of each instruction and keep the receiving agent inside its own approved action and data scope. [1], [2], [6]
Separate “can see” from “can do”
Document the records an agent can query separately from the actions it can take. A workflow may need a customer reference number without needing every customer field or permission to edit the record.
Require an approved handoff
For agent-to-agent work, define which instructions are trusted, what evidence must travel with them, and which requests must stop for a person. A downstream agent should not inherit a broader grant just because an upstream agent asked.
Watch for retry and duplicate paths
A failed write or repeated instruction can create a duplicate record or repeat an external action. Give the workflow an idempotency or duplicate-check step and route uncertainty to a person.
Keep an audit trail
Retain the instruction, source, proposed action, data consulted, result, reviewer decision, and timestamp for the period the business needs to investigate the workflow. Define retention and deletion rather than keeping everything by default.
03 / Human approval points
Make consequential work proposed, reviewable, and stoppable.
A useful approval gate says what the person is deciding, what evidence they need, and what happens when the evidence is missing or conflicts. These examples translate the reported operational concerns into a worksheet a small business can adapt. [1], [2]
Supplier or bank-detail changes
- Decision
- The agent may prepare a proposed change, but a person decides whether the supplier or bank record should be changed.
- Evidence to review
- Show the original request, the current record, the proposed new details, the source of the request, and an independent verification path for the supplier.
- Stop or escalate
- Do not write the change or trigger a payment when the request is unverified, the evidence conflicts, or the reviewer cannot confirm the source. Escalate to the named finance or supplier-record owner.
Payments and irreversible actions
- Decision
- A person approves the amount, recipient, scope, and timing before a payment, deletion, external commitment, or other action that cannot be safely undone.
- Evidence to review
- Provide the proposed action, the source record, amount or affected objects, policy checks, duplicate check, and any uncertainty or missing input.
- Stop or escalate
- Pause when the amount, recipient, authorization, or expected result is unclear. Escalate to the accountable owner; do not let a timeout or retry become approval.
Client updates that are not verified
- Decision
- A person reviews a client-facing update when the identity, facts, account status, or requested commitment has not been verified.
- Evidence to review
- Show the client message, relevant conversation and account context, the facts used, the proposed wording, and the exact item that remains unverified.
- Stop or escalate
- Do not send or record the update when the identity or facts conflict. Route it to the client owner or support lead with the original context intact.
Low-confidence or conflicting records
- Decision
- A person decides which source or record is correct when the agent cannot resolve a conflict with an approved rule.
- Evidence to review
- List the conflicting records, their timestamps and sources, the rule the agent applied, the confidence or uncertainty signal, and the proposed resolution.
- Stop or escalate
- Leave the records unchanged when no rule clearly applies. Escalate to the record owner and record the decision so the same conflict can be handled consistently.
Possible duplicate records
- Decision
- A person approves merging, creating, or retrying a record when a duplicate is possible.
- Evidence to review
- Show the matching fields, existing record links, failed or retried attempts, and the proposed create, update, merge, or no-op.
- Stop or escalate
- Do not create another record when the match is unresolved. Stop the retry path and escalate to the CRM or data owner.
04 / Revocation drill
Revoke authority as a procedure, not a promise.
Run this drill before launch and whenever there is a suspected misuse, unexpected action, ownership change, or broad permission change. A revoked button is not enough if a delegated route or stale credential still works. [1], [6]
- 01
Identify the authority to remove
Use the permission ledger to list the agent, connected systems, credentials, data sources, scheduled jobs, downstream agents, and delegated instructions it can use. Include grants that were inherited rather than directly configured.
- 02
Pause or disable action first
Stop the workflow, queue, schedule, or outbound action path so new work cannot continue while permissions are being changed. Preserve the current state and the reason for the pause.
- 03
Remove or narrow every grant
Revoke tokens, connected-app access, delegated permissions, agent-to-agent routes, scheduled triggers, and access to sensitive records. If the workflow must remain available, narrow it to a safer read-only or proposal-only scope.
- 04
Verify that access is gone
Test each relevant system with the revoked identity or a safe equivalent. Check that new actions fail or remain paused, and confirm that downstream agents cannot use a stale delegated path.
- 05
Record who revoked it and why
Write down the date and time, the revoking person, the owner, the grants changed, the reason, the verification performed, and any work left in a queue or affected record.
- 06
Review logs and affected records when risk warrants it
A human should inspect recent activity and records after a suspected misuse, unexpected action, broad grant, data incident, or failed verification. Review what was read or changed, notify affected owners when appropriate, and document follow-up.
Apply it to one workflow
Permission-boundary launch worksheet.
Pick one bounded workflow. Check each line, write the missing details beside it, and do not expand the scope until the owner can explain the approval and revocation path.
Research context
Source notes and limits.
Citations refer to the numbered sources in the supplied research snapshot. The snapshot is marked truncated and did not include complete public bibliographic details, so these notes explain only the findings used here. They are not links to independently verified sources or a claim that every provider behaves the same way.
Source [1]
Permission, revocation, delegation, and proposed operational changes
The supplied research brief attributes to source [1] concerns about who authorized an agent to act, whether permission can be revoked, visibility into current agent permissions, and one agent instructing another with authority that was never directly granted. It also identifies proposed supplier or bank-detail changes, expiring authority, and a named owner as useful controls. The brief does not provide the source’s public bibliographic details.
Source [2]
Operational approval and process-boundary risks
The brief attributes to source [2] concerns about access control, approval issues, unverified client updates, duplicate CRM records when agents retry failed writes, and the need for clear process boundaries and operational control. These findings support the stop rules in this guide; they are not a forecast for a particular business.
Source [5]
Governance, oversight, and implementation barriers
The brief attributes to source [5] findings that messy data, disconnected systems, and a lack of oversight can undermine AI projects, while unclear governance can produce inconsistent and fragmented implementations. The snapshot is a research summary and does not provide a public URL or full citation for this source.
Source [6]
Data access, retention, deletion, and provider settings
The brief attributes to source [6] concerns that free or consumer-grade tools may send business data to external servers, use it for training, retain it without deletion guarantees, or share it among users. It recommends defining retention for logs, indexes, backups, and deletion schedules, checking provider settings, and making access revocation straightforward. The brief does not establish that these practices apply to every provider or plan.
Keep the scope concrete
One workflow, one owner, one written boundary.
Return to the resources hub for the workflow-mapping and data-handling guides, then use this worksheet to make the first approval and revocation drill visible.