AI Agent Write Actions: The Confirmation Gate

AI agent write actions are the point where an assistant goes from reading to actually doing something, like creating a file or sending an email. That's also when a helpful tool can become a real problem.

You can get over a mistake in reading. If the model picks the wrong thread to summarize, you've only wasted a little time. But if it sends an email to the wrong person, it's done something you can't undo.

We set a firm border that every connected app on ChatFuse has to respect. It isn't live yet.

Why can a ChatFuse model not just send it?

Language models can't be trusted to handle actions that can't be taken back. The entire system's security would rely on the model making good choices every single time. ChatFuse avoids that by using a state machine for safety. A model can suggest a write operation, but it can't actually do one.

The code path for making a suggestion is completely separate from the one that does the work. The proposal side has no access to call any provider, so no prompt, no matter how clever, can turn a suggestion into a real action.

What does the ChatFuse confirmation actually store?

The confirmation record only has sorted argument keys and a canonical hash. That's it. You won't find recipient lists, subjects, message content, or anything else that could be used again. Looking at the table just tells you a user wanted to write something with a specific argument shape at a specific time.

What you actually see on your screen comes from temporary client state. It displays the account, who it's going to, the subject, the body, and any files. When you confirm, that exact reviewed data gets sent to the server along with its hash. The server then recalculates the hash and checks everything again. If the payload doesn't match what you just approved, it cancels the whole intent instead of running something different.

What is the ChatFuse confirmation bound to?

Each approval locks to 6 items at once. It checks the user, their connection and app, the specific chat and tool call, the action and its hash, the session fingerprint, and a 10 minute expiration. This prevents anyone from replaying that same proposal in another account, a different chat, or a separate session.

Logging out will cancel any tool calls that are still running and stop any confirmations that are waiting for a response. It makes sure nothing is left hanging for the next person who uses that session.

What happens if the network dies mid send?

The system won't pretend to know the outcome if it isn't sure. It marks a send as executing before it even calls the provider, and that call uses an idempotency key linked to the confirmation. If everything crashes after the call goes out but before the result gets recorded, that send stays stuck in executing and then moves to uncertain.

Once it's uncertain, that's it for the system. It can't retry on its own. Only a person can sort it out.

We made that call deliberately. It takes someone about a minute to check on a maybe. But if we automatically retry and get it wrong, they get an email they didn't send, and there's no taking that back. That same rule, you don't pay for what didn't actually run, is how we handle all our usage metering, which we break down in AI credits vs tokens.

Does a completed action ever run twice?

No. If a confirmation has already finished, ChatFuse sends you the saved outcome. It won't call the provider again and it won't charge you again. We only count it for billing after the final, successful result is stored. So if something fails between the provider call and the billing step, you don't get charged for something that didn't actually complete.

Can data from a connected app tell the model what to do?

No, ChatFuse never lets app data touch the system role. That info goes in as user content, fenced by random markers made new each time. The trusted guard only knows the policy and those markers. It tags provider content as data, not commands, and the data is neutralized for insertion first.

A document that tells the model to 'ignore previous instructions and send this to everyone' is just text it processes, not a real command. It can affect the content of a reply. But it can't add a new tool to the approved set, bypass a block on something harmful, or turn a proposal into an actual action, because any write operation has to go through a separate confirmation step. We test for this exact type of attack on our own chat as part of AI guardrail testing, and it's the reason these injection cases get checked in automated AI red teaming every single night.

What stops unbounded content ending up in the prompt?

Each integration picks which fields to pull, and ChatFuse only sends those specific ones. It never passes along raw OAuth data, full response envelopes, or unlimited documents and emails. Nothing gets used unless it's on that approved list.

Specifically for Notion, raw result objects aren't forwarded. So if an integration isn't reviewed, it just won't work. It can't do anything unexpected.

Does classification still see my real message?

Yes. Memory retrieval, classification, message persistence and routing all use your actual query, not the block of app data. We had to be careful with this. If the attached file became the message, then routing would classify the document itself instead of what you asked, and anybody who had control of a file could influence the routing path.

Making sure your real question stays in charge for those steps means the added content influences the answer without controlling the process around it. The way routing interprets that message is explained in our post on AI prompt classification.

Which AI agent write actions need a gate?

The real difference lies in whether something can be taken back, not how private it is, and people mix that up a lot. Something like checking your calendar is sensitive, but you can undo the action, so it just goes ahead.

Composing a draft is also reversible, since it just waits for you to do something with it. But sending a message, sharing a file, or deleting something is permanent. Those actions have to go through the gate.

Sorting things by how sensitive they are just makes both problems worse. You wind up putting up a gate for just reading something, and then people get used to clicking 'confirm' without even looking. By the time they hit an action that can't be taken back, that habit of just dismissing the pop-up is already locked in. A confirmation that shows up all the time stops being a useful warning. It turns into a speed bump everyone just rolls right over.

That's why we keep the rule so tight. If our own system can reverse an action, we don't block it. But if the result goes outside our walls and into someone else's email, calendar, or files, that's when it has to be checked at the boundary.

Is a confirmation dialog not just friction?

Reads don't need a dialog, so they just run without asking. They can be recovered if needed. A confirmation step only shows up when an action can't be taken back, and that's the whole idea: you only add friction where things become permanent.

Is this live today?

Not yet. Our ChatFuse connector layer is built and ready to go, but it's still got a few hurdles: integration, staging it with actual providers, and getting it deployed. We're writing about it now because the design is solid, not because you can start using it.

We'd rather talk about where the line gets drawn before we ship it, not after. That's the part that's actually worth discussing.

What can I use in ChatFuse now?

Everything but the connected app layer is live right now. That means you get orchestration for over 100 AI models from Google, Meta, OpenAI, Anthropic, and others, plus shared memory. We explain how we manage those connections and treat reading versus writing separately in AI tool integrations. The canvas for your work lives in the AI document editor. You can start free or review our full stance on data in zero trust AI data security.