Rules and approvals

What a rule is

A rule is data kept on a source or on a server. Inline applies it to every call, whichever door the call came through — MCP, HTTP, a script, or a registered tool. Rules on a source run first, wherever that source’s tools are called; a server’s own rules run after that, on everything the server serves.

Within one list, rules run top to bottom, and the first rule that refuses or holds a call ends it. A rule has a match (a tool name, a wildcard, or a behaviour such as delete) and a list of actions. Actions that run before the call are set, default, require, deny, limit, hold and webhook. Actions that run after it are redact, drop, pick and truncate.

The rules editor, opened from Servers or Sources, offers presets for the common ones: hold deletes for approval, always set an argument, require an argument, block a tool with a message, redact a field from responses, and ask a webhook. Each preset writes a rule you can then read back in one sentence, or edit as JSON. The JSON view is a convenience — the server validates every save either way, so it is not a route around a check.

When a call is held

A hold stops the call before anything upstream is touched. The agent is told the call is pending, not that it failed, and is given an approval_id it can check with approval_status. The call itself waits in Approvals.

Who may decide is part of the rule. A hold can name approvers — email addresses, or group:name — and when it names none, the owner or an admin of the thing the rule sits on decides. The person whose credentials the agent used may normally decide their own held call, because a hold records whose key an agent borrowed rather than who clicked anything, and that person is usually the human the hold exists to put in front of the call. A rule can set someone_else so that the requester is excluded; the workspace can require that everywhere, and then no rule can take it back.

Decisions are made from a signed-in browser session only. A key cannot approve anything, and neither can an OAuth session, so an agent holding the very credential that asked still cannot answer for it.

Approving runs the stored call at once, as the person who asked and within their key. Everything that would refuse it now still does — a lowered ceiling, a narrowed key, another rule. Only the rule that held it is not asked again. An undecided call expires after 24 hours and is not run; the agent has to ask again.

Telling people a call is waiting

A hold is only a control if somebody hears about it. Each server and source can carry an approval target: a webhook address (a Slack incoming webhook, or any https address) and an email address. Both get a short note with a link to Approvals; argument values are never sent. The editor can send a test, because saving an address only proves it was well-formed.

If a hold exists with nowhere to send, Inline says so — in the rules editor, on the settings row for that server or source, and at the top of Approvals for the person whose call is waiting. Email needs a mail server configured for the deployment; where none is, the page says the address is saved and nothing is being sent.

What is recorded

Both outcomes are written to Activity: the call is recorded as held, and once somebody decides, the row says who decided, when, any note they wrote, and whether the call then ran, is running, or did not run. A call that ran after approval links to its own record. An approval that nobody decided is recorded as lapsed.

Approvers see a preview of the arguments, with values that look like credentials hidden and long values cut. The result of the call goes to the caller only. The approval record itself is kept for 30 days after it is decided, unless the deployment sets a different window; the Activity record of the call is kept on its own schedule.