---
title: What it won't do
description: The limits Else actually has — enforced mechanically or written into the rules it runs under — and the limits we are not going to claim.
---

This is not a content policy page. Else has no published list of forbidden topics, and
we are not going to invent one so this page looks reassuring.

What we can tell you is the set of behaviours the system will not produce, and — more
usefully — which of those are enforced mechanically and which are rules it runs under.
The difference matters, so we have split them.

## Enforced, not requested

These hold regardless of how the request is phrased. They do not depend on the model
choosing to comply.

- **It won't reach private or internal network addresses.** Requests to internal hosts
  are refused before anything is fetched.
- **It won't take an app action we haven't cleared, without asking you.** The list is
  checked in the safe direction: an unrecognised or malformed action requires your
  approval rather than being assumed harmless. For apps without a per-action list, only
  read-shaped actions — searching, listing, fetching — proceed without asking; anything
  else stops.
- **It won't ask you to raise its own spend limit.** A run that tries to request more
  budget for itself is rejected on our side before it reaches you. This exists because
  it once happened, with invented numbers attached.
- **It won't pass a hand-built layout off as a generated image.** When image generation
  isn't available, what you get back carries a plain statement that it is a
  design layout rather than a generated image — attached by the system, not left to the
  model to admit.
- **When it can't confirm a capability is available, it treats it as unavailable.** Our
  check on image generation expires after 14 days; once it is stale the capability is
  reported as off rather than optimistically attempted.

## Written into the rules it runs under

These are instructions Else operates under on every run. They shape behaviour reliably
and we can show you the wording, but they are rules rather than physics — treat them as
strong commitments, not as mechanical impossibility.

- **It won't claim it can do something it can't do right now.** A reply that answers
  directly, with nothing switched on, is told in so many words that it cannot browse the
  web, open your files, act in your connected apps, or run anything in the background —
  and must say so rather than promise to "go and check".
- **It won't blur "this feature exists" with "you connected it".** Those two are kept
  distinct on purpose, so you never get a confident answer about an account you never
  linked. Internal identifiers are stripped out of what you read.
- **It won't invent the contents of a document it couldn't read.** A scanned,
  image-only file with no text in it comes back empty with a warning. That empty result
  is treated as an honest outcome to report, not a failure to paper over.

This behaviour does show up in real work. A finished task ended by flagging, unprompted,
that it had not managed to save one of its files and that part of its research had been
stopped by the spend limit — neither of which we asked it to disclose.

## What we are not claiming

We are not claiming a topic blocklist, a certified safety review, or that nothing
unwanted can ever come out of a run. There is no list of refused subjects behind this
page, so there is none to show you.

The guarantees we will stand behind are the ones above, plus two on other pages: it
stops and asks before anything leaves the app — see
[When it checks with you](/docs/when-it-checks-with-you) — and it never quietly raises its
own budget. Note what that second one is *not*: it is a guarantee about the model's
behaviour, not a guarantee that the number you set is enforced. On a chat nothing acts on
that number at all, as [Spending limits](/docs/spending-limits) sets out.