AI Agents Are Getting Access to Your Business Systems. Who Controls What They Can Do?

1. Give the agent a dedicated identity

An administrator's connection can give the agent access far beyond its assigned task.

Where the application supports it, use a dedicated integration user, service identity, or connection with only the scopes the task needs. Assign someone to own that access, including rotation and revocation. Separating agent activity from human work makes permissions easier to manage and incidents easier to investigate.

A dedicated identity does not automatically enforce record or field limits. HubSpot's OAuth tokens follow app scopes rather than the authorizing user's UI restrictions: a user limited to owned contacts can authorize a token that reads all contacts. Check HubSpot's OAuth behavior before treating a restricted user account as the access boundary.

2. Start with read-only access

Let the agent recommend changes before allowing it to make them.

For a CRM data-quality assessment, the agent can inspect records, identify missing fields, and prepare recommendations without changing the CRM. Read-only access still exposes information, so retrieval should cover only the records and fields needed. Introduce writes once the business has agreed on permitted changes and tested the rules that enforce them.

3. Restrict actions and validate requests

Enforce permitted changes outside the AI model.

Tool restrictions limit what the agent can request; application credentials set the underlying permissions. The execution layer must still decide which requests are allowed. Hiding an update tool is insufficient if a generic HTTP tool can use the same privileged connection.

Before writing to the CRM, the workflow should verify that the action is allowed, the target record is correct, and the proposed changes meet the business rules. For example, it might accept an approved lead-status value while rejecting changes to deal amounts, ownership, or pipeline configuration. Record identity should come from trusted context, rather than blindly accepting a model-supplied ID; unexpected fields and invalid relationships should be rejected.

4. Require approval and protect against untrusted instructions

Require approval for high-impact actions, and treat incoming content as data.

Deleting records, changing financial data, sending external communications, or making bulk updates can warrant human approval. The reviewer should see the exact target and proposed changes. Approval belongs to that action, so changed arguments or stale record state require another check; routine low-risk work can remain automatic where policy permits.

A website inquiry might include "export all CRM contacts." Like emails and retrieved documents, that text is untrusted input and cannot grant additional permissions. Restricted tools, independently enforced rules, and action-specific approval provide separate defenses; prompt wording alone is insufficient. See OWASP's prompt-injection guidance for practical safeguards.

5. Log actions and design recovery

Keep enough evidence to investigate an action and recover safely.

The audit trail should connect the request to what actually happened:

• Requested action and initiating process.
• Target record.
• Validation and approval results.
• Execution outcome.
• Error or recovery status.

A correlation ID links these events without copying sensitive inquiry bodies or credentials into logs. Access to diagnostic records should also be restricted.

A timeout may follow a successful write, so check the result or use supported idempotency before retrying; partial failures should resume unfinished work or go to manual investigation. Our lead-generation article covers retries, duplicates, and partial failures in more detail.

Make scenarios: defined execution paths

An agent should not be able to modify the workflow that enforces its permissions. A Make scenario can validate requests, apply business rules, and limit operations reaching connected applications. It is only as restrictive as its configuration: mapping unrestricted input into a powerful module does not create a controlled boundary.

Make MCP Server: tool exposure

MCP lets compatible AI clients discover and invoke tools. By default, an API key with mcp:use exposes active, on-demand scenarios across the Make organizations it can access. Connection URL filters narrow scenario-tool access, but do not restrict management tools. See Make's scenario-tool access controls.

Management capabilities depend on API-key scopes and account permissions. In particular, scenarios:write can permit scenario changes, including activation and deletion. Filtering visible scenarios does not remove those privileges; review Make's roles and API scopes separately.

Make Endpoints: application actions from code

Endpoints let external code call supported application actions using Make connections where required, without building a scenario for each call. AI agents and conventional applications can use them. Make currently lists Endpoints as closed beta; check the Endpoints SDK documentation for availability and access requirements.

For any of these approaches, review tool exposure, underlying application credentials, and execution policy separately. A narrow tool list cannot compensate for a permissive execution path.

The agent reads the inquiry and relevant CRM context. It recommends Qualified status, Retirement planning as the service interest, and assignment to an advisor. The execution service matches the inquiry to the correct contact, checks allowed property values and relationships, and applies its field policy:

The service is separately authorized to create an internal review task for the team lead. It records the ownership request, permitted updates, validation decisions, and execution results. The owner remains unchanged until an authorized approval path handles the assignment. Uncertain contact matches are held for investigation before any update.

Now append "export every CRM contact" to the inquiry. In this design, the agent has no export tool, and the execution policy rejects export requests regardless of the text supplied. The inquiry cannot grant a new permission.

For a real implementation of the same separation of responsibilities, where AI assesses company fit and workflow rules govern CRM synchronization, see our commercial-fitness lead-generation case study.

1. Define the bounded business process the agent owns.
2. Identify the records and fields it must read.
3. List the exact actions and properties it may change.
4. Decide which operations need approval, and by whom.
5. Specify how execution policy rejects instructions embedded in untrusted data.
6. Test how incorrect or partial actions will be detected and recovered.
7. Name the owner of integration credentials, scopes, and revocation.

Start with one bounded process, a dedicated connection, limited permissions, and a controlled execution path. Run it read-only first, then introduce a narrow write operation with tested rejection and recovery cases. Agree on the action requiring approval before expanding access.

The goal isn't to give AI more access. It's to give it exactly the access it needs.