Why an agent should not receive a normal employee account

An AI agent for email, CRM, or accounting is useful because it can do more than propose text: it can perform an action. That is also its main risk. A classification error, an ambiguous request, or an instruction embedded in an incoming email can become an actual message, record change, or data disclosure.

OWASP calls this excessive agency. The root cause usually has three parts: more functions are exposed than the task needs, the technical identity has overly broad permissions, and high-impact operations run without independent approval. A prompt alone cannot fix these conditions. Authority must be constrained in the tool and in the downstream system.

A common small-business shortcut is to connect the pilot with an administrator account because it makes setup easier. An agent that only needed to read new requests and draft a response can then send email, export the address book, or delete messages. If the model makes a mistake, infrastructure still sees a valid authenticated request.

The right design unit is not a “smart assistant.” It is a specific operation with an owner, defined input, data scope, and execution conditions.

Separate reading, preparation, and action

Split the workflow into three levels.

**Reading.** The agent receives only the data needed for its task: messages from one queue, open deals for one department, or inventory for an allowed warehouse. No mutation functions exist at this level.

**Preparation.** The model produces a structured proposal: request category, response draft, CRM field values, or a draft payment record. Normal software validates the result: allowed values, required fields, amount limits, recipients, and absence of secrets.

**Action.** A separate executor applies the approved change. It does not interpret free model text as a command. It accepts a narrow schema such as `create_draft`, `add_crm_note`, or `reserve_stock`. Sensitive operations require a person or an independent policy decision.

This separation does not remove automation. Most routine work stays automatic, while a model error is stopped before an irreversible step.

A permission matrix for three familiar systems

Before integration, create a small table. Each row is a tool; columns define the object, action, data scope, authority lifetime, and approval rule.

For an email triage agent, a reasonable set is:

  • read only the incoming request folder;
  • search only the support knowledge base, not the entire file store;
  • create a draft but never send it;
  • exclude other mailboxes and restricted attachments;
  • send only after employee review.

For CRM:

  • read open opportunities in the agent's department;
  • add a note and propose field values;
  • prohibit ownership changes, deletion, and bulk export;
  • rate-limit record changes;
  • require approval for discounts, closed status, and personal-data transfer.

For accounting:

  • retrieve an approved subset of counterparties and reference data;
  • create a document in draft status;
  • never post the document or sign a payment;
  • enforce amount and counterparty rules in the accounting system;
  • link every proposal to the person who approved it.

If a vendor API cannot separate these privileges, a protective adapter should expose only narrow methods of its own. A universal “execute any request” function or shell access creates an unnecessarily large error boundary.

Where tokens should live

API keys, passwords, and OAuth tokens do not belong in the system prompt, knowledge base, or conversation history. Model context is designed for reasoning and can appear in traces, memory, tool responses, or later steps of a multi-agent chain.

Keep secrets in a secret manager or protected executor configuration. The model receives the operation name, not the credential. The executor injects authority only after server-side validation of the user, task, and allowed scope.

A practical baseline includes:

  • a separate technical identity for every agent and environment;
  • different tokens for email, CRM, and accounting;
  • short token lifetime and a tested revocation procedure;
  • token binding to a specific resource and audience validation;
  • no forwarding of an inbound token to a third-party API;
  • removal of authorization headers and secret fields from logs.

MCP security guidance explicitly forbids token passthrough. A server must not forward the token it received to a downstream system. Access to an upstream API requires a separate token issued for that resource. This limits the impact of leakage and makes revocation more precise.

Approval must describe the action

A button that says “allow the agent to work” is too broad. The employee should see exactly what will happen: recipient, amount, changed fields, source data, and the reason for the proposed action.

Classify operations by risk:

  • low: read reference data, find a document, add an internal label — automatic;
  • medium: create a draft, reserve stock, update a noncritical field — policy-controlled and logged;
  • high: external sending, deletion, payment, permission change, or bulk export — mandatory human approval.

The agent must not decide whether its own action needs approval. Risk class belongs in the tool registry and is enforced by the executor. Otherwise a model can accidentally, or under influence from input data, label a dangerous operation as safe.

Approval itself should not become ceremonial. The screen must present the final action, and any parameter change must create a new approval request. One button for ten unrelated operations saves seconds but removes accountability.

Audit logs should answer questions, not collect everything

A useful audit record reconstructs the chain: who initiated the task, what data was available, which policy version applied, which tool was called, what the model proposed, who approved it, and what the downstream system returned.

Do not put tokens, full personal records, or entire documents in logs without a clear need. Store identifiers, version hashes, masked values, and references to protected storage with separate access control.

Simple warning signals include:

  • an unusual volume of calls to one tool;
  • attempts to access forbidden objects;
  • repeated privilege-elevation requests;
  • actions outside the workflow or expected time;
  • an increase in proposals rejected by employees;
  • a mismatch between task user and target-object owner.

Rate limits do not prevent an error, but they reduce its scale and provide time to stop the workflow.

Local models still need access control

Local inference reduces data transfer to an external provider, but it does not automatically make an agent safe. A model inside a private network can still receive a malicious instruction from an email or document and call an internal tool with excessive privileges.

Locality answers where text is processed. Authorization answers what the system can do. A production design needs both: network and data segmentation, minimum privilege, an independent executor, approval, and audit.

For sensitive processes, separate the reasoning plane from the action plane. The model creates a structured proposal in an isolated zone. A small deterministic service validates the schema and policy, then sends the permitted operation to CRM or accounting.

A two-week pilot

Start with one process and one reversible action. For example, the agent reads support requests, retrieves a knowledge-base article, and creates a response draft. Sending remains with the employee.

During week one:

  • collect 20–50 real scenarios, including errors and malicious embedded instructions;
  • build the tool and permission matrix;
  • create separate technical identities;
  • define approval and audit fields;
  • configure rate limits and emergency revocation.

During week two, run the scenarios in a copy or test environment. Measure not only response accuracy but also the share of dangerous actions blocked, review time, false privilege requests, and audit completeness.

Move to production only if the agent consistently saves time and every failure remains inside a predefined damage boundary. If useful output continually requires an administrator token, the problem is integration architecture, not model quality.

Management takeaway

Do not grant the agent full employee permissions “just in case.” Define one business operation, give it a separate narrow tool and identity, and keep external sending, money movement, deletion, and access changes behind human approval.

The first practical step is to inspect the current pilot: which methods are actually visible to the model, and whose account executes them? That check takes less time than another prompt revision and usually reveals the biggest risk sooner.