Agent Permissions Are Product Design: Authorization Beyond API Keys

Most teams think about agent permissions too late.

First they focus on model quality. Then retrieval. Then tool wiring. Then maybe the human review flow.

Eventually somebody asks a question that should have been on the table from day one:

"What exactly is this thing allowed to do?"

At that point, the discussion often collapses into credentials. Which API key? Which service account? Which role binding?

Those matter, but they are not the whole problem.

Authorization in agent systems is not just a plumbing issue. It is product design.

Because the real question is not simply whether the system can access something. It is whether it should act, for this user, in this workflow, with this level of confidence, under these conditions.

That is a much richer problem than secrets management.

Authentication is not authorization

This distinction sounds basic, but it gets blurry fast in agent systems.

Authentication answers:

"Who is the user or system?"

Authorization answers:

"What should they be allowed to do here?"

In agent products, there is an extra wrinkle:

the model is often acting through tools on behalf of someone else.

That means you may have:

• the human requester
• the application identity
• the tool or backend identity
• the policy governing the action

If those are collapsed carelessly, the agent ends up operating with a broader authority than the human would have had directly. That is how systems drift from "helpful assistant" into "privileged automation surface."

OWASP's LLM guidance on excessive agency is useful here because it names the root problem clearly: too much functionality, too many permissions, or too much autonomy given to a system that is still probabilistic.

That is not only a security bug. It is a design failure.

The permission question that matters most

When I review an agent workflow, I ask:

What evidence should be required before the agent is allowed to take this action?

That immediately produces a better design conversation than "what token should it use?"

For example:

• Can the agent issue a refund?
• Can it draft the refund and request approval?
• Can it do so only for a certain amount?
• Does it need a verified customer context first?
• Should the action be blocked if the request came from retrieved text rather than direct user instruction?

That is authorization thinking.

The right permission model is usually conditional, contextual, and workflow-aware.

Why least privilege is harder with agents

Least privilege sounds straightforward until the model is choosing tools dynamically.

Now you are not just assigning access to a user or service. You are assigning possible actions to a system that may:

• misread intent
• follow malicious injected instructions
• carry stale context forward
• act on low-confidence interpretations

This is why agent authorization should be narrower than ordinary integration authorization.

If a human support representative can eventually reach five internal systems, that does not mean the first version of the support agent should have those same powers in one hop.

Agent capability should be staged.

Start with:

• read access before write access
• draft creation before direct execution
• narrow scopes before broad scopes
• approval paths before autonomy

That is not overcautious. That is the only sane way to introduce a probabilistic system into real workflows.

Good authorization design looks like workflow design

Strong agent permissions are usually structured around a ladder:

1. Observe
2. Recommend
3. Prepare
4. Request approval
5. Execute

That sequence is far more useful than a binary allowed/not allowed model.

Many agent teams make their lives harder by jumping from observation straight to execution. The middle steps are where trust is built.

If the agent can:

• gather the right evidence
• draft the proposed action
• explain why it thinks the action is appropriate
• surface the decision to a human owner

then the organization learns what good execution would require before the system gets direct power.

That is exactly how mature permissions should evolve.

Authorization has to include scope, not just action

"Can refund" is not a permission model.

Better questions:

• refund which products?
• up to what amount?
• for which customer tier?
• in which channel?
• during which workflow states?
• with what evidence attached?

That is where product and security meet.

If you do not define those boundaries clearly, the agent ends up with permissions that are technically valid and operationally reckless.

The OWASP MCP Top 10 is useful here as well because scope creep is one of the easiest ways for agent systems to become dangerous without anyone noticing a single dramatic failure.

Permissions expand a little at a time. Temporary exceptions become defaults. Broad read access quietly turns into broad action authority because the tool surface was never designed with gradients of trust.

The agent should not inherit authority just because it can see a tool

One subtle mistake I see often is letting tool availability imply action legitimacy.

The reasoning goes like this:

• the tool is connected
• the model knows the schema
• the user asked for something related
• therefore the agent can probably do it

No.

Tool visibility should not equal action permission.

The system needs an explicit policy layer between "the tool exists" and "the action is allowed now."

That policy can be lightweight at first, but it has to exist.

Approvals are part of authorization, not a patch on top

Many teams treat approvals like a UX add-on. The real build happens first, then someone says, "We can always put a human review step in front of the risky actions."

That usually produces brittle workflows because the action design was never built around evidence, rationale, or reversibility.

A better approach is to design the approval model as part of the permission system itself.

For each meaningful action, decide:

• when approval is required
• who approves
• what evidence must be shown
• what gets logged
• what changes if the request is ambiguous or low confidence

That is authorization.

An approval step without evidence is just a rubber stamp interface.

A practical permission model for early agent products

If you are trying to ship something useful without building a policy engine from scratch, I would start with these rules:

1. Separate read tools from write tools.
2. Require explicit user confirmation or human approval for meaningful state changes.
3. Limit high-risk actions by amount, object type, or workflow state.
4. Log the rationale, evidence, and acting identity for every nontrivial action.
5. Give the agent the minimum set of tools that can prove the use case.

That alone will eliminate a surprising amount of risk.

It will also make the product feel more trustworthy because users can see that the agent is not operating as a vaguely privileged ghost in the system.

The strongest permission models feel intentional

When agent authorization is done well, you can feel it in the product.

The system does not overreach. It asks for confirmation where it should. It stays narrow when it should. It explains what it wants to do before it does it.

And when something is blocked, the boundary feels designed rather than arbitrary.

That is the standard teams should be aiming for.

Not just "the keys are locked down."

Not just "the agent passed authentication."

But: the product clearly encodes what this system should be trusted to do, and when.

That is the real work.

The short version

If your agent can act, authorization is not a backend footnote. It is one of the core product decisions.

Design permissions around:

• action severity
• scope
• evidence
• approvals
• reversibility

That is how you keep the system useful without turning it into an unaccountable operator with a nice interface.

Further Reading

• OWASP Top 10 for LLM Applications
• OWASP MCP Top 10
• NIST AI Resource Center