Read-Only Access for AI Agents: Where It's Set

Read-only access for an AI agent is set in the credential each connected system issues, not in the agent or its prompt. In Insulin, an agent’s integration allowlist decides which systems it can reach, and each system’s own role, scopes, key or IAM roles decide what it can do there. Here is where that ceiling sits, system by system, and whether each documented setup can hold an agent to reading.

---

“Can it be read-only?” is the first thing an IT or security owner asks about an AI agent that will touch a business system. In Insulin, the answer depends on the system, because it isn’t stored in Insulin. Fours’ integration pages say whose permissions an agent’s tools run under, and read side by side they give one rule: Insulin picks the systems, and each system’s credential sets the ceiling.

The table below covers eight business systems whose pages say outright where that ceiling sits, plus the two switches Insulin controls itself. After it come the setting to narrow for each system, how to check what an agent can call, and the question read-only doesn’t answer: who can ask.

Where is read-only access for an AI agent set?

In the credential each system issues: a role, a set of scopes, a key’s permissions or a service account’s IAM roles. Insulin decides which systems an agent reaches, and the system decides what the agent may do there.

Three layers decide it, and the prompt isn’t one of them:

1. The allowlist picks systems, not tools. An integration allowlist is the list of connected systems an agent may use. Insulin’s Agents documentation calls it an “optional allowlist of connected systems the agent can use” and describes no per-tool setting, so putting Workday on an agent’s list gives it Workday’s tools, the one that submits time off included. Restricting which integrations an AI agent can access covers choosing the list.
2. The credential sets the ceiling inside each system. All eight business systems below connect at the organization level only. Organization agents “can only use org-level integrations”, while personal agents and the built-in assistant use user-level connections, so only an organization agent reaches these systems, through the organization’s connection. As Zuora’s page puts it, “Every Fours user in your organization shares the org connection.”
3. Insulin’s own switches cover two surfaces. Fours’ own MCP server has an Access level on its card, and each knowledge base attached to an agent has a Read or Edit mode.

An instruction such as “only read, never change anything” is something a model may follow. A permission the credential lacks is a call the system refuses, whatever the prompt says.

Which business systems can keep an agent read-only?

Four of the eight: Zuora’s tools only read, and BigQuery, Ironclad and Ashby can be narrowed to reading. Workday can partly, Lever’s page doesn’t say, and the documented setups for ServiceNow and Intercom can’t. Insulin’s own two switches can. The last column answers in each page’s own words.

System	What its agent tools can do	Who sets the ceiling	Can it be kept read-only, per its page?
Zuora	Read accounts, subscriptions, invoices and payments (6 actions)	The Zuora user the OAuth client is created under	Yes. The tool set is read-only, and the client’s Zuora role “sets the ceiling on what the agent can read”
BigQuery	List datasets and tables, read a table’s schema, run a standard SQL query (4 tools)	The service account’s IAM roles	Yes. BigQuery Data Viewer plus BigQuery Job User, per Google’s IAM documentation
Ironclad	Create and cancel workflows, record approval decisions, send signature requests; create and delete records, entities and webhooks (46 actions)	The OAuth client’s scopes, and the acting user fixed at connect time	Yes, by scope. Scopes are “per resource and action”, and “a missing scope makes the matching tool fail”, within the acting user’s permissions
Ashby	Create and update candidates and applications, move applications between stages, add notes; read jobs, interviews and org data (23 actions)	The org API key’s module permissions	Yes, per module. “Grant read access at minimum, plus write access for anything you want the agent to change”
Workday	Read workers, compensation, organizations, job requisitions and time off, run a WQL query, and submit a time-off request (15 actions)	The API client’s security-domain grants	Partly. Read-only “aside from submit-time-off-request”; the page describes no domain that separates reading time off from submitting it
Lever	Move opportunities through the pipeline; create and delete requisitions, notes and webhooks; create and deactivate users; read EEO responses (61 actions)	The org API key	Not described. The agent’s reach “matches that key’s permissions”, and the page doesn’t say how a key is narrowed
ServiceNow	Create, read, update and delete incidents, problems, change requests, users and groups; record approval decisions; place catalog orders (40 actions)	The roles of the user Fours acts as, which the Fours guide calls the OAuth Application User	Not by the documented setup. The guide’s minimum role, itil, already runs the incident, problem and change writes; only user and group writes need admin
Intercom	Read any conversation and reply to, close or reopen it; create, update and delete contacts, companies and articles (42 actions)	The app’s declared scopes, workspace-wide	No. Tools run “under the app’s declared scopes across the whole workspace”; the only control is leaving it off the allowlist
Fours’ own MCP server	Fours’ own tools: reading only, or also creating and changing data, or also deleting, by Access level	The Access level on its card, then your own Fours permissions	Yes. Read only is the default, and “Access only narrows the tools on offer”
Knowledge bases	Search, or also create, update and deprecate files (never delete)	The access mode on each attachment	Yes. Read mode retrieves and searches “for grounded context only”

How do you narrow each system to reading?

Narrow the credential where its Fours page says the ceiling is set. Where the page offers no read-only setting, leave the system off the agent’s allowlist, which, for an organization agent, only an org admin can change.

Zuora: read-only by design

Zuora’s tools can’t change anything: “no Zuora record can be created or modified through it.” The Fours guide has you create the OAuth client “under a user with the permissions you want Fours to operate with”, and Zuora scopes the client to that user’s role, so the role decides how much billing data the agent reads, not whether it writes. Narrowing it costs no silent wrong answers: “A call Zuora rejects surfaces as an error, never as an empty result.”

BigQuery, Ironclad and Ashby: narrow the credential to reading

• BigQuery. The query tool runs the SQL the agent writes, so the service account’s roles are the boundary. Fours’ setup suggests BigQuery Admin, BigQuery User or BigQuery Data Viewer. Google says a query job needs BigQuery Job User on the project and BigQuery Data Viewer on the tables and views it references, while BigQuery Data Editor can also update table data and delete tables. Setting up a query-only AI agent for BigQuery compares every role.
• Ironclad. Register the OAuth client with only the scopes you want the agent to have: “Ironclad’s scopes are per resource and action — for example public.workflows.createWorkflows — so a missing scope makes the matching tool fail.” Every tool also runs as the acting user, who “is fixed at connect time and applies to every request, for everyone in your organization”, and the Fours guide advises a dedicated Ironclad integration user rather than a real employee’s account.
• Ashby. The Fours guide says Ashby scopes API keys per module, such as Candidates, Jobs and Interviews: “Grant read access at minimum, plus write access for anything you want the agent to change.” Fours checks the key when you connect, but that check “cannot confirm you granted it every module the tools you plan to use will need”, so a module you forgot shows up later, when every tool for it fails.

Workday: read-only except one tool

“Aside from submit-time-off-request, these tools are read-only.” The ceiling is the API client registered with Workday’s Register API Client task, as the Fours guide names it, and “its security-domain grants set the ceiling on what the agent can reach”; a missing domain makes the matching tool fail. The guide’s examples are Worker Data, Organization Information and Time Off, and it describes no domain that separates reading time off from submitting it.

The typed tools aren’t the edge of what the agent reads, either. execute-wql-query is “the escape hatch for anything the typed tools don’t cover”, so the domains, not the tool list, bound what a Workday agent can read. If an agent must never submit time off, keeping Workday off its allowlist is the only documented control that holds on every surface.

Lever: not described

“All tools run under the org API key, so the agent’s reach matches that key’s permissions.” The page doesn’t say how a Lever key’s permissions are narrowed, and its 61 actions include creating and deactivating users, deleting notes and webhooks, and get-eeo-responses-pii, which returns EEO survey responses “including personally identifiable information”. Until you’ve confirmed in Lever what the key can do, treat a Lever agent as one that can write.

ServiceNow and Intercom: not read-only by the documented setup

• ServiceNow. Fours acts as the OAuth Application User you attach to the client, “so its roles set the ceiling on everything the integration can do.” The Fours guide asks for itil at minimum and names only the creation and deletion of users and groups as needing admin too, so the documented minimum already runs the tools that create, update and delete incidents, problems and change requests. Its recommended Auth scope limits the client to four ServiceNow APIs, among them the Table API that holds those records, and with scope enforcement turned off, the guide says, “the role is the only boundary.”
• Intercom. “An Intercom access token carries the permissions declared by the app, applied across the whole workspace — not the role of the admin who authorized it.” Every tool runs under those scopes, “so the agent can read any conversation regardless of who it is assigned to”, and the tools include replying to conversations and deleting contacts, companies and articles. There is nothing on your side to narrow: an agent that must only read can’t have Intercom on its allowlist.

Fours’ own MCP server and knowledge bases: Insulin’s own switches

• Fours’ own MCP server, which the integrations catalog still shows under its former name, Suger, has an Access level on its card. Read only, the default, offers “only tools that read data”; Read & write adds every tool that creates or changes data except deletes; Read, write & delete offers every tool. “Access only narrows the tools on offer. It never widens what your Fours account may do: Fours still checks your permissions on every call.” MCP server connections are user-level, so each person picks the level for their own connection, and changing it means disconnecting and connecting again; a connection made before the choice existed counts as Read only. Only this card has an Access choice: “other MCP servers expose whatever tools they offer.”
• Knowledge bases take an access mode per attachment. Read retrieves and searches “for grounded context only”; Edit can also create, update and deprecate files, never delete them. The built-in Insulin assistant’s default selection, Automatic, searches every knowledge base you own, read-only, and in a channel, member agents are always read-only against the channel’s knowledge bases.

How do you check which tools an agent can call?

Ask the agent. Every agent can list its integrations and the actions each one supports: “the provider actions it exposes, each with a description and whether it is read-only.” Before you share an agent, ask it something like List the Workday actions you can use, and say which ones aren’t read-only. The integration pages also point to each connection’s Actions tab, under Settings → Integrations, for “the exact tool list for your connection”.

The list says what each tool does, not what your credential allows. A write tool on it can still fail when the credential lacks the permission, and a read-only tool reads whatever the credential reaches, as Workday’s WQL tool shows. The table above is the other half of the answer.

Read-only isn’t private: who can ask the agent?

Everyone who can reach the agent, and Insulin sets that audience through sharing, channels and jobs, not through the credential. Workday sees one API client, whoever asked: “Every tool runs under the registered API client.”

Take a Workday agent for Acme’s HR operations team. Only an org admin can create an organization agent, and only an organization agent can use Workday or be shared at all. If the API client’s domains reach pay, get-worker-compensation reads a worker’s compensation for whoever asks, and four paths decide who that is:

Path	Who can get what the agent reads	Who controls the path
Sharing the agent	Each person shared at USER or above, or everyone in the organization once it’s shared org-wide, as EDITOR or USER	The agent’s owner, or someone granted ADMIN on it
An organization channel	Every member of the channel, VIEWERs included, since everyone in a channel sees the same messages; anyone in the organization can preview a channel shared with the whole organization	The channel’s owner and admins add people; an agent not shared org-wide can be added only by its owner or someone with ADMIN on it
A recurring report	Only the job’s creator, not organization administrators, unless Planner scheduled the work in an organization channel, where every member of the channel sees it	Whoever creates the job
The Workday API client	No one through Insulin once it’s revoked: “Revoking the client in Workday immediately breaks the connection”	Whoever administers the API client in Workday

Three of those paths are easy to miss:

• An org-wide share opens the agent to the whole organization at once. Agents can’t be shared as VIEWER, and USER, the lowest agent role, can chat. An org-wide share also lets anyone who can use the agent add it to an organization channel where they hold EDITOR or higher.
• A channel answer is a channel message. In an organization channel, a message that mentions no one goes to Planner, which has no integrations of its own and assigns each part of the request to the member agent best suited to it. A pay question can reach the Workday agent without naming it, and every member sees the answer.
• Planner’s scheduled work is the exception to private jobs. A job is private to its owner, organization administrators included, but work Planner schedules in an organization channel belongs to the channel, and every member of the channel sees it.

To end access at the source, delete the integration under Settings → Integrations and revoke the API client in Workday, which the Fours guide says to do “if you want to cut access from that side.”

Will an approval card stop a write?

Don’t count on it. Insulin’s documentation says that “some tool calls pause for your explicit approval” with a Tool Approval Required card, and that the card “is offered only in an interactive solo chat in the web workspace, on the main thread.” In a channel, a Slack or Microsoft Teams DM, or a reply inside a sub-thread, it isn’t offered and the action isn’t held back. Where the approval gate is armed maps every surface. A permission the credential lacks is refused on all of them, which is why read-only belongs in the credential, not in the card.

Frequently asked questions

Can an AI agent have read-only access in Insulin?

Yes, for some systems. Insulin’s allowlist chooses which systems an agent can use, not which tools, so read-only comes from each system’s credential. Zuora’s tools only read; BigQuery, Ironclad and Ashby can be narrowed to reading; ServiceNow and Intercom can’t be, by their documented setup.

Can I give an agent some of an integration’s tools but not others?

Not in Insulin. The integration allowlist is a list of connected systems, and the documentation describes no per-tool setting. Inside a system, the credential decides which tools succeed: in Workday a missing security domain, and in Ironclad a missing scope, makes the matching tool fail.

Which integrations can’t be kept read-only?

By their documented setup, ServiceNow and Intercom. Intercom’s tools run under the app’s declared scopes across the whole workspace, so there is nothing to narrow, and ServiceNow’s minimum role, itil, already runs tools that create, update and delete incidents. Keep either off a read-only agent’s allowlist.

Who can see what a read-only agent reads?

Everyone who can ask it: people the organization agent is shared with at USER or above, the whole organization if it’s shared org-wide, and every member of an organization channel it belongs to. A job’s output stays with its creator, unless Planner scheduled it in an organization channel.

Does the tool approval card stop an agent from writing?

Don’t count on it. The card is offered only in an interactive solo chat in the web workspace, on the main thread. In a channel, a Slack or Teams DM, or a sub-thread, it isn’t offered and the action isn’t held back. A missing permission is refused everywhere.

How do I see which of an agent’s tools change data?

Ask the agent to list an integration’s actions: each comes with a description and whether it is read-only. Integration pages also point to the connection’s Actions tab for the exact tool list. The list shows what each tool does; the credential decides whether a call succeeds.

Takeaways

• The allowlist picks systems; the credential sets the ceiling. Insulin describes no per-tool setting, so read-only inside a system comes from its role, scopes, key or IAM roles.
• Four of the eight business systems can hold an agent to reading: Zuora by design, and BigQuery, Ironclad and Ashby by narrowing the credential. Workday can partly, and Lever’s page doesn’t say.
• ServiceNow and Intercom can’t by their documented setup, so an agent that must only read leaves them off its allowlist.
• Insulin’s own switches are Read only on Fours’ own MCP server and Read mode on a knowledge base.
• Read-only isn’t private. Sharing, organization channels and Planner’s scheduled channel work decide who sees what the agent reads, and the approval card guards one surface only.

Read-only is a property of each system’s credential; who can ask is a property of the agent. To see how Insulin agents are scoped to their systems, shared and handed to jobs, start with AI agents for any business workflow, and open Fours’ integration docs for each system’s setup before you narrow its credential.