An agent with your ad account

A policy limit is a rule enforced by a check. Somewhere there is a condition, and if it is correct and reached on every path, the limit holds. Most software security is this, and most of it is fine, but the failure mode is a path nobody thought about.

A structural limit is one where the thing simply cannot be expressed. Not refused — absent. There is no argument to pass, no endpoint to call, no state to reach.

The difference matters more with an agent than with a person, because an agent explores. A person who finds a way to do something they were not supposed to usually stops. A model presented with a partial refusal will try the adjacent phrasing, and the adjacent phrasing after that, not out of malice but because retrying is what it does when something does not work.

So the limits worth relying on are the ones with nothing to retry against.

What the credential can see. Structural, where capabilities are registered per request against the scopes the credential carries. A read-only credential does not receive the drafting capabilities at all; they are not in its list. There is no tool to be argued into calling, which is the cheapest guarantee in the whole system because it costs nobody any vigilance.

Which workspace it reaches. Structural. The workspace comes from the verified credential rather than from anything the caller sends, and no capability accepts a workspace to name. An identifier belonging to somewhere else produces no row, so it produces no answer and no link — the boundary is the query rather than a check on top of it.

How far a number may move. Policy, deliberately, and checked more than once: when the change is written, again when it is approved, and once more immediately before a platform is called. More than once because time passes while a change waits, and the last check is the one that decides. The same functions run at all three points, so the sentence read at the gate and the decision at the apply cannot disagree.

What clears without a person. Policy, and narrow on purpose. A rule you wrote can clear the reversible, spend-reducing half of the work and nothing else. Creates, removals, uploads, anything whose direction cannot be read, and anything raw all wait for a person.

Two structural, two policy. The honest presentation says which is which, because a customer deciding how much to trust this deserves to know which guarantees survive a bug.

With read access: which platforms are connected and when each last synced, the accounts under them with the currency each bills in, every campaign including the ones not delivering, the structure beneath them, the daily counts and the rates computed from them, the media the workspace holds, the change requests and the plans, and a computed summary of an account's recent history that carries its own age.

That is a lot, and it is the part that changes a working day. Most of the hours in an ad account go into finding out what happened, and a credential that can only read collapses that from an afternoon of exports into one exchange.

With drafting access it can also propose changes: a batch of change requests, each carrying what it would do, the state it would do it to, and the checks it passed. The worst case of a drafting credential is a queue of proposals nobody wanted, which costs an afternoon and no money.

Which is the place to be exact, because this is the post where somebody will otherwise assume more. An agent's reach over the reading surface is real and immediate. Its reach over the writing surface is a proposal: a record of an intended change, with the value it would replace and the checks it passed, waiting for you or for a rule you wrote to clear it. And even cleared, no platform write reaches a customer account until that platform has granted write access — applying to a platform is in private beta.

It cannot discover accounts you did not connect. It cannot reach a second workspace. It does not hold platform credentials. And the one door that reaches past the normalised model into a platform's own interface is off until a workspace owner turns it on, is granted per workspace or per connection, and produces change requests that no rule may ever clear, because a rule is written against a shape and a raw request does not have one.

None of those are features anybody asked for. They are the shape of a system designed by somebody imagining the incident report rather than the demo.

One property deserves its own paragraph because it surprises people in both directions.

A credential is bound to one workspace for its whole life, and the membership of whoever minted it is re-read on every call rather than checked once at the mint. Remove that person from the workspace and every credential they created stops answering in the same moment, with nothing to revoke by hand.

That is excellent for offboarding and inconvenient for automation: anything that has to outlive one person should be minted under an account that is not going anywhere, and the credential's name should say so. It is a good example of a limit that is structural rather than remembered — nobody has to run an offboarding checklist for it to hold.

Mint read. Ask it the questions you have been exporting spreadsheets to answer. Find out whether an agent on your accounts is useful at all, which is a question you can settle in an afternoon at no risk.

Add drafting when you want preparation rather than description. Add the ability to clear things deliberately, to one credential, with a job specific enough that you would notice it doing something else.

The trust you are extending is not to the model. It is to the shape of the system around it, which is why the limits are worth more attention than the capabilities.

MCP is a contract, not a feature is the interface half of this, and What an agent can reach in your account is the full inventory.