What an agent can reach in your account

With a read scope — which every credential carries — a client can reach the normalised account data one workspace holds.

Connections. Which platforms are connected, each one's status, when it last synced and when it last tried, and a capabilities object saying what that platform can actually express: which change operations it supports, where budget attaches, which objectives it accepts, what a deletion means there, and whether a change can be dry-run against the platform before it is applied.

Ad accounts. The canonical accounts under each connection, with the currency each one bills in and the time zone its days are counted in.

Campaigns and everything under them. Every campaign including the ones not delivering, with status, objective, budget and flight window; then ad groups, ads, creatives and keywords beneath them, newest first.

Metrics. Daily counts per entity — spend, impressions, reach, clicks, conversions and conversion value, with the account's currency stamped on the row — and the five ratios computed from them at the moment you look.

The media library. The images and videos the workspace holds and has handed to the platforms.

Change requests and media plans. The list of drafts and their statuses, and the plans and their items.

An account brief. A computed summary of an account's last ninety days: coverage, totals, a comparison against the previous twenty-eight days, the objective mix, spend concentration, the rankings by return and by cost per acquisition, and the weekday rhythm. It carries its own age and is flagged once it is more than seven days old.

There are also reads that go past the mirror to a platform's own systems where the platform offers them — a change history saying who moved which field and when, the search terms that matched an ad, where a display or video campaign's money actually went, and keyword or interest research for resolving what to target before anything is drafted. Which of those exist depends on the platform, which is what the capabilities object on each connection is for.

It reads what one workspace's connections have synced, and nothing else. There is no discovery of accounts you did not connect. There is no reach into a second workspace: the workspace comes from the verified credential and no capability accepts one to name, so an identifier from elsewhere produces no row and therefore no answer.

Platform credentials are not part of the surface. Neither is anything about billing beyond what your own plan entitles you to.

There is one door to a platform's own API for the endpoints Tempio has not normalised, and it is closed by default. It is off until an owner turns it on, the switch is workspace-wide, and a mutation through it is still a change request that no rule may ever clear — because a rule is written against a shape and a raw request does not have one.

With a draft scope, a client can write change requests, edit the payload of one still waiting, revert an applied change by drafting its inverse, and edit media plans.

A drafting call takes a connection and a list of operations and writes them as one reviewable batch of up to fifty entries — a longer list is refused rather than truncated. Where entries depend on each other, a child names the index of the entry that creates its parent, so nothing carries an identifier that does not exist yet. What comes back is the batch, a link to the gate for the whole group, and the authority that cleared it.

Nothing in that paragraph is a change to an ad account. A change request is a record of an intended change, carrying the state it would change from and the checks it passed, and it sits at the gate until something clears it. Stated plainly, because this is the guide where it matters most: your connections read your accounts, a change is written as a draft on the record, applying it is gated on approval — by you, or by a rule you wrote — and no platform write reaches a customer account until that platform has granted write access. Applying a cleared change to a platform is in private beta.

Two details about drafted money that are easy to miss. The currency of a payload is not the client's to state: the server stamps it from the target account and overwrites whatever arrived. And a create is drafted with the entity paused, so building the structure and starting delivery are two rows carrying two authorities rather than one act with a side effect.

Scopes. Approve is opt-in at the mint and off by default, and the in-app agent never holds it. On the explicit surface, capabilities are registered per request against the scopes the credential carries, so a read-only credential does not see the drafting capabilities at all — they are absent rather than present and refusing. An agent cannot be argued into calling something it was never offered.

The workspace boundary. Described above, and it is structural rather than a check.

Guardrails. The connection's kill switch, the account's own daily ceiling derived from what that account has actually done, the rule that a budget may not move more than a hundred per cent of its current value in one change, the first-budget cap for an entity with no baseline, and the rolling twenty-four-hour sum of applied increases on a connection. They are checked when a change request is written, again at approval, and once more immediately before a platform is called, using the same functions each time so the sentence you read at the gate and the decision at the apply cannot disagree. Nothing in the product raises them, and no scope buys past them.

What no rule may clear. An approval rule can clear a pause, a budget decrease or a bid decrease under a cap it states in a currency it states. It never clears a create, an upload, a removal or a change to account defaults; never an increase, an amount over its own cap, or an amount in another currency; never a change whose direction cannot be read; never a draft the platform's own dry run refused; never one carrying a special ad category; and never anything on a connection whose kill switch is on. A batch is one unit, so one row a rule cannot clear sends the whole group to a person.

The audit log holds every move a change makes: written, edited, approved, applied, refused, reverted behind a failed sibling, rejected, undone, or marked failed by hand. Each row names who acted — a person, the in-app agent, a key, or a rule — and for an approval, which authority cleared it and whether the approver was the same actor that drafted the change.

That last detail is the one worth knowing about before you hand any credential the approve scope. A key approving its own work is a different fact from a person approving it, and the record says which happened rather than flattening the two.

The log records an actor by name rather than by a link to a user account, so it holds a rule or a key as readily as a person, and it outlives the change request: a draft can be edited or superseded, and what happened to it stays readable.

Two controls, both immediate. Revoke the credential, and its next call is refused while everything it already drafted stays exactly where it is. Or pause the connection, which stops syncing and blocks every apply written against it whatever is queued and whatever rule would otherwise have cleared it.

Neither rejects anything. They stop what is next, not what is recorded, which is the right shape for a control you reach for when you are not yet sure what happened. How to scope an MCP key is how to avoid needing either.

The argument for reading this list as limits rather than as capabilities — and for telling the structural ones from the enforced ones — is in An agent with your ad account.