Access

A role is workspace-wide. A member reads everything in the workspace and drafts changes; an admin approves them as well; an owner does both and holds the plan. That is the right shape for one company running its own ads, and the wrong shape for an agency: one workspace holding four clients' accounts and an account manager who works on one of them should not read the other three's numbers.

Settings → Access is where that is narrowed. Restrict a connection and it is reached only by the members named on it, each at a level you choose. Every other member does not see the connection refused — they do not see it at all.

Restricting a connection

Every connection in the workspace is listed with a Restrict button and the members of the workspace beneath it.

While a connection is open — which every connection is until somebody restricts it — the workspace role is the whole of the authority, exactly as it was before this page existed. The member rows under an open connection say what each person's role already reaches, so you can see who a restriction would affect before you make one.

While a connection is restricted, only the members carrying a level reach it. A member with no level has no access: the connection, its ad accounts, its campaigns, its drafts, its media and its numbers are absent from every screen and every agent answer they get.

Opening a connection again leaves the levels where they are. They mean nothing while the connection is open, and deleting them would discard the list you built the moment you flipped the switch to see what it would do.

Restricting and opening are both written to the audit log, with the connection and who did it.

The three levels

Approve is the one place a level gives somebody more than their role does. A workspace member cannot approve anything; a member with Approve on one connection can approve drafts on that connection alone. That is the point of it: an account manager signs off their own client's changes without being made an admin of everybody else's.

It changes nothing else about how approval works. Over MCP it still takes a key minted with the approve scope — a level is not a credential. The chat agent inside Tempio still holds no approve capability at all, whatever level the person it is acting for carries. And every approved change is still a change_request on the record, approved by a person or by a rule the workspace wrote.

Owners

An owner reaches every connection in the workspace, restricted or not, and the list says Always on beside them rather than offering a level. Somebody has to be able to see everything: a workspace that could lock its owner out of a connection is a workspace that could lose one.

Where the restriction is enforced

In one place: the tool layer every read and write already goes through. The three clients — the hub, the chat agent inside Tempio, and your own AI over MCP — inherit the same rule rather than each carrying a copy of it.

That means a restricted connection behaves as though it were not there for a member who is not named on it. Lists leave it out — the dashboard and its figures, the campaign list, the drafts queue, the media library, the plans, the connections page, list_connections, list_ad_accounts, list_campaigns, get_metrics, list_drafts and the rest. A list that answered "refused" once per hidden row would still tell the reader how many clients the workspace has.

Naming one by id answers the same way: "Connection not found", the sentence an id that never existed gets. That is deliberate. A refusal worded differently from a miss would be an oracle — a member could confirm a client exists by watching which answer came back — so the two are one answer.

A member who can see the connection and cannot do this particular thing with it gets a refusal by name instead: somebody with View who tries to draft is told their access doesn't go that far, because they are already looking at the connection and that is the only answer they can act on.

A key's reach is its minter's reach. An MCP key carries the person who created it, and an OAuth connector carries the person who signed in, so a credential never reaches further than the human behind it. Tempio's own background work — the hourly sync, the account briefs, the weekly digest — runs for the workspace rather than for a person and is not narrowed by a restriction; nothing it does puts data in front of anybody.

Reading it from an agent

list_connection_permissions answers who reaches each connection and how far, including which members are owners and therefore always on. It needs owner or admin, read from the person behind the credential — the same gate the page itself applies.

A credential never reaches further than the person behind it, and that is re-checked on every call rather than at the moment it was made: demote the member who minted an approve-scoped key and the key's next call can read and draft and no longer approve.

There is no tool that changes access. Every governance write is a person's act on this page. An agent may explain the rules; a person writes them.

The plan

Restricted connections are on Pro and up. Below it the page still lists every connection and every member — a workspace deciding whether to upgrade should be able to see what it would be buying — with the plan's own sentence at the top.

What stays available below the plan is everything that loosens: opening a restricted connection again, and taking a level away. A workspace that closed three connections and then moved to a smaller plan would otherwise be locked inside its own restrictions, unable to undo the thing it can no longer have. A plan decides what a workspace may take on, never whether it may put something back. Billing has the plans.

Who can change it

Owner or admin — and Settings → Access is one of the few pages a member cannot open at all. What it shows is the shape of every restriction in the workspace: which connections are closed, what they are called, and which colleague works on each. Handing that to somebody deliberately kept off a client's account would undo the restriction in the reading. A member who opens it is told to ask a workspace owner.