AI Agents Need an Action Gateway: A Safe Architecture for CRM and ERP

An agent becomes dangerous when it receives a button

A business usually starts with a harmless assistant: find a customer in CRM, check inventory, or draft an email. Tools are then added—create an opportunity, change a price, post an accounting document, or send a message. At that point, the language model stops being only a text generator and becomes a participant in a business process.

The wrong response is easy to formulate: “improve the prompt so the agent does not do anything extra.” Prompts help behavior, but they are not an access-control boundary. A model can make an error, misunderstand an ambiguous request, or process a malicious instruction from an email or document. Constraints must hold even when model output is wrong.

NIST describes agent systems along two axes: tool permissions—read-only, constrained write, or broad write—and environment trust. RAG over internal material with read-only access is fundamentally different from a computer-using agent that operates on the open internet and changes system state. Wider permissions and less trusted environments require stronger technical constraints.

The practical small-business conclusion is simple: do not give the model direct access to CRM, ERP, email, or a database. Place an action gateway between them. The model creates a typed proposal, while ordinary software verifies permissions, limits, duplicates, required approvals, and only then calls a narrow operation.

Three independent reasons to constrain an agent

OWASP describes Excessive Agency as excessive functionality, excessive permissions, and excessive autonomy. These causes should be handled separately.

**Excessive functionality.** An email module used for drafting can also send and delete messages. Even if the account is limited, an unnecessary function increases the consequences of an error.

**Excessive permissions.** A product-search tool connects to a database identity that can change prices and delete rows. The model may only call a search function, but the intermediary still carries dangerous privileges.

**Excessive autonomy.** A function and its permissions are genuinely needed, but it executes without approval: email is sent, a discount is applied, or a payment document enters a final state.

Different controls address these layers. A narrow tool catalog reduces functionality. Separate service identities and object-level rights reduce permissions. Previews, limits, and human approval reduce autonomy. One “security system prompt” replaces none of them.

Action-gateway architecture

A production environment can use eight components.

1. User context

Every request is tied not only to an agent but to the employee on whose behalf it acts: role, department, customer portfolio, and current session. A shared privileged account erases boundaries, allowing a sales representative to see another portfolio or support staff to gain financial functions.

For a remote MCP server, the specification requires token-audience validation and prohibits passing the inbound token through unchanged. The gateway obtains a separate token for the target API with the correct audience and minimum scopes. Tokens never enter model context or conversation history.

2. Read-only planner

The model reads allowed context and selects an action to propose. It does not change data at this stage. The output is not SQL, a URL, or a shell command, but an object under a strict schema, for example:

```json
{
"action": "crm.create_followup",
"customer_id": "c_1842",
"due_date": "2026-08-19",
"reason": "client requested a callback"
}
```

The `action` value comes from a short list. The customer identifier must exist in an already authorized set. The date passes format and business validation. The `reason` is shown to a person but never executed as an instruction.

3. Schema validator

Ordinary code checks types, required fields, string length, enumerations, and ranges. Unknown fields are rejected. The model cannot add `admin=true`, embed a second command in a string, or invent an arbitrary destination.

Structured JSON is not inherently safe. It merely creates a boundary where deterministic rules can operate. Schema validation is followed by checks for object existence, status, relationships, and process constraints.

4. Policy engine

Policy answers questions that must not be delegated to the model:

• may this employee perform the action;
• is it allowed for this customer and department;
• are amount, discount, quantity, and deadline acceptable;
• is a second approver required;
• is the action valid in the document's current state;
• has a daily or per-minute limit been exceeded;
• is the target system a test or production environment.

A rule should return an understandable reason rather than only “denied.” Employees can then correct data or use the normal route, and the team can see which constraints most often block automation.

5. Preview and risk classification

The gateway shows the future effect: fields that will change, recipients, old and new prices, and documents to be created. For email, it displays recipients and complete content. For CRM, it shows a before-and-after diff. For ERP, it shows document type, legal entity, counterparty, amount, and status.

At minimum, actions are divided into three classes:

• **low risk:** create an internal task or draft;
• **medium risk:** change a reversible field or assign an owner;
• **high risk:** send an external message, change price, post a document, initiate payment, or delete data.

Low-risk actions may become automatic within narrow limits after a successful pilot. Medium risk requires explicit or batch approval. High-risk actions keep the target system's established approval process; a chat button must not bypass accounting or contractual controls.

6. Deterministic executor

The executor does not reason. It receives an approved command and calls a specific method such as `create_crm_followup`, never `run_sql`. Each tool has minimal functionality and a separate service role.

MCP recommends input validation, access control, rate limits, result sanitization, timeouts, and call logging. These controls apply regardless of protocol: MCP describes an interface, but does not replace API or database security.

7. Idempotency and queue

A network timeout does not mean an operation failed. Blindly repeating `create invoice` can produce a duplicate. Each business command receives a stable key derived from action type, object, and request version. The executor first checks whether the key has been processed and returns the previous result.

A practical design uses a transactional queue: the command and its audit record are saved together, then a worker delivers it to the external system. Reconciliation identifies stuck and partially completed operations. The agent does not decide whether to retry after an ambiguous response.

8. Audit and feedback

The journal records user, input request, model and policy version, proposed command, policy decision, preview, approval, actual API response, and final status. Secrets and unnecessary personal data are excluded.

Evaluation needs more than successful calls. Track rejected proposals, reasons, manual edits before approval, duplicates, rollbacks, and actions employees prefer to perform normally. These data reveal whether the agent saves time or creates a new review queue.

Business tools instead of universal interfaces

Dangerous interfaces look convenient: `execute_sql`, `run_shell`, `fetch_url`, or unrestricted `send_email`. They move almost all security into textual instructions.

Narrow tools describe business intent:

• `find_customer_by_phone` returns a limited field set;
• `create_callback_draft` creates an internal task without contacting a customer;
• `prepare_invoice_draft` creates an unposted document for an existing order;
• `request_discount_approval` creates a request rather than changing price;
• `send_approved_template` limits content and recipient;
• `attach_document_to_case` adds a file to one accessible case without deleting old files.

Such APIs take longer to build, but every action gains an owner, tests, and a damage boundary. For most small businesses, ten narrow operations provide more value than a universal agent with access to the entire desktop.

A local model does not remove action controls

Local inference addresses data transfer, latency, and dependence on an external API. It does not fix ambiguous requests, prompt injection, or incorrect tool selection. A model inside the perimeter can still post the wrong document when granted broad permissions.

A practical deployment keeps model, context, policy, journal, and gateway locally. CRM or ERP is reachable only by the executor in a separate segment. If an external model is used, it receives the minimum anonymized context and never sees tokens. Placement changes the data boundary, while least privilege remains necessary.

Modelled economics

Assume employees perform 300 repetitive actions daily. Finding an object, filling a form, and checking it takes four minutes. An agent reduces preparation to one minute, while 30% of actions need two additional minutes of review. The modelled calculation is:

• baseline: 300 × 4 = 1,200 minutes;
• with the agent: 300 × 1 + 90 × 2 = 480 minutes;
• modelled benefit: 720 minutes, or 12 hours daily.

Subtract narrow-tool development, integration, policy maintenance, audit, and exception handling. One incorrect payment or bulk message can erase a month of savings, so risk cost belongs in the model. These figures are illustrative rather than a measured company result.

A four-week pilot

**Week 1.** Select one reversible action: create an internal task for an existing customer. Record baseline time, errors, and user rights.

**Week 2.** Implement read access and a typed proposal without writing. Add schema, policy, and preview. Test invalid identifiers, other employees' customers, unknown fields, and malicious text in notes.

**Week 3.** Connect the deterministic executor in a test environment. Add an idempotency key, rate limits, audit, and a simulated network timeout.

**Week 4.** Allow writes for a small group with confirmation on every action. Measure completion time, edits, policy denials, duplicates, and rollbacks.

Expand to another tool when no critical errors occur, duplicates are blocked, employees understand the future effect, and time savings remain after review. Automatic external sending or document posting should be a separate stage.

The management takeaway is that an agent needs a short catalog of permitted intentions, not “system access.” Vnutrik may bring an entire key ring, but a production gateway should accept only one fitting key, verify its owner, and show a person which door will open.