What is an app firewall for AI workers?
An app firewall decides which connected apps an AI worker may reach and at what level, so it holds only the access you granted, never your whole account.
Connecting an app to an AI agent usually means handing over an entire account. The app firewall exists so that is not the deal.
What "connect your account" normally means
| The usual deal | With an app firewall | |
|---|---|---|
| Scope granted | Everything the account can do | Per app, at Off, Read or Write |
| Who holds it | The assistant you are using | One worker, with its own key |
| Narrowing later | Disconnect and start over | Narrow it, the worker keeps running |
| Reach | Anything you can reach | Nothing you did not connect |
| Blast radius of a mistake | The whole account | One worker's granted level |
Off, Read, Write
Access is granted per app and per level:
- Off: the worker cannot reach this app at all.
- Read: it can look, and cannot change anything.
- Write: it can act.
Granting only the level the job needs is the whole practice. Worked through three real kits, the pattern is visible:
| Kit | Apps and level | Why |
|---|---|---|
| Engineering Pulse | github: Read | A digest reads; it never pushes |
| Executive Daily Briefing | calendar, email, tasks: Read | It summarises three sources and writes nothing back |
| Support Inbox Triager | email: Write, tasks: Write | Drafting a reply and filing a ticket are both writes |
Notice what each one does not have. The briefing worker touches three apps and cannot change any of them. The triager has no calendar access, because classifying a support message does not require your schedule.
This is why a kit states the apps and the access it wants before you take it. You approve a specific request rather than a blanket one.
Narrow it later, and the worker keeps running
Permissions are not a one-time setup decision. You can narrow or switch off any of it afterwards, and the worker keeps running with whatever is left.
That behaviour is deliberate and unusual. Most systems treat a revoked permission as a fatal error, which teaches people never to revoke anything. Here the worker degrades: it does the parts of its job it still has access for, and the receipt records what it could not do.
The practical effect is that you can start a worker at Read, watch a week of receipts, and grant Write once you agree with its judgement. Reversible decisions get made; irreversible ones get postponed forever.
What it protects against
Three distinct risks, worth separating because they need different answers:
- Blast radius. One key per worker with its own scope list means a worker that misbehaves misbehaves narrowly, and can be switched off without touching any other worker in the fleet.
- Scope creep. An agent given broad access will eventually use it in a way nobody intended, not through malice but because a model with a tool reaches for it. Access it does not hold is access it cannot reach for.
- Reachability. A kit cannot reach an account you have not connected. The publisher of a kit never gains access to your data.
What it does not do
Naming the limits is what makes the rest credible. The app firewall answers "which apps, at what level" and nothing else:
| Question | Answered by |
|---|---|
| Which apps, and Off, Read or Write? | The app firewall |
| Which people may it read about or contact? | Contact rules |
| What must never leave, whoever it goes to? | Redaction |
Write on email means the worker may send mail. It does not say who to. A support worker should be able to reply to customers and should not be able to email your board because a customer mentioned them, and access levels cannot express that difference: both are "send an email". That is why the three layers compose rather than overlap.
The failure mode it is designed around
The failure worth designing against is not a hostile model. It is a helpful one.
An agent under pressure to complete a task will use whatever is in reach. Give a triage worker Write on the CRM "just in case" and eventually a run will decide that updating a record is the helpful thing to do, and it will be right about half the time. Nobody wrote an instruction telling it to; it simply had the tool.
The mitigation is not a better prompt. It is not holding the tool.
It is not an upsell
The complete safety layer, the app firewall, redaction, contact rules, and one key with its own scope list per worker, ships on every plan, Free included, and is never tier-gated.
Charging for the controls that make autonomy safe would mean selling the risky configuration as the default and the safe one as an add-on. Manage connections on the Connected apps page, and see /pricing for what each plan does change.
FAQ
What access does an AI worker get to my accounts?
Only what you grant, per app and per level: Off, Read or Write. Every kit states the apps it uses and the access each needs before you take it, you approve each connection yourself, and a kit cannot reach an account you have not connected.
Can I take access away after deploying a worker?
Yes, at any time. Narrow a permission or switch one off and the worker keeps running with whatever is left, recording on its receipt what it could not do. It never quietly regains access you removed.
Does the publisher of a kit see my data?
No. Taking a kit mints a worker in your own account with its own key. The publisher wrote the instruction and the access requirements; they gain no access to the accounts you connect.
Is the app firewall included on the free plan?
Yes. The complete safety layer ships on every plan including Free and is never tier-gated, alongside contact rules and redaction.
Why not just tell the agent what it may not do?
Because an instruction is a request evaluated by a model against every other pressure in its context, and a helpful model under pressure can talk itself past one. An access level is enforced outside the model, so there is nothing to negotiate with.