Read-only AI: how to give an agent access without giving it write access

Short answer: A genuinely read-only agent is one where the mutating tools do not exist for that turn. It is not one that has been asked nicely to avoid them. In Crew Orbit, Ask mode's tool registry contains exactly four tools: search_knowledge, list_tasks, get_task, and load_guidance. Write tools are absent, so there is nothing for the model to call even if it decides to. Agent mode carries the full tool set behind approval cards on anything irreversible, external, or incomplete. Mode is enforced by registry shape, not by prompt wording.

Every AI adoption conversation reaches the same sentence, usually from the person who has to sign off. What stops it from changing something? It is the correct question. It is also the question most vendors answer badly. The usual answer is a system prompt with a line like “you are a read-only assistant. Do not modify any data.”

That is not a control. It is a request.

Why a prompt is not a permission boundary

A system prompt is text, delivered through the same channel the model is reasoning over. It sits alongside the user's message, alongside retrieved documents, alongside whatever the model reads from an external tool. It competes for attention with everything else in that context, and it has no mechanism to win.

So a prompt-based restriction fails in ordinary, non-adversarial ways long before anyone tries to attack it:

• Instruction dilution. Twenty turns into a conversation, the read-only line is far away and the user's request is right here. Models weight recency and specificity.
• Helpfulness pressure. The user says “just create the ticket.” The model was trained to be useful. One of those two forces was trained in. The other was pasted in.
• Indirect instruction. If the agent reads documents, pages, or issue text, that content is in the context too, and it may contain sentences that look like instructions.
• Unfalsifiability. You cannot demonstrate the restriction to an auditor. You can only report that it has not visibly failed yet, which is not evidence.

Compare that with a control enforced outside the model. If a tool is not in the registry for a turn, the model has no schema to fill, no name to emit, and no handler behind it. There is nothing to persuade. The restriction is not a belief the model holds. It is a property of the system the model is running inside.

This is the general lesson, and it is worth stating independently of any product: agent privilege should be a property of the execution environment, not a claim in the prompt. When you evaluate any agent platform, the question is not “how is it instructed?” but “what could it call if the instructions failed?”

What Crew Orbit's Ask mode actually is

Every turn in Crew Orbit carries a mode, ASK or AGENT. The two modes differ in exactly one way that matters: which tools are assembled into the registry for that turn.

Ask mode has four tools, and that is the complete list:

• search_knowledge: scoped retrieval over the knowledge library.
• list_tasks: the project backlog.
• get_task: a full work item including its description.
• load_guidance: pulls the body of a rule the model was only shown by name.

There is no create_task in Ask mode. Not a disabled one, not a guarded one. It is not present. If the model, for whatever reason, decides the right move is to create a work item, the interactive fallback that would invent that call is a no-op. Nothing happens, because there is nothing there.

Agent mode is the full tool set, and it is not unguarded either. Explicit, complete, reversible writes execute and report a result you can act on. A created work item comes back as a card with a link to open it, and an undo where undo is possible. Anything irreversible, costly, or external always shows an approval card. That covers starting a run, creating a project, and a write through a connected tool server. Those two tiers are a deliberate design: putting a confirmation dialog in front of a reversible action trains people to click through confirmations, which is how you lose the ones that matter.

Mode is a control, not a suggestion

The precision of the mechanism only helps if the mechanism cannot be talked around. So the surrounding rules matter as much as the registry itself:

• Mode is a composer control. A person sets it, visibly, next to the box they type in. It is not buried in settings and it is not inferred from phrasing.
• It is sticky per session. A conversation does not drift between privilege levels turn by turn. If you started read-only, you stay read-only until someone changes it.
• The default is inherited. It comes from a settings value that resolves organization → project, so an organization can set the floor and a project can specialize. That is the same inheritance shape as the rest of the platform's configuration.
• Privilege narrows, never widens. A saved command can pin its invocation to Ask, so a command written for summarizing cannot mutate anything even in an Agent-mode session. The reverse is impossible by construction: no command can widen Ask into Agent. That asymmetry is the point. The strongest thing anything in the content layer can do is take privilege away.

That last point is the one to test in any tool you are evaluating. Ask the vendor whether a saved prompt, a template, a slash command, or a rule can raise the agent's privilege. If the answer is yes, or is vague, then the content layer is a privilege-escalation surface. And the content layer is exactly the layer your least-security-minded user is editing.

What makes an approval a real approval

Agent mode raises the second half of the problem. Once a tool can write, consent has to be collected in a way that means something. Most implementations get this wrong in one of two directions: they confirm everything, or they confirm in prose.

A usable approval card states four things: what will happen, where it will happen, why it was requested, and the specific values a person can judge. It also expires. Expiry matters more than it looks. An approval request that waits forever becomes stale context: the person who eventually clicks approve is consenting to a decision made in a situation that no longer exists. In Crew Orbit an unanswered request auto-rejects after a few minutes, and offers to ask again. A double approval executes once and then reports a conflict rather than acting twice.

And the part that sounds like a UI detail but is really a security property: typing “approve” in the chat box is never an approval mechanism. Free text is not authorization. It cannot be reliably distinguished from someone discussing an approval, quoting one, or pasting a document that happens to contain the word. The same channel also carries model-influenced content. Approve and Reject are buttons. While a decision is pending, the composer says so.

A related distinction: sometimes the agent needs a value rather than permission, such as which project or which assignee. Then it asks for the value in a form, not in prose. A picker when there are options, a field otherwise. The model is not allowed to substitute a sentence for the control: if it asks in text which project you meant, the platform still renders the select. Asking for a value is not asking for consent, and blurring the two is how people end up approving things they did not read.

Read access is not write permission

One more boundary that gets collapsed in practice, and should not be. Retrieval access and write permission are different checks.

A person can search the knowledge library, read the backlog, and get full detail on a work item, and still not be allowed to create one. So an approval in Crew Orbit is consent, not entitlement: approving an action can still fail on a missing permission such as task creation. The agent never operates above the permissions of the person driving it. Approving a card grants the agent your intent, not a role you do not have.

This is the correct shape, and it is the answer to a question security reviewers ask well: does the AI have its own privileges? It should not. An agent whose permissions are a superset of its operator's is a privilege-escalation path with a friendly interface.

How to reason about agent privilege in general

Strip out the product names and a short evaluation checklist falls out. For any agent you are considering giving access to a real system:

• Where does the restriction live? In the prompt, or in the set of callable tools? Ask to see the tool list for the restricted mode. A vendor who can name it exactly has built it. A vendor who describes the instruction has not.
• What is the blast radius if the model is fully compromised? Assume the model does the worst thing it can. The honest answer is the set of tools in the registry. Nothing more, and nothing less.
• Can privilege be widened from inside? By a user, a saved prompt, a template, retrieved content. Every yes is an escalation surface.
• Is consent a control or a string? Buttons and expiry, or text matching.
• Whose permissions apply? The operator's, or a service identity that quietly outranks everyone.
• Is the granted privilege visible while it is active? A person should be able to see, without checking settings, whether the thing they are typing into can change anything.

None of this is exotic. It is the same reasoning that produced least privilege, scoped tokens, and separate read replicas. Apply it to a component that generates its own next action. The novelty of language models has made a lot of teams forget conclusions they already reached about every other kind of automation.

What are the honest limits?

Three things worth knowing before you plan a rollout around this.

The shipped default is Agent, not Ask. The default mode is a settings value, and it is seeded to Agent. If you want read-only to be what your team gets unless someone deliberately changes it, that is a setting you change at organization scope. It is not the out-of-the-box state. Worth doing on day one if your rollout is broad.

Read-only is not confidentiality. Ask mode restricts what the agent can change, not what it can read. Its read tools still reach everything the asking person is permitted to see: the knowledge library in scope, the backlog, work item detail. If your concern is that an answer might surface something a particular person should not see, the control for that is document scope and project permissions, not mode. They solve different problems and one does not substitute for the other.

Connected tool servers are a chat capability, not a run capability. Registered tool connections are available in Ask Crew Orbit, where their writes are approval-gated. They are not reachable from AI runs today. If a vendor conversation blurs those two, ask which one they mean. We would rather say it plainly here than have you discover it in a pilot.

Why this unblocks adoption

The practical value of a real read-only mode is that it changes who has to say yes. A read-only lane can be handed to the whole team, including product, support, design, and a new hire in week one. The worst outcome of a bad turn is a wrong answer, not a modified backlog. That is a decision an engineering lead can make without a security review, and it is how most teams should start.

Then, when the team has decided which workflows are worth letting the AI act on, Agent mode is a per-session escalation with approvals on the actions that deserve them. Not a platform migration. A control in the composer.

Where this fits

This post is about what the AI is allowed to do. Its counterpart is what the AI knows: see why your AI should cite its sources and say “I don't know”. For the surrounding access model, read how to manage AI agents across organizations, projects, and permissions, and for the procurement framing, governing AI changes before the pen test asks.

If “what stops it from changing something?” is the question holding up your rollout, the answer should be a registry, not a sentence. Start at crew-orbit.com.