Least Privilege for AI Agents: A Practical Access Model

§ 01Least Privilege at a Glance

The smallest useful grant is the intersection of what the role needs, what the current task needs, what the environment permits, and what current policy authorizes:

Effective authority = role ∩ task ∩ environment ∩ current policy ∩ principal authority

NIST SP 800-53 defines least privilege as allowing only the access necessary to accomplish assigned organizational tasks. NIST SP 800-207 on Zero Trust Architecture adds a useful operational principle: access should be evaluated per session, granted to individual resources, and limited to the privileges needed for the task.

For an AI agent, that per-task emphasis matters. A standing worker may receive new goals, revisit a queue, use multiple tools, and delegate subtasks over time. A grant that was appropriate yesterday may be excessive for the action requested now.

Use four default privilege states:

Approval is separate. An agent can be technically able to perform a bounded action while still needing a human decision for a particular case. The permissions and approvals model explains that decision layer; least privilege is about reducing the capability that exists before and after the decision.

§ 02What Least Privilege Changes for AI Agents

Traditional least-privilege programs often start from users, roles, applications, and service accounts. AI agents add three design problems:

1. The system may select tools and sequence actions dynamically.
2. Natural-language inputs and retrieved content can influence which action is proposed.
3. One agent may initiate work for another agent or use a human-connected account.

These properties do not require abandoning familiar access-control principles. They make precise enforcement more important.

Separate functionality, permission, and autonomy

OWASP’s Excessive Agency guidance treats excessive functionality, excessive permissions, and excessive autonomy as distinct contributors to harm. Its mitigations include removing unnecessary extensions and functions, avoiding open-ended tools where possible, minimizing downstream permissions, preserving user authorization context, and requiring approval for high-impact actions.

A prompt such as “only read customer records” addresses none of these layers if the connected identity can export, update, and delete records. Enforce the boundary in the connector, downstream system, account, policy engine, wrapper, or human-operated step.

Treat the agent as a non-human principal

An agent may act: as its own service or workload identity; on behalf of a named user; through a shared integration identity; inside an ephemeral runtime; through a browser session already authenticated as a person; or through another agent’s tool connection.

Record the full chain:

accountable principal → initiating user/system → agent identity → tool identity → target resource

If the downstream log shows only a generic integration account, preserve agent, task, session, approval, and principal context in a correlated event record.

Least privilege is not role-based convenience

Role-based access control can be useful, but a broad role such as marketing_manager may combine analytics read, contact export, campaign creation, audience upload, budget change, public launch, user administration, and integration management.

Break that role into task-relevant capabilities. A content-research agent may need analytics summaries and approved brand assets. It does not need ad-account billing, customer export, or user administration merely because those capabilities belong to the same human department.

Make the narrow path operationally complete

Least privilege fails when the approved path cannot actually complete the task. The organization then grants a broad emergency role, shares a human credential, or lets the agent improvise around the control.

Before launch, trace one normal task from trigger to accepted result:

If the agent needs a prohibited capability to work around a missing product feature, redesign the workflow. Do not grant arbitrary SQL because the application lacks a filtered report - create a restricted view. Do not grant mailbox deletion because the available connector bundles read and delete together - use a dedicated mailbox or a wrapper that exposes only read.

Useful denials should also preserve safe progress. When an action is blocked, return: the denied operation; the applicable boundary; whether a narrower action is available; the correct escalation owner; the evidence required for a new grant; and the task state while waiting.

Do not reveal secrets, hidden resources, or unnecessary policy details in the denial. The goal is to keep the agent inside the authorized path without teaching it to search for a bypass.

Separate normal work from elevation

Some roles occasionally need a higher privilege. Do not keep that privilege active for convenience. Design a separate elevation path:

1. The agent prepares an exact request tied to the active task.
2. Policy verifies that the privilege can be elevated for this action.
3. An authorized person or system approves the narrow grant where required.
4. A temporary credential or role becomes available.
5. The agent performs the single bounded action.
6. The system validates the result.
7. Elevated access ends automatically.
8. The event is reviewed independently if its consequence warrants it.

Routine work should continue through the non-privileged identity. NIST SP 800-53’s least-privilege control family includes using non-privileged accounts or roles for nonsecurity functions, restricting privileged accounts, reviewing privileges, and removing access after defined periods of inactivity. For agent operations, the practical lesson is simple: an identity used for ordinary research, drafting, or queue work should not stay elevated because one rare task needed more authority.

§ 03Map the Reachable Authority Before Granting Access

Start with the business task, then trace every place where the agent could read, change, transmit, spend, or delegate.

Model transitive reach

The first system is not the full boundary. A connected tool may reach other systems:

If an agent can read a password-reset email, access the browser profile, and change an account credential, those capabilities combine into more authority than any single grant suggests.

Calculate maximum credible impact

For each grant, ask: What is the most sensitive data reachable? What is the most consequential write action? What is the largest batch or spend possible? Which external recipients can receive output? Which permission can the identity change? Which credential can it retrieve or mint? Which other agent or workflow can it trigger? How quickly would misuse be detected? How would the effect be contained?

Use the AI employee risk assessment to decide whether the remaining authority is acceptable. Least privilege narrows exposure; it does not decide the organization’s risk tolerance.

§ 04Give the Agent a Distinct, Protected Identity

Do not operate a standing AI employee through a human’s day-to-day administrator account. A distinct identity improves attribution, revocation, policy enforcement, and access review.

Choose the right identity pattern

Google Cloud’s service-account security guidance recommends single-purpose service accounts, avoiding keys where possible, disabling unused accounts, using fine-grained policies, and applying temporary privilege elevation rather than giving one account every permission it might occasionally need.

AWS’s IAM security best practices similarly recommend temporary credentials for workloads, least-privilege permissions, conditions that further restrict access, and regular removal of unused identities, roles, permissions, policies, and credentials. These product-specific mechanisms differ, but the access pattern is portable.

Do not share a human credential

Sharing creates several problems: agent actions look like human actions; the agent may inherit unrelated access; revoking the agent disrupts the person; multifactor or device policy may be bypassed or weakened; secrets can be copied into prompts, files, or logs; the account’s future privilege changes silently expand agent reach; and the system may act after the person’s approval context has changed.

If a browser session necessarily uses a human account, restrict the browser workspace, logged-in domains, tabs, actions, and time. Do not treat “the user was already logged in” as authorization for every reachable action.

Protect credentials as high-value resources

The agent should not receive raw long-lived secrets when a managed or temporary identity is available.

Require: no credentials in prompts, memory, handovers, or generated artifacts; secret retrieval only at the execution boundary; credentials that cannot be exported where the platform supports that property; short lifetimes; audience and resource restrictions; rotation and revocation; masked logs; detection of unusual use; and separate emergency access controlled by humans.

The ability to read or mint a credential is often equivalent to the privilege behind that credential. Include it in the authority inventory.

§ 05Reduce the Tool and Function Surface

An agent cannot misuse a function it cannot reach. Remove unnecessary tools before trying to constrain their use with instructions.

Prefer narrow tools

Narrow interfaces improve both security and reliability. They reduce the number of parameters the agent must choose, allow stronger schema validation, and make expected postconditions easier to verify.

Separate read, prepare, execute, and administer

Do not group these actions: read a customer record; generate a proposed update; apply the update; export the dataset; delete the record; change who may access the record; and create a new integration token.

Administrative functions should stay separate from ordinary work. An agent that publishes approved content should not also manage CMS users, install plugins, edit templates, or change domain settings.

Guard open-ended tools

Sometimes the task genuinely requires code, shell, browser, or general research access. In that case, restrict: runtime and container; working directory; filesystem paths; command or operation families; network destinations; inbound and outbound data; package installation; subprocess creation; environment variables; credential access; execution time; tool-call count; compute and spend; result size; and persistence after the task.

The prompt-injection guide should treat retrieved pages, documents, email, and tool output as untrusted content. Least privilege makes the resulting control failure smaller; it does not prevent the manipulation itself.

Disable dormant functions

Remove: trial connectors no longer used; debug commands left enabled; write functions needed only during setup; old browser sessions; obsolete service accounts; unused OAuth scopes; temporary allowlists; abandoned child-agent tools; and emergency access after the event.

Dormant privilege is still privilege.

§ 06Scope Resources, Data, and Destinations

“Read-only” is not enough. Reading can expose personal data, customer communications, source code, financial records, contracts, credentials, strategic plans, or cross-tenant information.

Apply resource-level scope

Apply field and classification scope

An agent that summarizes support trends may need category, date, resolution, and product fields. It may not need names, email addresses, payment data, authentication details, private attachments, or agent notes.

Define: allowed classifications; allowed fields; prohibited fields; tenant/customer boundaries; geographic or contractual boundaries; retention and memory rules; redaction before inference; aggregation thresholds; export rules; and approved destinations.

Connect this to the AI memory privacy and retention model. A narrowly scoped read can become broad persistent exposure if unnecessary data is copied into memory, a handover, or an artifact.

Restrict destinations

Exfiltration and accidental disclosure depend on where data can go.

Validate destination identity at execution time. A saved contact, stale channel name, redirected URL, or copied address can change the effect of an otherwise valid action.

§ 07Bound Actions With Conditions, Limits, and Time

Static permission answers only “can this identity call this operation?” A production policy must also decide whether the current request is allowed.

Use conditional authorization

Evaluate:

allow = identity + task + resource + action + data + source state + destination + limits + time + incident state

Examples: allow draft creation only for an active task in the approved project; allow a CRM field update only when the record is assigned to the current queue and the source-of-record ID matches; allow an email draft only for the verified thread and no new recipients; allow a staging deployment only for the reviewed commit; allow read access only while the shift is active; or block all consequential actions while an incident flag is open.

Add per-action and cumulative limits

Include cumulative limits. Ten actions below a per-action threshold can still exceed the intended daily or customer-level exposure.

Make access temporary

Prefer: per-request authorization; task-bound grants; session-bound tokens; shift-bound access; just-in-time elevation; explicit expiry; automatic revocation at terminal state; and reauthorization after material state changes.

CISA’s hardening guidance recommends minimum necessary permissions, limited session-token durations, removal of unnecessary accounts, and ongoing account monitoring. For agent work, align expiry with the shortest unit that remains operationally practical.

Recheck at execution

Do not authorize only when the task begins. Before a consequential action: reauthenticate the acting identity; verify the object and destination; confirm the task is still active; confirm the policy version; confirm limits remain; confirm approval is valid where required; confirm no incident or pause is active; and bind the action to the current proposal.

This avoids using yesterday’s authority for today’s changed state.

§ 08Prevent Privilege Expansion Through Delegation

An agent that delegates should pass a task, not a credential bundle.

The child’s effective authority must be:

child authority = parent authority ∩ delegated task need ∩ child role policy ∩ current organization policy

Never use:

child authority = everything the parent can reach

Define the delegation contract

The AI agent task-delegation guide defines task ownership and return conditions. Least privilege adds the authority intersection that must hold across the same boundary.

Block authority laundering

Authority laundering occurs when a task reaches an agent or tool with broader access than the initiator could legitimately use.

Examples: a read-only agent asks an admin agent to change a record; a child agent uses a shared browser session that exposes unrelated accounts; an external agent calls an internal tool with a generic privileged key; a delegated research task receives the parent’s full memory; a workflow invokes a cloud function whose service identity is over-privileged; or a rejected action is reformulated as a new task to bypass approval.

Validate the principal and authorization chain at every handoff. NIST’s zero-trust model for cloud-native applications emphasizes application and service identities, not only user and network identity. The same idea applies when agents call agents.

Constrain downstream delegation

Set: maximum depth; maximum child count; permitted child roles; permitted tools; maximum aggregate spend; data-minimization rules; no further delegation by default; parent cancellation propagation; child access revocation at return; and complete parent-child event correlation.

If the platform cannot prove these boundaries, keep sensitive delegation blocked or pass a minimized artifact to a human-approved workflow.

§ 09Handle Broad Connectors With Compensating Controls

Some connected applications expose permissions that are wider than the task requires. Do not pretend a broad OAuth or application role is narrow. Record the gap and reduce authority elsewhere.

Use this order:

1. Choose a narrower connector scope or application role.
2. Create a dedicated account, workspace, project, folder, queue, or tenant segment.
3. Restrict the downstream account’s permissions.
4. Place a task-specific wrapper in front of the broad interface.
5. Move work to staging or a review queue.
6. Require human execution for the consequential step.
7. Increase monitoring and shorten credential duration.
8. Reject the integration if residual authority remains unacceptable.

Keep policy outside the prompt

Instructions should explain the role, but enforcement should exist where the action occurs: identity provider; application IAM; OAuth scopes; database privileges; filesystem boundary; browser or desktop workspace; network policy; tool wrapper; policy engine; approval gateway; or a human-operated execution step.

A model instruction is behavior guidance, not a substitute for denied access.

§ 10Test, Review, Revoke, and Prove the Boundary

Least privilege is not complete when access is granted. It must survive normal work, error, manipulation, role change, and termination.

Test positive and negative cases

Review actual privilege use

The AI employee audit-log guide defines the evidence needed to reconstruct grants, decisions, actions, and state changes. Access review needs that event history; a current permission snapshot cannot show how authority was used.

Revoke on lifecycle events

Revoke or re-evaluate when: the task completes or is cancelled; the shift ends; a user withdraws the request; the employee’s role changes; a tool or connector changes; the resource owner changes; data classification changes; the approval expires; the agent delegates or returns work; a credential may be exposed; an incident occurs; or the role is paused or retired.

Test revocation. Verify the agent cannot use an existing session, refresh token, browser cookie, cached credential, child task, or queued action after the boundary closes.

Connect failures to the AI employee incident-response plan: pause work, revoke credentials, contain affected resources, preserve evidence, assess impact, correct unsafe state, and recover deliberately.

§ 11How to Apply Least Privilege in CellCog

CellCog publicly describes AI Employees as standing workers with goals, permissions, schedules or wake conditions, task boards, memory, handovers, approval expectations, connected tools, browser or desktop access, and delegation to other AI Employees. Each capability creates an authority surface the organization must configure deliberately.

Configure in this order

1. Define the task and accepted outcome.
2. Identify required sources and outputs.
3. Choose a distinct agent or connected-system identity.
4. Connect only the required system.
5. Narrow resources and data in the downstream system.
6. Enable only required functions and actions.
7. Add conditions, limits, and expiry.
8. Place human review at consequence and uncertainty boundaries.
9. Test denied actions and revocation.
10. Expand only after accepted work proves the current boundary.

CellCog’s AI Employees page describes connected work across applications and persistent shifts. Verify the live product and connected application before relying on a particular scope, approval, or revocation behavior. A platform-level permission cannot narrow a downstream account that already has unnecessary authority unless an enforcement layer actually applies that restriction.

When using Cowork or browser access, grant the minimum access required, review sensitive actions, and understand that file, page, session, or command output may be transmitted for AI processing. Keep credentials and unrelated accounts outside the permitted workspace.

Users set the employee’s goals, schedule, permissions, and connected accounts, and remain responsible for monitoring its work and the actions it takes on their behalf.

§ 12Final Checklist

• The agent has a distinct and attributable identity.
• The accountable principal and full identity chain are recorded.
• No broad human or administrator credential is shared by convenience.
• The role and current task define the access need.
• Environment, system, resource, record, field, and classification scope are explicit.
• Only required tools and functions are exposed.
• Read, prepare, execute, delete, export, and administer are separate permissions.
• Open-ended shell, browser, SQL, HTTP, code, and filesystem access has additional boundaries.
• Destinations, recipients, and external sharing are allowlisted where possible.
• Per-action and cumulative volume, rate, spend, runtime, and retry limits exist.
• Access expires with the task, shift, session, approval, or defined time.
• Credentials are temporary and non-exportable where supported.
• Secrets do not enter prompts, memory, handovers, logs, or artifacts.
• Authorization is rechecked before consequential execution.
• Child agents receive a narrow authority intersection, not the parent’s full access.
• Downstream delegation is blocked unless explicitly required and tested.
• Broad connector gaps have documented compensating controls.
• Required actions succeed in tests, while adjacent and prohibited actions fail.
• Grant, use, denial, elevation, delegation, and revocation events are reconstructable.
• Unused identities, tools, functions, scopes, credentials, and sessions are removed.
• Revocation ends active sessions, refresh paths, queued work, and child authority.
• A failed boundary invokes pause, containment, evidence preservation, and recovery.

Least privilege is not a one-time connector setting. It is a continuously enforced relationship between an identity, a task, a resource, an action, and the authority that still exists at that moment.