How to Give AI Access to Company Systems

When a company connects AI to email, files, customer records, or other business tools, it decides what information the AI can see and what actions it can take. An AI agent is software that can choose and call tools, sometimes in sequence, to complete a task. For example, an agent might find a customer record, draft a reply, and send it.

Give the AI a distinct, limited identity, and make the software and services it connects to enforce those limits. A prompt can guide the AI, but it cannot reliably control what the AI is allowed to do. Before giving the AI more access, define its task and the data and actions it needs. Decide which identity it will use, and how you will review and remove its access.

Define the work before connecting tools

Start with one task and name the systems, records, and actions it requires. “Help with customer support” is too broad to set permissions. “Find a customer’s order status and draft a reply” is more specific: the AI needs access to relevant order records and a way to prepare a message. Sending that message requires a separate permission.

Some AI features use only information a person provides. Other designs retrieve company data or call tools such as email and customer-record services. Retrieval-augmented generation, often shortened to RAG, means software finds relevant company information and gives it to the AI to help answer a question. Tool use lets the AI request an action through a software function or a connection to another service. An agent may choose several tool calls and run them in sequence.

These designs create different risks. A retrieval feature needs to respect the requester’s permissions when it fetches documents. A read-only connection can still expose sensitive information if the AI can also send that information to an outside recipient. A tool described as a reader may expose editing or deletion functions. Review the actual operations a connection enables, rather than relying on a broad label such as “read-only.” OWASP identifies excessive tool functions, permissions, and autonomy as separate sources of excessive agency.

Give the AI an identifiable, limited identity

An identity is the person, service, or agent a company system recognizes when it checks whether to allow a request. Give each AI integration an identity that has a named owner and a documented purpose. Avoid hiding its activity under a shared employee login or an untracked credential. A distinct identity makes it easier to see what the AI did and to remove its access.

Some integrations use a dedicated agent identity. Others let the AI act with a person’s permissions, a pattern called delegated access. A dedicated identity supports task-specific permissions, but it can accumulate broad access if nobody reviews it. Delegated access can preserve a person’s access limits, but logs need to distinguish the AI’s actions from the person’s. Choose the pattern that fits the task and confirm that the connected services record who initiated each action. Microsoft’s guidance for AI-agent access recommends clear ownership and visibility into the permissions an agent receives across connected services.

Apply least privilege: give the AI only the permissions it needs. Limit access by action, such as reading, creating, editing, or deleting; by resource, such as a specific mailbox or group of records; and, where the platform supports it, by duration. An access token is a credential that lets software make requests to resources it has permission to use. The OAuth security best current practice recommends restricting tokens to the resources and actions they need, which limits the damage if someone misuses or steals one. NIST’s zero-trust guidance likewise treats access as a decision that should apply to specific resources, rather than granting broad trust based on a user or network location.

Enforce limits in software, not in prompts

Let the AI propose an action, but make the application and the connected service decide whether that action is allowed. For example, an AI might request access to a file or ask to send a message. The application should check the request against the AI’s identity and permissions, and the receiving service should reject requests outside those limits.

Give the AI narrow tools that match its task. A function that reads a specific customer’s order is easier to limit than a general tool that can search, edit, and delete customer records. Check that the AI sends valid values to each tool, and restrict where tools can send information when possible. Keep checks that decide whether a request is allowed outside the model. The model may misunderstand instructions. It may also encounter misleading content in an email, a document, or a web page. Google Cloud’s AI security guidance describes prompt injection, where untrusted content tries to redirect an AI’s behavior. Instructions to ignore such content can help, but they do not replace permission checks where tools accept requests and services provide data.

Match approval to the consequence

Require a person’s approval before an action that is sensitive or externally visible. Also require approval when it is costly or difficult to reverse. For instance, an AI can draft a customer email automatically while a person reviews it before sending. A useful approval screen shows the proposed action, its target, and the information involved. A generic “Approve?” prompt gives the reviewer little basis for judgment.

A person’s approval does not make an action safe by itself. A reviewer can miss a problem or approve without checking. Keep the AI’s underlying permissions narrow even when a person can approve an action. For low-impact actions, a direct permission check and a useful audit trail may be more appropriate than frequent approvals that people stop examining. Google Cloud’s guidance discusses risks in both human-approved and agent-only operation.

Log activity and practice revoking access

Record enough information to investigate what happened: the AI identity, the initiating person or task when available, the tool call, the target resource, the authorization decision, and the outcome. Check whether each connected service exposes those details; logging and attribution vary by product.

Assign someone to own the integration and review its permissions as the task changes. Test how to shut off access before relying on the connection: disable the AI identity, invalidate its tokens, and remove permissions from connected services. Microsoft recommends testing these controls and tracking what an agent can actually access. A list of AI connections also helps identify integrations that no longer have an active owner or business purpose.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com