Where the risk starts
A small company connects a locally hosted AI agent to its CRM: it finds customer records, drafts replies, and updates ticket status. The model runs in the company's own environment, so data is not sent to an external model API. Yet the integration uses a shared technical administrator account. In this arrangement, the account's permissions, not the model's location, define the possible damage. If the agent selects the wrong tool or treats untrusted text as an instruction, the CRM call still arrives with administrator privileges.
OWASP classifies excessive agent authority as Excessive Agency. Its examples include an extension that reads through an identity that also has write access, and a tool that acts for an individual user through a generic privileged identity. The business lesson is not to prohibit tools. Their authority should match the specific process, user, and action.
Three identities, not one “bot”
Separate three concepts in a typical integration:
- The employee on whose request the action runs. This person has a role, responsibilities, and access to particular customers or departments.
- The agent service. Its technical identity can call the tool gateway, but should not by itself grant access to every CRM or ERP record.
- The tool or action gateway. It checks the user, permitted operation, and data boundary before contacting the target system.
If the target system supports delegated access, an action can run in the user's context with the necessary limited scope. OAuth 2.0 Token Exchange describes a mechanism for one service to obtain a token to call another service on a user's behalf; actual support depends on the provider and target system. It is not a universal switch: older CRM and ERP systems may not support this pattern. In that case, the gateway must check the user's authority itself, while its technical account has only the minimum rights required for permitted operations.
A safer path for a write operation
Suppose a sales manager allows the agent to propose changing the next-contact date. A practical sequence is:
1. The application authenticates the employee and supplies their identity, department, and request context to the gateway. The agent must not invent these fields in its own output.
2. The model proposes a structured action, such as `update_next_contact` with a record ID and date. Free-form SQL or a universal HTTP call is unnecessary for this workflow.
3. The gateway fetches the record again and checks its department, the employee's role, allowed fields, and request validity. It checks immediately before the write, not merely when the conversation begins.
4. Sensitive changes—discounts, payment details, deletion, or bulk export—require a separate approval by an authorized person, or the agent is given no such operation at all.
5. After the write, the system records who initiated it, which tool ran, which record was affected, and what the CRM returned. Passwords, tokens, and unnecessary personal data stay out of the log.
This boundary matters more than a polished prompt. “Do not change someone else's records” can help guide the model, but cannot replace role and record-ownership checks in integration code. Test denials explicitly: a different department, expired session, repeated call, and an attempt to change a field outside the allowlist.
Secrets and the shared account
An inventory can start with a simple question: exactly which credential does each agent connector use? If one secret enables reading, modification, and export of all data, split the operations. Use a read-only identity with a limited data scope for lookups; use a separate, narrowly defined route for writes with an additional authorization check. Keep tokens in a proper secrets store, not in prompts, conversation history, or settings available to business users. Define expiry, revocation, and rotation. When an employee leaves, their former authority must not persist through a shared agent key.
Replacing one master key with several equally powerful keys only multiplies secrets. The goal is to reduce the maximum data and actions reachable through each connector. If the CRM cannot define separate roles and data limits, record that limitation as a risk and start with draft preparation rather than automatic writes.
Data, infrastructure, and economics
A pilot needs a map of user roles, CRM operations and fields, data owners, test records from different departments, a connector, and an audit trail of gateway decisions. The local model may run on an existing server; local inference does not solve authorization. Most additional work lies in the integration layer, role setup, and denial tests. A small company does not necessarily need a complex identity platform on day one: narrow down to one workflow and a small set of operations, provided reliable service code performs the checks.
Measure value by operator time per authorized operation, correction rate, and access-control errors—not by model call counts. Compare manual work, an “agent drafts only” mode, and automatic writes on the same sample. Include gateway development and maintenance, audit, and exception handling in the cost. If the volume of repetitive updates is low, human approval may cost less than full automation.
A small next step
Pick one workflow, such as changing the next-contact date. List every action the agent truly needs and, separately, everything it must never do. Create test records in two departments and exercise four negative cases: another team's record, an extra field, revoked access, and a repeated operation. Only then connect writes to the production CRM. The rule is simple: the agent may propose an action, but permission to execute it comes from a verifiable access-control system, not the model.