Table of Contents

Connecting a chat interface to an AI agent backend — how do you handle user permissions? That question is where teams get stuck, and usually they aim at the wrong target: they treat it as a data integration problem. It isn’t. The hard part is translating each user’s permissions into what the agent’s tools are allowed to do on that user’s behalf.

Connecting a chat interface to an AI agent backend is not, at its core, a data integration problem. Data integration — moving a request out and a response back — is a solved problem with decades of prior art. The problem that is actually new is translating a user’s permissions into an agent’s access scope.

The request that looks like an integration problem

The requirement usually shows up in a simple form: employees want to issue work instructions from one chat surface — an internal messaging tool, a team collaboration app — without switching windows or logging into a separate platform to talk to an AI agent. Whatever the agent platform is, the immediate instinct is to treat this as a connectivity project: build a bridge, pass the request, return the result.

That instinct is not wrong, but it’s aimed at the wrong problem. The mechanics of passing a request from a chat frontend to a backend service and returning a response — whether through a middleware layer or a direct connection — are technically indistinguishable from any legacy system-to-system integration. If that were the whole problem, this would be a solved problem.

Why the old integration lens undersells the real work

What’s actually new is that an agent is now the thing acting on the backend, on behalf of a specific user, inside a conversation that started somewhere else. The agent doesn’t just relay a query — it decides which tools to call and what data those tools touch. That introduces a permission-mapping problem that a stateless API proxy never had to solve.

The core claim: the interface-to-backend data flow is the old, solved problem. Translating a user’s access rights into an agent’s tool-level access scope is the new one.

Impersonation vs. delegation: naming the actual pattern

This permission-translation problem already has a name outside the agent world — it just needs to be recognized rather than reinvented.

• Impersonation means the system logs in as the user and acts with the user’s full authority, indistinguishable from the user themselves.
• Delegation means the system verifies the user’s identity and acts within the scope the user is entitled to, without literally becoming them.

The pattern that fits an agent gateway is delegation — specifically the shape known in OAuth-based systems as On-Behalf-Of (OBO): a downstream service acts for an upstream-authenticated user, carrying that user’s scope forward rather than assuming a service identity with its own, broader rights.

The mapping has two layers, not one

With a traditional API, OBO is usually a single hop: user scope maps directly to API scope. With an agent backend, the mapping doubles:

User's access rights
        ↓ (layer 1)
Which tools the agent is allowed to call
        ↓ (layer 2)
Which data those tools are allowed to touch

Layer 1 asks: given this user, which of the agent’s available tools should even be offered? A user without approval authority shouldn’t have an agent that can call an “approve request” tool, regardless of how good the agent’s reasoning is.

Layer 2 asks: even for an allowed tool, which records can it touch? A tool call to “look up customer records” needs to inherit the same row-level and field-level restrictions the user would have if they queried the backend directly. An agent’s intelligence doesn’t grant it new authority — it only decides when to invoke authority the user already had, or didn’t.

Skipping layer 2 is the more dangerous failure mode, because it’s invisible in normal testing: the agent behaves correctly for every test user who happens to have broad access, and the gap only shows up when a narrowly-scoped user’s request causes the agent to reach data that user was never allowed to see directly.

What this means for design

A few implications follow directly from treating this as a delegation problem rather than a connectivity problem:

• Don’t authorize at the agent level only. An agent-level “this agent can be used by this role” check is layer 1 only. It says nothing about what the agent’s underlying tools can touch for that specific user.
• Pass identity through, not just intent. The agent needs to carry the calling user’s identity into every tool invocation, not just the natural-language instruction. A tool call without the caller’s scope attached defaults to trusting the agent’s own service identity — which is usually broader than any individual user’s.
• Treat tool scope as a first-class access control surface, separate from and downstream of role-based access control on the frontend. RBAC decides what a user sees in the UI; tool scope decides what an agent can fetch or change on that user’s behalf, and the two can drift out of sync if they’re designed independently.

What’s still open

Two related design questions come up immediately once permission mapping is handled, and they’re worth naming even though this piece doesn’t resolve them: whether to build an orchestration layer that automatically routes a natural-language instruction to the right agent (versus requiring explicit agent selection), and how far to extend delegated scope — read-only lookups versus write and update actions with their attendant audit and reversibility requirements. Both deserve their own treatment once there’s a concrete decision to write about, rather than a hypothetical one.

Frequently asked questions

How do I handle user permissions when connecting a chat tool to an AI agent? Don’t model it as data integration. The request/response plumbing is the easy, solved part. The real work is carrying each user’s identity and permission scope into every tool the agent calls, so the agent can only touch what that specific user is allowed to touch. Handle permissions as a delegation problem, not a connectivity problem.

What is the on-behalf-of (OBO) pattern for AI agents? On-behalf-of means a downstream service acts for an upstream-authenticated user, carrying that user’s scope forward instead of using a broad service identity. For an AI agent, OBO has two layers: which tools the agent may call for this user, and which data those tools may touch. The agent acts within the user’s rights — it doesn’t gain new authority by being smart.

Why isn’t connecting an agent to a backend just an integration problem? Because an agent doesn’t just relay a query — it decides which tools to call and what data they touch, on behalf of a specific user. A stateless API proxy never had to map user permissions to tool-level access. That permission mapping is the genuinely new problem, and it’s invisible in normal testing because it only surfaces when a narrowly-scoped user’s request reaches data they were never allowed to see.

What’s the difference between impersonation and delegation for agents? Impersonation means the system logs in as the user with their full authority, indistinguishable from them. Delegation means it verifies the user’s identity and acts only within the scope they’re entitled to, without becoming them. An agent gateway should use delegation — specifically the OBO shape — so the agent carries the caller’s scope rather than assuming a broader service identity.

Takeaway

The data plumbing between a chat interface and an agent backend is not where the design risk lives — that part is a solved integration problem regardless of which chat tool or agent platform sits on either end. The risk lives in whether a user’s access rights are correctly translated, twice, into what the agent’s tools are allowed to call and what those tools are allowed to touch. Get the delegation model right, and the integration is the easy part.