Skip to main content

April 29, 2026 · 7 min read · The Helix team

Scoped permissions for AI agents

Tool use is the glamorous part of agent design. Scoped permissions are the boring part. They are also the part that decides whether the agent ships to production or stays in a demo.

What a scope actually is

A scope is a typed, revocable, audit-able permission attached to an identity. "This agent can read this mailbox", "this agent can propose meetings on this calendar", "this agent can never send to addresses outside this domain". Each scope is enforced server-side; the agent cannot self-grant.

Why "give the LLM all the tools" fails

It is tempting to expose every API your agent might want as an MCP tool and let the LLM choose. The blast radius is the entire surface — and a single jailbreak gives the agent the full key ring. Worse, the audit log is unhelpful: "the agent decided to send this" without the rule that allowed the send.

Scoped permissions invert the model. The agent can call any tool the LLM wants — the server only honors calls that fall inside the identity’s scopes. The audit log records both the call and the scope that allowed it.

How Helix shapes scopes

Scopes are per-identity, never global. A team running ten agents has ten scope sets. Audit events tag every action with the identity, the scope that allowed it, and the human who approved (where applicable).

The escape hatches we deliberately did not build

These omissions are the point. Scopes that can be raised at runtime are scopes a jailbreak can raise. Scopes encoded in the schema and frozen per-identity are scopes that hold.

Keep reading

Helix for developers — auth + scopes · Spin up a free agent inbox

Newsletter

One email when we publish next.

One short email when the next post drops. No drip sequence.

No spam. Unsubscribe in one click.