Concepts

Grants and approvals

Install-time grants, one enforcement boundary, approvals with editable arguments, and session grants for chat.

Nothing in Recued acts on your accounts unless you installed the capability and granted it in advance. Granting happens before execution, enforcement happens at call time, and both leave a record.

#Grants are made at install

Installing a pack is the moment you decide what it may do. Before anything is installed, Recued shows:

  • every recipe the pack will install;
  • the account (connection) it can use, if any;
  • the requested access level, such as read or read-and-write;
  • the audience — who may use those grants, defaulting to only you;
  • body-content visibility or local-tool access, where requested.

The grant attaches to the installed pack. Individual recipes cannot silently widen it, and you can revise it later without reinstalling anything.

#One enforcement boundary

Every operation — whether you clicked Run, a schedule fired, or an external AI agent asked — passes through the same boundary before executing:

text
request
  ↓ resolve who is asking (actor) and on which channel
  ↓ resolve the installed capability and its contract
  ↓ check the grant and the operation's risk tier
  ↓ execute locally
  ↓ write the audit record

There is no privileged path around it. The server's own scheduler, your chat messages, and a connected agent all meet the same checks.

#Risk tiers and approvals

Reads execute when granted. Writes can be set to require approval. Outward, irreversible actions — sending mail, posting messages, changing records other people see — are approval-gated by default and stay gated until you decide otherwise.

An approval request reaches your paired surfaces and waits durably until you answer; nothing proceeds in the meantime. Where a request carries arguments — an email draft, a record update — you can edit them before approving. And when one origin produces a burst of identical operations, Recued asks once for the whole batch instead of once per item.

#Session grants

When you are working in chat, per-action approval can be relaxed deliberately for the rest of the session:

  • Exact — approve this precise action, once.
  • Batch — approve this action shape for the burst it belongs to.
  • Open — allow this operation class within a scope for the session.

After repeated identical approvals, Recued may suggest a standing rule. Only you can create one — suggestions never activate themselves.

#Doors

Externally reachable channels are opened deliberately. A door — MCP for AI agents, reception for public pages and inbound requests, messenger for chat platforms — carries its own per-tool grants, and its access credential is derived from the door itself, so closing the door revokes the access it granted.

#When something goes wrong mid-flight

If a gated call crashes between decision and confirmation, Recued does not silently retry. The operation is parked as in doubt and you are asked what happened before anything resumes.

Recued is local first; your server remains the authority.

Recued Docs

Search documentation

Start typing to search the documentation.