Connect Google Sheets to an agent and the consent screen gives you one real choice: "See, edit, create, and delete all your Google Sheets spreadsheets." All of them. There's a read-only version, and that is the entire menu (Google for Developers).
That checkbox isn't a permission. It's a whole category of permissions, bundled and handed over as one. It's a key, not a job description. The key opens the door. It says nothing about what you're allowed to do once you're inside.
For about thirty years, that was fine. A person was always holding the key.
A scope was sized for a human
You have the Sheets key, but you only ever touch the three cells you meant to. The scope is wide. Your behavior is narrow. Nobody lost sleep over the gap between the two, because you were the one minding it. The consent screen could afford to be lazy. You were the real access control.
This is why OAuth feels coarse the moment you look closely. It was designed for apps a person drives, where broad scopes plus human judgment add up to safe (Strata). Take the person out and only the broad scope is left.
An agent holds the whole keyring
Hand that key to an agent and the gap becomes the whole story. The agent inherits everything the scope allows. Ask it to append one row to one tab, and you have also authorized it to overwrite, reformat, and delete every spreadsheet in the account. It probably won't. "Probably" is carrying a lot of weight in that sentence.
This is the defining security problem of the agentic era, and the numbers have caught up to it. The State of AI Agent Security 2026 report found that 88% of organizations had a confirmed or suspected AI agent incident in the past year, and that nearly half of teams still wire agents up with shared API keys (Gravitee). OWASP added a principle called "least agency" to its 2026 Top 10 for Agentic Applications: give an agent the minimum autonomy its task needs, so a hijacked one can't do unlimited damage (Aikido).
Least agency is the right idea. The problem is that the credential can't enforce it. Google does not mint a "this agent, write only, this one sheet" token. The scope is the smallest unit it sells.
The permission you actually want is the operation
So move the decision down a level. Below the credential, to the operation. Not "can this reach Sheets" but "what is it allowed to do there." Read only. Write only. One endpoint, and nothing else.
Once the operation is the unit, the things you actually want become sentences you can write down:
- An agent that sends email on your behalf but can never open your inbox.
- One that reports on your CRM but can't change a single record.
- One that watches your Stripe revenue but can't move a dollar.
A scope can't express any of those. An operation-level permission expresses all three. That's what General Input Agent Firewall does. It filters every call at the level of the operation, below the credential: you choose what an agent can do independently of what the key can access, per connection when one agent needs a tighter leash than another, or across your whole workspace as a standing rule, spanning the 8,500+ tools in the catalog.
Enforced below the key
Where you enforce a rule matters as much as the rule. General Input Agent Firewall runs at the runtime proxy that sits between the agent and the outside world, underneath the credential. A blocked call never leaves the sandbox, so it never reaches the model, so the model never gets the chance to be talked into making it.
And the key itself stays out of reach. The AI never sees it. Credentials are encrypted at rest, injected at runtime, and stripped before anything touches the model. Every call that does go out is written to an audit trail. The firewall decides which calls are even on the table.
Scopes answered the right question for the world that built them, the one where a human was always the last line of defense. Agents removed the human. The permission model has to follow the action down to where it actually happens.
Don't hand an agent a key. Hand it a list of operations.