Who Can Read Your AI Agent's System Prompt?

An AI agent’s system prompt is the set of instructions that defines its behavior, personality and constraints. In Insulin, everyone an organization agent is shared with can read it: anyone below Editor sees the agent’s full configuration read-only, and an org-wide share extends that to the whole organization. Write the prompt for its widest audience, and keep credentials and restricted data out of it.

---

“If I share this agent with the team, can they read its instructions?” is worth asking before the share rather than after. In Insulin the answer is yes, and Fours’ documentation says so plainly: when your role on a shared agent is below Editor, “you see the full configuration, but every control is disabled so you can’t change it.” The system prompt is part of that configuration.

That’s a sensible design: a team that depends on an agent should be able to see what it was told to do. It does mean a prompt is configuration, not a secret, and whatever it holds, it holds for everyone the agent reaches. Writing reliable instructions for an enterprise AI agent covers what a prompt should say. This post covers who reads it, and what to move out of a prompt before you share it.

Who can read an AI agent’s system prompt in Insulin?

Everyone the agent is shared with, at every role. The Owner, Admins and Editors see the agent’s configuration with editable controls, and anyone below Editor sees “the full configuration” read-only. The Sharing Agents reference names what that configuration holds in its list of what an Editor can change: “system prompt, default model, knowledge bases, and — for org admins — the integration allowlist.”

Only Organization agents can be shared at all: “Personal (user-level) agents are private to you, and their Share button is disabled.” Creating an Organization agent takes an org admin, since that ownership option “is disabled for members who are not org admins.”

Who	How they get access	Reads the system prompt?	Can change it?
Owner	Creates the agent, or receives it by transfer	Yes	Yes, and only the Owner can delete the agent
Admin on the agent	Granted to a named person	Yes	Yes, and decides who else gets access
Editor	Granted to a named person, or by an org-wide share	Yes	Yes: the prompt, default model and knowledge bases, plus the integration allowlist if they’re an org admin
USER, shown as Member	Granted to a named person, or by an org-wide share	Yes, read-only	No
Everyone in the organization	An org-wide share, as Editor or USER	Yes, members with the VIEWER org role included	Only under an Editor share, and never a VIEWER

Read-only isn’t a partial view. Working with a Shared Resource says Editor, Admin and Owner “see the same view with editable controls,” so a Member also sees which default model the agent runs, which knowledge bases it searches and which integrations are on its allowlist.

Why does an org-wide share change the answer?

Because it gives the prompt to everyone in the organization at once, including people who can’t use the agent. Org-wide sharing grants Editor or USER, never Admin, and “everyone in the organization then gets that role automatically without an individual invite.”

That includes members whose org role is VIEWER. The Organization Roles reference says a VIEWER “can view agents, channels, and Custom Apps” that are shared, but “cannot start a chat.” An org-wide share therefore puts the agent’s instructions in front of people who can read them but can’t use the agent.

Two more paths lead to the same audience, or keep someone in it:

• An install from the Organization store. That store is shown only to org admins, and installing from it “creates an org-shared copy that is visible to your whole organization.” Installing an agent copies the catalog item’s system prompt into your workspace for you to edit, so an admin who customizes that copy is writing for the whole organization from the first save.
• A transfer of ownership. An Organization agent can pass only to a current org ADMIN, and the former owner drops to USER: “you can still use the agent.” A USER still sees the configuration read-only, so handing an agent over doesn’t take you out of its audience.

The audience is set by whoever holds Admin on the agent. Managing shares “requires the ADMIN role on the agent itself — the owner, or a teammate explicitly granted ADMIN — not merely being an org admin.” Who can run what in an AI workspace explains why running an agent and editing it should be separate grants.

Where else does a system prompt reach?

Three places no share list shows: the agent’s description, the model provider that serves each turn, and anyone who can ask the agent about itself.

• The description. You don’t write an agent’s description. “When you save, Insulin auto-generates the agent’s description by summarizing its system prompt — so an empty system prompt yields an empty description,” as Creating a Custom Agent puts it. Each save produces a fresh summary of whatever the prompt says, so a line that shouldn’t be summarized doesn’t belong in the prompt.
• The model, and the vendor serving it. A prompt is what the model follows, so it goes with every turn to whichever provider serves that turn. The AI Model Policy is where an org admin decides “which vendors may see our prompts.”
• Anyone who can ask. An agent can be asked about its own instructions like anything else. The OWASP Top 10 for LLM Applications lists this risk as LLM07:2025 System Prompt Leakage, and its position is plain: “the system prompt should not be considered a secret, nor should it be used as a security control.” Training a model not to reveal its prompt, OWASP adds, “is not a guarantee that the model will always adhere to this.” Insulin’s documentation doesn’t promise otherwise, and a prompt with nothing secret in it doesn’t need the promise.

The built-in Insulin assistant is the one exception: it “is built in and cannot be edited or deleted,” so there’s no prompt of yours in it to read.

What should you keep out of an agent’s system prompt?

Anything you wouldn’t show the agent’s widest audience, starting with credentials. OWASP’s first mitigation for LLM07 is to “avoid embedding any sensitive information (e.g. API keys, auth keys, database names, user roles, permission structure of the application) directly in the system prompts.” Each kind of content has a better home in Insulin. Take a renewals agent at Acme, shared org-wide as USER:

If the prompt holds…	For example	Put it here instead	Why
A credential	”Sign in to the billing portal as svc-renewals with password …”	An integration under Settings → Integrations, on the agent’s allowlist	The connection holds the credential, and an agent reporting on its integrations never returns one
Restricted data	”List prices rise 9% on January 1. Don’t mention it before the announcement.”	Nowhere this agent can reach. If a smaller group needs it, a separate agent shared with them by name	Every reader of the prompt sees it, and “don’t mention it” asks the model to enforce access
Numbers that change	”Current discount tiers: …”	A knowledge base, synced from the document the team maintains	A number in the prompt is only as current as the last edit, and only Editors and up can edit
A procedure	”To process a renewal: 1. Check the contract end date. 2. …”	A skill	Written once, available to any agent, and loaded when a conversation needs it
Who the agent is and how it behaves	”You’re Acme’s renewals assistant. Never confirm a credit amount; finance confirms credits.”	The prompt	That’s what a prompt is for, and none of it needs hiding

Moving a line out of the prompt is about upkeep, not secrecy. A knowledge base has sharing of its own, and “your org role does not, by itself, grant access to any organization knowledge base.” But a custom agent searches the knowledge bases attached to it when it answers, so treat what an agent can retrieve as something the people who chat with it can ask about. If a reader of the prompt shouldn’t see something, moving it to a knowledge base or a skill doesn’t fix that. Keeping it away from this agent does.

That is also OWASP’s answer when people need different access: “if those tasks require different levels of access, then multiple agents should be used, each configured with the least privileges needed to perform the desired tasks.” In Insulin, that’s a second Organization agent, shared by name rather than org-wide. Why procedures belong in a skill rather than the prompt is covered in the difference between agents and skills.

Where do an agent’s credentials belong?

In an integration connection. The agent’s configuration then names the system on its allowlist, and the credential stays with the connection. For an organization agent, that takes three steps:

1. An org admin connects the system under Settings → Integrations, in the Organization group. Any member can view that list, “but only an org ADMIN can connect or disconnect them.” Most connectors are org-level, per the integrations overview: “one shared API key, OAuth app, or service account for the whole organization.”
2. The system goes on the agent’s integration allowlist, an “optional allowlist of connected systems the agent can use.” Org-level agents “can only use org-level integrations,” and only an org admin can change an organization agent’s integrations, which “prevents a shared agent from being quietly granted new organization-level tool access by someone without admin privileges.”
3. The agent can describe the connection without exposing it. Asked about its own integrations, an agent lists each one’s actions “plus non-secret connection details such as an account id or base URL. Credentials are never returned.”

A personal agent works the same way with personal connections, which “are per-user and are available only to your own user-level agents and apps.” Either way, what the agent can do in that system is bounded by the credential’s own permissions, not by anything the prompt says.

If a credential has already sat in a shared prompt, deleting the line isn’t the whole fix. Everyone who could open the agent could have read it, so rotate the credential with the system that issued it, and connect the new one as an integration.

What should you check before sharing an agent org-wide?

Read the prompt as the newest member of the organization would, then fix what you find before you turn the share on.

1. Read it as a Member. Anything you’d hesitate to show every colleague, VIEWERs included, comes out.
2. Search it for credentials: passwords, API keys, tokens, connection strings and service-account sign-ins. Each becomes an integration, and any that were already shared get rotated.
3. Take out restricted data. If a smaller group needs it, give that group its own agent, shared by name.
4. Move changing numbers to a knowledge base and procedures to a skill, so the prompt holds only behavior.
5. Pick the org-wide role. USER lets people chat with the agent without changing it; grant Editor by name to the few who maintain it.
6. Know who controls the audience. The Owner and anyone with Admin on the agent manage its shares; org admin status alone doesn’t.

Frequently asked questions

Can people I share an AI agent with read its system prompt?

Yes. In Insulin, everyone an agent is shared with can open its settings. The Owner, Admins and Editors can change the system prompt; anyone below Editor, a USER shown as Member, sees the full configuration read-only, system prompt included.

Does sharing an agent org-wide show its prompt to everyone?

Yes. An org-wide share gives everyone in the organization the Editor or USER role automatically, including members whose org role is VIEWER. A VIEWER can view shared agents but can’t start a chat, so the prompt reaches people who can’t even use the agent.

Can a personal agent’s system prompt be shared?

No. Only Organization agents can be shared in Insulin. A personal agent’s Share button is disabled, and personal agents are private to the person who created them.

Where should an AI agent’s credentials go instead of the prompt?

Into an integration under Settings → Integrations, added to the agent’s allowlist. An organization agent uses only organization-level connections, which only an org admin can connect, and an agent describing its integrations never returns credentials.

Can an AI agent be stopped from revealing its system prompt?

Don’t rely on it. OWASP’s guidance is that a system prompt “should not be considered a secret,” and training a model not to reveal it is no guarantee. Insulin’s documentation describes no such guard, so keep anything that needs hiding out of the prompt.

Does an Insulin agent’s description come from its system prompt?

Yes. You don’t type one: when you save, Insulin auto-generates the description by summarizing the agent’s system prompt, so an empty prompt yields an empty description. Anything the prompt says is material for that summary.

Takeaways

• Everyone an agent is shared with can read its system prompt. Below Editor it’s read-only, and an org-wide share extends it to the whole organization, VIEWERs included.
• Give each kind of content its own home. Credentials go in integrations, changing numbers in a knowledge base and procedures in a skill; restricted data goes nowhere the agent’s audience can reach.
• Don’t count on the model to keep a prompt private. Write it for its widest audience, and there’s nothing in it to leak.

A system prompt is one part of an agent’s configuration, alongside its model, knowledge bases and integrations. To see how those fit together and how an agent is shared with a team, start with building AI agents for any business workflow.