Why AI agents need a permission layer, not just more connectors

Most of the energy in the agent ecosystem goes into reach: more connectors, more MCP servers, more tools an agent can call. That is useful — an agent that cannot touch your systems cannot help you. But reach is the easy half. The half that decides whether you can run agents in production is governance: which worker may take which action, through which credential, in which account, right now.

A connector catalog answers "can the agent reach Google Ads?" A permission layer answers "should this worker be allowed to change a budget on this account this minute, or only read it?" Those are different questions, and the second one is the one that keeps teams from turning agents loose.

Reach without governance is just a bigger blast radius

Every connector you add expands what an agent can do on a good day — and what it can do on a bad one. A misread instruction, a prompt injection in a fetched web page, a confused tool call: with broad reach and no governance, each of these can spend money, push code, email a customer, or edit the wrong account. The catalog made the agent capable. Nothing made it safe.

The usual stopgaps do not scale. Hand-editing which tools appear in a config file is brittle and per-machine. "Trust the prompt" fails the first time the model is wrong. And one shared API key behind a connector means every worker that touches it inherits the full scope of that key.

What a permission layer actually decides

A permission layer sits between the agent and the tools and makes four decisions on every call:

• Visibility — which tools this worker's role can even see, so a sales agent never discovers a production deploy action.
• Identity — which connection/credential the call routes through, so the right account, repo, property, or workspace is selected by policy rather than by luck.
• Action class — whether this is a free read, or a write that needs a human in the loop before it runs.
• Record — a log of who called what, through which connection, and what happened — including the calls that were blocked.

None of these are connector features. They are policy decisions about the work, and they belong in a layer that every agent and every tool passes through.

Roles, not raw access

"Google Ads access" is too coarse to be a permission. The useful unit is a role: an Ads Operator may search campaigns freely and mutate them only after approval; an SEO Analyst may read Search Console and open GitHub issues but never push; a Sales Ops worker may update deals in one CRM portal and nothing else. The role encodes the job, and the permission layer enforces it the same way for a human-triggered run, a scheduled job, or an autonomous loop.

Connectors decide what is reachable. A permission layer decides what is allowed. You need both, but only one of them lets you sleep.

Where this leaves you

If you are evaluating agent infrastructure, separate the two questions deliberately. Ask a connector platform how many tools it integrates. Ask a permission layer how it scopes a worker, where credentials live, how it gates risky actions, and what its audit trail captures. The first question is about capability. The second is about whether you can hand the keys to a non-deterministic operator and still answer for what it did.

That second question is the one Grantry is built to answer.