How Recued works — Recued Docs

Recued sits between an AI and your accounts. It controls what the AI can do. It splits the work into four parts. One part runs things. One part acts on web pages. One part shows you the screen. One part is an online extra. No thin app can quietly become the boss of your data. No cloud service can either.

#The four surfaces

Surface	Responsibility	Does not own
Server	Runs everything, knows who you are, keeps the secret keys, the warehouse, the grants, and the audit diary	A hosted screen or the marketplace pages
Browser Bridge	Small actions on web pages, and notifications from your computer	Recipes, rules, or any long-lasting power
Webclient	Shows the screen and takes your clicks	Running recipes, or your account secret keys
Cloud	The marketplace, names, certificates, and a few other online extras	Your warehouse, your prompts, or your provider secret keys

#One enforcement boundary

Every action goes through the same one gate before it runs. The gate looks at five things. Which installed capability is being used. Who is asking. Which contract that capability runs under. Which action was granted. And how risky the action is.

text

AI request
   ↓
resolve actor + contract + capability
   ↓
grant and approval checks
   ↓
local execution
   ↓
audit record and reversible result

Reads run only when you said yes ahead of time. Writes can be set to ask you first. Actions that cannot be undone keep asking you first unless you change that. That stays true even when you let smaller actions run freely.

#Cloud boundary

The cloud can help your server get a name that stays the same. It can help it get a certificate. It also runs the public marketplace. It never carries your normal recipe traffic. It never gets the secret keys your server keeps.

#Continue

Read Security and privacy to see what crosses each line. Or read Recipes and packs to see how the things you install fit this gate.