AI Employee Permissions and Approvals: A Practical Model

§ 01Permissions and Approvals at a Glance

Two more layers complete the picture: audit evidence (what can be reconstructed - actor, request, approval, result) and recovery (how harm is contained or reversed).

A sound design combines these controls. No single prompt, approval card, or connector toggle is sufficient.

§ 02What Is the Difference Between Permission and Approval?

A permission is a standing capability granted to an identity. An approval is a decision about whether a particular action - or bounded class of actions - may proceed.

Permission

Examples: read a specified Drive folder; create a draft in one CMS workspace; update one CRM field; run commands inside one project directory; view a designated browser tab group; or send messages only to an internal test address.

Permission belongs to the technical access layer. If the underlying credential can delete every CRM record, a prompt saying “do not delete” has not removed that permission.

Approval

Examples: approve this exact customer reply; approve a refund below a defined amount; approve deployment of this reviewed commit to staging; approve a batch of 20 records that match a saved query; or approve temporary access until a stated time.

Approval belongs to the decision layer. It needs an authorized approver, enough evidence, a clear action, and an expiry or use condition.

Authorization

Authorization is the combined decision that an authenticated identity may perform a specific action under current policy and context. Use:

Authorization = identity + permission + current policy + required approval + runtime conditions

An identity may have permission but lack current authorization because approval is missing; the case exceeds a threshold; the source is stale; the volume limit is reached; the task is outside the role; the allowed window has closed; a required field is missing; or the role is paused.

Human oversight

Oversight is broader than approval. It includes sampling, KPI review, correction, exception decisions, access review, incident response, change approval, and role retirement.

Human oversight can appear throughout the lifecycle. At the action boundary, the permission and approval contract must specify exactly what the system may do, under which conditions, and who must approve it.

Accountability

An AI employee is software, not a legal employee. A human or legal organization remains accountable for choosing the role, connecting accounts, setting permissions, naming approvers, monitoring work, responding to incidents, and accepting or rejecting residual risk.

Do not assign accountability to a model because it wrote a handover.

§ 03Why Must Permissions Be Action-Specific?

System-level labels hide too much. “CRM access” might include: read contact fields; read private notes; export the database; create leads; change lifecycle stage; reassign accounts; delete records; trigger sequences; manage integrations; and administer users.

Those actions have different consequences and should not inherit one policy.

The 11-field permission contract

If a vendor exposes only a broad connector grant, apply narrower controls in the connected system, middleware, workflow, account, folder, or human-operated action layer.

Scope the object

“Drive” is a system. “Approved competitive-research folder, excluding legal, HR, finance, and customer folders” is an object and data scope.

“Email” is a system. “Read inbound messages sent to the AI employee’s dedicated inbox; draft replies; no external send” is closer to an action contract.

Scope the action

Separate: read; search; summarize; create draft; propose change; execute reversible change; send/publish; transact; delete; change permissions; and create or delegate new authority.

Write and administrative access should never be inferred from read access.

Scope conditions and limits

Conditions can include task type, required sources, record state, customer segment, risk class, currency/amount, destination domain, business hours, source freshness, approval validity, action count, cumulative spend, and incident state.

A $50 threshold per action is incomplete if the worker can perform 1,000 actions. Include cumulative volume and period.

§ 04What Five Permission States Should an AI Employee Use?

Use five states that map technical access to operating authority.

These states are not a universal product taxonomy. They are a buyer-facing model for comparing and configuring tools.

State 0: blocked

Block actions that are outside the role; legally reserved; physically impossible; destructive without recovery; unacceptably high impact; unsupported by evidence; impossible to audit; or unnecessary for the outcome.

Blocked is a legitimate production state, not a temporary onboarding inconvenience.

State 1: read

Read access should still be scoped. Reading can expose personal data, credentials, private communications, privileged material, strategic plans, source code, session tokens, and cross-customer data.

“Read-only” means no system change. It does not mean no privacy or confidentiality risk.

State 2: prepare

The worker creates a draft, recommendation, diff, or structured action proposal. It cannot cause the external effect.

Require: source trace; assumptions; affected system/object; proposed change; risk/reversibility; unresolved uncertainty; and approver.

Prepare is often the right long-term state for public, contractual, or high-judgment work.

State 3: approve then execute

The AI employee proposes the exact action. The approver sees enough context to decide. The worker executes only the approved action before the approval expires or context changes.

Approval should become invalid when the target object changes; amount/destination changes; source or policy changes; the action is edited materially; expiry passes; the role or approver is no longer authorized; or an incident pauses the system.

State 4: bounded execute

The AI employee may act without per-item approval only inside an explicit envelope.

It still needs: allowlisted task and action; scoped identity and data; volume/spend/time limits; automatic and manual stop conditions; logs; sampling; exception escalation; postcondition checks; and periodic access review.

The graduated onboarding ladder explains how evidence - not elapsed time - moves a role toward this state.

§ 05How Do You Build an Action-Specific Approval Matrix?

Start from the process decision map, not the connector catalog. The outcome-first AI employee hiring guide shows how to identify the role owner, task decisions, consequences, and action boundaries that this matrix must enforce.

Step 1: inventory actions

List each material action the role might take: system; object; operation; external effect; current human owner; frequency; exception; failure impact; and current recovery path.

Split combined verbs. “Manage email” becomes read, label, archive, draft, send, forward, delete, download attachment, and change mailbox rules.

Step 2: choose the lowest useful state

Ask: what is the lowest permission state that still produces most of the outcome?

A research worker may need web and document read access, but no publishing. A support worker may draft responses while refunds and account changes remain human-only.

Step 3: define approval policy

“Auto-approve” should always name the policy boundary. It should not mean “the agent decides what is safe.”

Step 4: specify the approval packet

Show the approver: worker identity and role; task; target system/object; exact action; before/after state; source evidence; uncertainty; amount/volume/destination; policy and threshold; reversibility; expiry; downstream effects; and approve, modify, reject, or escalate options.

An approval card that says only “run command” or “send email” creates consent without informed review.

Step 5: verify result

After execution, record: action attempted; tool/system response; resulting state; postcondition; unexpected side effect; rollback/recovery if used; task status; and notification.

Approval authorizes an attempt. Postcondition verification proves whether the intended result occurred.

§ 06Which Actions Should Require Human Approval?

Require human approval when consequence, irreversibility, sensitivity, novelty, scale, or uncertainty crosses the organization’s tolerance.

OpenAI’s practical guide to building agents identifies failure thresholds and high-risk actions - such as sensitive, irreversible, or high-stakes actions - as triggers for human intervention. It also recommends evaluating tool risk using factors such as read versus write access, reversibility, account permission, and financial impact.

Use those principles as a starting point, then apply the buyer’s actual policy.

Always review consequence

Consider: financial loss; legal or contractual commitment; rights or eligibility decisions; privacy/confidentiality exposure; security impact; production outage; customer or employee harm; public/reputational impact; data loss; and downstream automation.

An action can be mechanically reversible but socially irreversible. A deleted draft may be restored; an offensive customer message cannot be unsent from the recipient’s memory.

Review novelty and uncertainty

Require approval when the case subtype is new; sources conflict; policy is ambiguous; required evidence is missing; the worker requests broader scope; the action differs from tested examples; a tool returns an unfamiliar result; a target is unusually large or sensitive; or another agent supplied unverifiable work.

The approval trigger should inspect context, not only dollar amount.

Review scale

One correct action does not prove a safe batch. Add limits for records per action; actions per shift/day/week; recipients; cumulative spend; affected customers/accounts; files/rows; publication reach; and downstream triggered actions.

Use a pilot batch before raising the limit.

Keep some decisions human-only

AI may prepare evidence while a qualified person makes and executes: employment decisions; medical diagnosis/treatment; legal advice or final legal acceptance; credit/benefit/eligibility decisions; payment or treasury authorization; security containment with destructive access; irreversible production/data changes; and commitments outside approved terms.

The exact boundary depends on law, policy, risk, system design, and available controls. “Human-only” is a policy decision, not a claim that AI can never assist.

Use the AI employee task-suitability test before granting access. A task that is not observable, recoverable, or safe enough to evaluate should not receive broader authority merely because an approval card exists.

§ 07What Does a Practical Permission Matrix Look Like?

The matrix should describe real actions rather than broad roles.

This table is illustrative. It does not authorize a particular action. Each organization should replace role names, limits, data classifications, approvers, and recovery paths.

Email

Separate: receive; read; label; archive; draft; reply; initiate; forward; download attachments; alter mailbox rules; and delete.

Use allowlisted senders/recipients, domain restrictions, content classifications, attachment rules, rate limits, and commitment boundaries. External send should usually follow a successful draft-and-review phase.

CRM

Scope: tenant/workspace; object type; record segment; fields; lifecycle states; ownership changes; enrichment source; exports; sequences; and deletion.

A worker that may update research_summary should not inherit permission to change account owner or contract status.

Documents and knowledge

Control: folder/project; document classification; read/write; copy/export; sharing; public links; cross-workspace search; source freshness; and memory/retention.

Prevent a shared knowledge connector from silently becoming cross-department authority.

CMS and social channels

Separate create-draft, edit, schedule, publish, unpublish, moderate, respond, change template, install plugin, and administer users.

Public output should include evidence, brand, legal, accessibility, and security checks appropriate to the content. A worker can own the draft queue while publication remains human-controlled.

Code, terminal, and infrastructure

Separate: read file; edit file; create branch; run test; install dependency; execute command; access secret; open pull request; merge; deploy; modify infrastructure; change identity/access; and delete data.

Working-directory scope reduces reach but does not make every command safe. A command inside a project directory can still transmit data, install untrusted software, or call external systems.

Finance and payments

Separate prepare from authorize. An AI employee can collect evidence, reconcile, identify duplicates, draft a payment batch, flag exceptions, and produce an approval packet.

The organization may keep payment release, bank-detail change, credit decision, tax position, and material journal entry under authorized human control.

§ 08How Should Approval Work for Scheduled and Event-Triggered Shifts?

An action that starts while no person is watching needs stronger pre-authorization boundaries - not weaker review.

Approve the envelope before the trigger

Define: trigger source; event type; authenticity; deduplication; required fields; task subtype; allowed action; volume/spend; quiet hours; stale-event cutoff; escalation; automatic pause; and supervisor notification.

The trigger may create a task. It should not automatically authorize every downstream action.

Distinguish policy approval from item approval

Policy approval can allow:

For verified monitoring events from the approved queue, create an internal incident-summary draft, attach source logs, and notify the on-call channel. Do not change production, contact customers, or revoke accounts.

Item approval is still needed before a particular containment or external communication.

Expire standing authority

Review standing authority on a fixed cadence; after an incident; after a role/source/tool/model change; after unusual usage; when the owner changes; when the task has been idle; and when policy or regulation changes.

Disable unused triggers and credentials. A dormant role should not wake with old authority months later.

§ 09How Do CellCog Permissions and Approvals Work?

CellCog’s public AI Employees page says users set goals and permissions, and the product describes approvals as part of the employee scaffolding. The platform also supports connectors, Cowork on a user’s computer, and Browse my Chrome.

When comparing products, make permission and approval granularity a non-compensating gate inside the AI employee platform selection framework. A platform should not advance because superior output quality or lower cost offsets an authority boundary it cannot enforce.

Treat these as separate permission planes:

Passing one plane does not approve another. A bounded role with a broadly authorized browser session still has broad technical reach.

Connector permissions

The current CellCog connectors guide describes connections to services such as Google Drive, Slack, and Gmail and says CellCog accesses services when the user grants permission.

Before connection: inspect requested scopes; prefer a role/service account; remove unrelated data; use a test tenant where possible; verify revocation; decide what may persist under the AI employee memory policy or in outputs; and map each connector action into the matrix.

Do not translate “supports Gmail” into permission to read or send every message.

CellCog Cowork

As of July 19, 2026, the current Cowork guide said Cowork could read and edit files and run terminal commands in a selected working directory. It described per-command approval, configurable auto-approval, blocked sensitive paths, credential redaction in command output, a per-chat toggle, and immediate loss of access when the Desktop app closed.

Use the working directory as one boundary, then add: repository/project scope; read/write/execute separation; command class; network behavior; dependency policy; secret handling; test requirements; output review; destructive-command block; and rollback.

Product safeguards reduce risk. They do not justify auto-approving every command.

CellCog Browse my Chrome

As of July 19, 2026, the current Browse my Chrome guide described a designated CellCog tab group inside a real Chrome profile and four approval thresholds:

The guide says tabs outside the CellCog group cannot be acted on unless adopted, and adopting a personal tab is a separate moderate action. It also says the Chrome safety banner can revoke debugger access for a tab.

Keep most sensitive work at None, Safe, or Moderate unless a specific, tested role justifies more. “Dangerous” is a product threshold name - not a recommendation.

Browser data needs a separate decision

CellCog’s guide and privacy policy describe automatic redaction of password and credit-card fields, but say cookies, local storage, screenshots, and visible authenticated page content may be included in the chat context when accessed.

Therefore: use a dedicated work profile where possible; adopt only necessary tabs; avoid exposing unrelated accounts; do not assume every sensitive field is redacted; treat screenshot and session access as data permissions; require approval for data-changing clicks; and revoke the tab/profile/session when work ends.

Verify current behavior

CellCog’s public controls can change. Before publication and before rollout: recheck the live guides; test the current approval card; verify the default threshold; confirm what action is classified at each risk level; demonstrate revocation; and save evidence of the selected configuration.

Do not claim every sensitive action is automatically blocked. The safe statement is that CellCog exposes user-configurable permission and approval mechanisms, and the buyer must configure and monitor them.

§ 10What Happens When AI Employees Delegate to Other Agents?

Delegation should transfer a task, not silently transfer the delegator’s authority.

When the delegator is an AI manager, apply the AI manager control test as well: routing authority, review authority, repair limits, escalation, and shutdown must be evaluated separately from each worker’s task permission.

Then use the manager-agent versus specialist-agent boundary to keep coordination tools and portfolio visibility separate from each specialist’s domain data and execution permissions.

Use intersection, not inheritance

The specialist should receive only the intersection of: the delegator’s permitted task; the specialist’s own role permissions; data required for the subtask; tool access required for the subtask; current approval; and time/volume limits.

Use:

Effective delegated permission = task grant ∩ delegator authority ∩ specialist authority ∩ current policy

If any set excludes the action, delegation must not expand it.

Preserve the principal and chain

Record: human/business owner; originating AI employee; delegated AI employee or tool; subtask; shared context; permission granted; approval inherited or newly required; output returned; final decision owner; and actions executed.

“Agent B did it” is not enough to reconstruct why Agent A asked or which human-approved role initiated the chain.

Reapprove material changes

Require new approval if the specialist changes the target; requests more data; chooses a higher-impact tool; increases amount or volume; changes external communication; delegates again; encounters conflicting policy; or proposes an action outside the original packet.

Approval of a goal is not blanket approval of every plan an agent team invents.

Keep high-impact authority centralized

For multi-agent work, let specialists gather evidence, analyze, challenge, draft, test, classify, and propose. Keep final high-impact action with one clearly identified authority. This reduces confused-deputy behavior and makes the approval experience understandable.

§ 11How Do You Test Permissions Before Production?

Test both allowed and denied behavior. A test suite that proves only successful access misses the control.

Build four test groups

Include valid tasks, malformed inputs, stale approvals, duplicate events, revoked credentials, cross-account records, and embedded instructions that request broader access.

Test read boundaries

Attempt: an allowlisted object; a neighboring prohibited folder/table; a hidden or sensitive field; another customer/tenant; a personal tab outside the workspace; an old record outside the retention period; and a source supplied by another agent.

The worker should not infer that nearby data is allowed because it is technically discoverable.

Test write boundaries

Attempt: an approved field/value; an unapproved field; the wrong environment; an excessive batch size; a duplicate action; action after expiry; action after role pause; action requiring a second approver; and action whose precondition changed after approval.

Verify that denial is visible and does not trigger an unsafe retry loop.

Test approval semantics

Confirm: the approver identity is authorized; the approver sees the exact target and effect; approval applies once or for a defined batch; material edits invalidate approval; expiry is enforced; rejection cannot be bypassed by rephrasing; delayed approval rechecks current state; approval and execution are correlated; and the approver can escalate instead of approve/reject.

Run reviewer drills with one seeded unsafe proposal. The human gate is a control only if humans can detect the problem.

Test recovery

Perform - not merely describe: connector revocation; worker pause; schedule/trigger disable; credential rotation; rollback or compensating action; queue reconciliation; log preservation; stakeholder notification; and re-entry at a lower permission state.

If recovery cannot be tested safely, the action may be unsuitable for independent execution.

§ 12What Evidence Should Every Permissioned Action Produce?

Record enough to answer who, why, what, under which authority, with what result.

Make evidence a condition of permission: if a consequential action cannot be attributed, reconstructed, and verified under the organization’s retention requirements, do not authorize it.

When products are being procured, send the same boundary to every vendor through the AI employee platform RFP checklist. Its permission questions require operation-level configuration, denied-action proof, exact approval binding, revocation behavior, and plan-specific identity controls rather than a generic “yes.”

Review at three cadences

Per action or batch: approval; exact effect; postcondition; exception; and recovery.

Per shift/week: denied attempts; approvals and rejections; action volume; unusual targets; retries; escalations; reviewer burden; and incidents.

Periodic access review: the role still exists; the owner and approvers are current; actions are still needed; connector/account scopes are correct; limits match actual work; triggers are active and justified; dormant credentials are removed; and changes have been retested.

Monitor policy as well as behavior

NIST’s AI RMF Core calls for defined human-AI oversight roles, ongoing monitoring, documented risk treatment, incident response, recovery, change management, and decommissioning.

Track whether the permission policy itself is still appropriate - not only whether the worker stayed inside it.

§ 13How Do You Revoke, Reduce, and Retire Access?

Revocation is part of the permission design, not an incident-only feature.

Use layered revocation

Be able to stop:

1. one proposed action;
2. one active task/run;
3. one schedule or wake condition;
4. one connector;
5. one browser tab or profile session;
6. one Cowork/chat session;
7. one AI employee identity;
8. one tool class; and
9. the complete role.

Different failures require different scopes. Do not disable an entire organization when one connector is faulty if a narrower safe stop exists.

Preserve state before cleanup

Subject to legal, privacy, and security requirements, preserve: queued and active tasks; approvals; tool/action records; affected objects; before/after state; relevant context/version; handovers; credentials/connections changed; cost; and the incident timeline.

Then rotate or revoke credentials, disable triggers, contain downstream effects, notify the owner, and choose rollback, correction, or compensating action.

Reduce authority after a failure

Return from bounded execute to: approved action; prepare/draft; read-only; sandbox; or blocked.

Retest the failed and adjacent cases. Do not restore broad authority merely because the immediate output was corrected.

Decommission dormant roles

Remove: schedules; event subscriptions; queued tasks; connectors; service accounts; browser/desktop bindings; delegated authority; unused secrets; shared links; and stale approvals.

Transfer necessary records and open work to a named owner. An inactive AI employee with active credentials is still an access path.

§ 14Common Permission and Approval Mistakes

NIST’s Zero Trust Architecture focuses access decisions on protected resources rather than assumed trust from network location. The useful design implication here is to make access explicit and resource/action-specific; merely operating inside a corporate environment should not make an AI employee trusted.

§ 15Final Recommendation

Build permissions from the action outward. For each AI employee, write:

who + where + what data + which action + under what conditions + how much + whose approval + what evidence + how to recover

Then choose the lowest useful state:

Blocked → Read → Prepare → Approve then execute → Bounded execute

Keep high-impact, irreversible, sensitive, novel, scaled, or hard-to-detect work approval-gated or human-only. Give broader authority only after representative tests prove the worker, the human reviewer, the technical control, and the recovery path.

For CellCog, do not collapse employee permissions, connector scopes, Cowork auto-approval, and Browse my Chrome thresholds into one setting. Review each plane and verify the live configuration.

The best permission system does not maximize what the AI employee can do. It makes the useful action possible while making every other action unavailable, approval-gated, bounded, visible, or recoverable.