Roles, tools, and permissions

Learn how to give an AI agent enough access to help without giving it control of the whole business.

An AI agent should enter a business system like a team member with a defined role—not like an anonymous program with a master key.

Four ideas establish that role:

identity answers who or what is acting;
responsibility explains why it is acting;
permission defines which information and operations are allowed;
tools are the concrete capabilities it can use.

Connecting an agent to a tool does not automatically authorize every use of that tool. Telling an agent “do not send without approval” does not enforce the rule by itself.

Begin with a job description

Consider a lead follow-up agent. The name sounds clear, but it leaves important questions unanswered.

Owner: Which business and workspace own the agent, and who is accountable for its configuration?
Responsibility: Which measurable condition is the agent expected to advance or complete?
Context: Which customers, opportunities, fields, documents, and history may it read?
Tools: Which searches, drafts, record changes, and external actions may it request?
Autonomy: Which actions may proceed automatically, and which need approval?
Limits: How many records, messages, steps, minutes, or dollars may one run consume?
Escalation: Which uncertainty or exception should route the work to a person?

Once these are defined, “lead follow-up agent” becomes an operating role rather than a label.

Give tools according to responsibility

The agent may need to read assigned opportunities, review recent activity, create an internal task, draft a message, and ask for send approval.

It probably does not need to change billing settings, publish workflow changes, or read customers owned by another team.

Kind of tool	Example	A sensible boundary
Read	Retrieve one assigned opportunity	Limit records and visible fields
Propose	Draft a next action	Require a known format and supporting context
Internal change	Create a follow-up task	Validate owner, target, and duplicate rules
External action	Send an approved message	Require recipient, connection, approval, and budget
Configuration	Propose a workflow change	Separate proposal from publication

A smaller tool set improves security and often improves AI performance. The agent has fewer irrelevant choices and operators have a clearer boundary to review.

Reading and changing are different permissions

An agent that can see a customer should not automatically be able to change that customer. An agent that can prepare a message should not automatically be able to send it.

This separation supports a practical adoption path:

begin with read-only access;
allow structured proposals and drafts;
observe accuracy and corrections;
authorize narrow, reversible internal actions;
retain approval for consequential or external actions.

Autonomy grows around specific actions, not around the agent as a whole.

Permission follows the actor across interfaces

The same boundary should apply whether the agent retrieves information through the product, an API, a workflow, or an MCP tool.

Permission can be limited by:

workspace or client;
object and record;
field;
relationship;
action;
integration connection;
and configuration capability.

Sensitive fields may need especially narrow access. A leave-form agent might need an approved duration and limitation without receiving every clinical detail in the patient record.

Delegation should remain visible

Agent activity often begins with another actor. A person starts a workflow, the workflow invokes an agent, and the agent requests an action through an external service.

person requests the work
      ↓
workflow owns the responsibility
      ↓
agent prepares or requests an action
      ↓
runtime validates the request
      ↓
external connection performs the permitted effect

Each participant has separate authority. A person does not transfer every permission they possess simply by asking an agent for help. An agent does not inherit every capability of a connected service.

The history should preserve this chain so the business can understand who initiated, proposed, approved, and executed the work.

Agents need operating limits

Traditional permission answers “may this action happen?” Agents also need limits that answer “how much, how often, and for how long?”

A follow-up agent may be allowed to create tasks only for assigned records, with no more than one active follow-up task per opportunity. A research agent may have a time budget, source policy, and maximum number of searches.

Reaching a limit should create an explicit state. “Budget exhausted” is not the same as successful completion. The workflow can return partial work and ask a person whether additional execution is worthwhile.

Agent changes should be traceable

Changing the model, instructions, tools, permissions, threshold, or escalation policy can materially change behavior.

Runs should identify the configuration that was used. This makes it possible to compare results before and after a change and investigate a problem accurately.

Retiring an agent should prevent new work and revoke active credentials while preserving the history of earlier runs.

Instructions guide; the runtime governs

The prompt explains how the agent should reason. Identity, permission, tools, limits, approval, and history define what the agent is actually allowed to do.