Read-Only by Default: The Safest AI Asks First

A read-only AI assistant reads across your connected tools and answers questions, but it never sends, edits, or deletes anything on its own. When an action would change the outside world, an email, a Slack message, a status update, it stops and shows you a draft. Nothing leaves your control until you tap confirm. That single boundary is what makes an AI safe to point at your whole company.

Read vs. write: the distinction that matters most

Every action an AI takes falls on one side of a line. Reading pulls information in: it searches your inbox, scans a Notion page, checks a HubSpot deal, reads a Stripe invoice. Nothing in the outside world changes. Writing pushes information out or alters it: sending an email, posting a message, updating a record, deleting a file. Reads are recoverable by nature, worst case, the assistant surfaces something you already had access to. Writes are not. A sent email cannot be unsent. A deleted record may be gone. A message posted to the wrong channel is visible the moment it lands.

This asymmetry is the whole game. Most of the anxiety people feel about giving an AI access to their tools is really anxiety about writes. Holka resolves it by treating the two categories as fundamentally different permissions, not two flavors of the same thing.

Why 'read-only by default' is a product philosophy

Read-only by default means the assistant's resting state is observation. It can look across everything you connect and reason over it, but its hands stay off the controls until you explicitly hand over a specific action. This is a deliberate design stance, not a limitation we are apologizing for.

The alternative, an AI that writes freely and hopes for the best, optimizes for autonomy at the expense of trust. That trade is backwards for an internal company brain. The value of Holka is that it can read across Gmail, Slack, Notion, your CRM, Stripe, and 300+ other sources at once and give you an answer with sources attached. That value doesn't require write access. So write access stays off by default, and every write becomes an explicit, visible, one-tap decision instead of a silent side effect.

Put plainly: the assistant should be able to tell you everything and change nothing, unless you say otherwise.

What the AI can do without asking

Because reads don't alter anything, the assistant works freely inside that space. Without stopping to ask, Holka can:

• Search across all your connected tools in a single query
• Pull the current status of a deal, ticket, project, or invoice
• Summarize a long thread, document, or channel
• Cross-reference facts from multiple tools and reconcile them
• Answer a question and show which tool each fact came from, so you can verify it

That source attribution matters. A read-only assistant that cites its sources isn't asking you to trust a black box, it's showing its work. You see that the renewal date came from HubSpot and the payment status came from Stripe, and you can click through to check. Reading widely and transparently is exactly where an AI should be fast and unsupervised, because the blast radius is zero.

What always requires your one-tap confirmation

The moment an action would change something outside Holka, the assistant stops and waits. These always require your explicit confirmation:

• Sending an email or a Slack message
• Replying to a thread or a customer ticket
• Creating or updating a record in your CRM
• Posting, publishing, or modifying any shared content
• Anything that deletes, archives, or overwrites data

The pattern is consistent: the AI prepares, you approve. It does the tedious part, gathering context, drafting the right thing, addressing it to the right person, and then hands you a finished draft to inspect. Your judgment is the release valve. Nothing crosses the line from draft to done without a human tap.

Drafting an email or Slack message, then waiting for you

Here's how it works in practice. You ask Holka to reply to a prospect who went quiet, or to nudge a teammate about a blocked task. The assistant reads the relevant history, understands the context, and writes the message. Then it stops.

What you get back is a draft: the recipient, the subject, the full body, laid out for review. You can send it as-is, edit a line, rewrite it, or discard it entirely. Until you act, the message exists only inside Holka. It is not queued, not scheduled, not "about to go", it simply waits.

This is the difference between AI drafting before send and AI sending on your behalf. Both save you the typing. Only one keeps you as the author of record. When the message goes out, it went out because you decided it should, in the words you approved. That confirmation step protects what a model can't fully judge for you, your name, your relationships, and your read on tone and timing. It matters most where the stakes are highest, like a reply to a customer support ticket.

Contrast with autonomous agents acting unsupervised

The industry has been drifting toward autonomous agents, systems that take a goal and execute a chain of actions on their own, sending and changing things along the way without checking in. That's a genuinely different safety posture, and it's worth being honest about the trade.

An unsupervised agent optimizes for hands-off completion. Its failure mode is that a small misunderstanding compounds into real actions before anyone notices, the wrong email to the wrong client, a bulk update that corrupts records, an apology sent for a problem that didn't exist. There's often no natural checkpoint where a human could have caught it.

A human-in-the-loop AI inverts that. It does the same preparation work but inserts a deliberate pause at every irreversible step. You trade a few seconds of review for the guarantee that nothing surprising ships. For an assistant wired into your company's most sensitive tools, that pause is the feature. Holka is intentionally a safe AI agent in this narrower sense: fully capable of reading and reasoning autonomously, deliberately not autonomous about writing.

The confidence problem

Autonomy also assumes the AI knows when it's wrong. Models are frequently confident and mistaken at the same time. A read-only-by-default design doesn't depend on the model being calibrated about its own uncertainty, because the human check happens regardless of how sure the AI feels. Safety shouldn't rest on the model correctly doubting itself.

Scoped OAuth and encrypted tokens underneath

The confirmation model sits on an access model built the same cautious way. When you connect a tool, Holka authenticates through scoped OAuth, it requests only the permissions it needs, and where a tool offers read-only scopes, it uses them. You grant access in the tool's own consent screen and can revoke it there at any time. Connect Slack, Gmail, or your CRM and you decide the reach.

Underneath, the access tokens that make those connections work are encrypted at rest. Holka doesn't bulk-copy your data into a separate warehouse, your information stays in the tools that own it, and Holka reads it when a question calls for it. Combined, these choices mean:

• The connection itself is minimally scoped, not all-or-nothing
• Credentials are encrypted, not sitting in plaintext
• Your data stays in your systems, not duplicated into ours
• Every write is still gated behind your tap, on top of all the above

Read-only-by-default and scoped, encrypted access reinforce each other. One limits what the assistant would do; the other limits what it could reach.

Why this reassures risk-averse founders and IT approvers

The people who approve new software are paid to imagine the worst case. A founder wonders what happens when the AI misreads a customer's tone. An IT reviewer wonders what a compromised integration could touch. A read-only OAuth AI with confirmation gates gives both of them a clean answer: the realistic worst case is that the assistant reads something it shouldn't have surfaced, recoverable, bounded, and never destructive. It cannot quietly send, spend, or delete.

That's an easier thing to say yes to. The approval conversation stops being "do we trust an AI to act on our behalf" and becomes "do we trust an AI to read and draft, while a person stays in control of every send." For a tool meant to become the shared brain of a whole company, earning that yes, from the most skeptical person in the room, is worth more than the autonomy it gives up.