Agent frameworks need an authorization layer

Frameworks are toolkits, not products

Agent frameworks solve a real problem well. Composing models, tools, memory and control flow by hand is tedious, and the abstractions these libraries provide save meaningful engineering time.

What they do not supply is the surrounding enterprise product: identity, policy, configuration sync, runner placement, lifecycle records, audit history and an operator interface. Those are assumed to be the application's responsibility, which is correct for a library and insufficient for production operations.

The authorization gap

In most framework deployments, the agent runs as one service identity with one set of credentials. Whatever the agent can reach, every caller can effectively reach through it. The agent becomes a confused deputy: a privileged intermediary that does not distinguish between the SRE who is allowed to roll back production and the analyst who is not.

Fixing this properly means resolving authorization for the *caller* — before dispatch, for the route and for every protected resource the run references — and failing closed when a check cannot be evaluated.

Tool discovery is an access decision

It is tempting to let an agent discover every available tool and pick. In production that is a policy decision disguised as a convenience feature. The set of tools an agent can see should be filtered by the caller, the team, the scope and the requested action — evaluated live, not baked into a configuration file at startup.

Frameworks behind a boundary

The durable arrangement treats agent and model implementations as replaceable components inside a governed platform. Framework-based capabilities run behind an approved service or MCP profile; the platform governs invocation, records the tool calls and holds the evidence.

That way an improvement in framework tooling is an upgrade, not a re-litigation of your security model.