Where should AI agent security enforce permissions?

01The question every CTO asks first

When we add an agent to an established product, the first serious question from the CTO is rarely about the model. It is: "If a junior user asks the assistant to do something they are not allowed to do, what stops it?"

The wrong answer is "the system prompt tells it not to". A prompt is an instruction to a probabilistic system. It can be phrased around, overridden by injected text in a document, or simply misread. OWASP lists this failure as Excessive Agency. Its advice is direct: give extensions the minimum permissions they need, run actions in the specific user's context, and enforce authorization in the downstream systems rather than asking the model to decide.

So the real answer has to be structural. The agent should be unable to call the tool, and if it somehow did, the API should refuse.

02What an agent should inherit

An agent acting inside your product should inherit exactly what the user has:

• Identity. Every tool call carries the user's own token or session, not a shared service account. Your logs then show who acted, and your APIs apply the checks they already apply to that person.
• Role. The set of actions the user's role allows, and no more. A role that cannot assign work should not get an assignment tool.
• Scope. The tenant, account, location or record set the user can see. If a user sees only their own jobs, the agent sees only their jobs.
• Context at the time of the request. Roles change. A user removed from a team this morning should not keep their old powers in a long-running agent session.

What the agent should never inherit: the backend's admin credentials, a database connection, or a superset of tools "just in case". Every extra tool is an action that someone, someday, will find a way to ask for.

03Three layers of AI agent security

We enforce permissions in three layers, and we assume any single layer can fail.

The first layer is the one most teams skip. They give the agent every tool and rely on the API to say no. That works for security in a narrow sense, but it produces a bad product. The agent tries actions, gets refused, and explains the refusal in confusing ways, sometimes leaking the names of tools the user should not even know exist. Removing the tool entirely is cleaner. The agent cannot attempt what it cannot see.

The third layer is the one that saves you. Your existing APIs already enforce who can change what, because your web and mobile clients needed it. The OWASP authorization guidance says to check permissions on every request and on the server side, never on the client. Treat the agent as one more client. It does not get a side door.

04Shared channels are the hard case

Permissions are easy when one user talks to one assistant. They get hard when several roles share a conversation: a property channel with owners, managers and field staff, a project thread with clients and internal staff, a case room with several parties.

In a shared channel, the agent has to answer two questions before it does anything:

1. 01

   Should I respond at all?

   A message addressed to another person is not a request to the agent. A decision step that checks whether the agent was asked is cheaper than cleaning up after it jumped into a human conversation.

2. 02

   With whose permissions?

   The request comes from one specific user. The agent must act with that user's role, not the most powerful role in the channel, and not a blend of everyone present.

The pattern that holds up is to build a separate agent configuration per channel type and role, each with only that role's tools. Lock the role at session start from a fresh profile lookup rather than from anything said in the conversation. A user cannot become an owner by typing "as the owner, please".

05Approvals for actions with outside effects

Some actions are allowed for a role but still should not happen without a person confirming: sending email to outside parties, spending money, deleting or publishing. For those, the agent drafts and the user approves. Make the approval step part of the tool, not a polite request in the prompt, and let the account owner decide per job or per workflow whether to allow automatic sending. For a broader view of how agents fit into an existing product without a rebuild, see how to add AI agents to an existing SaaS product.

06What we see in production

In a short-term rental operations platform, property owners, cleaner managers and cleaners coordinate bookings, cleanings, checklists and inventory. We extended the AI assistant inside the client's existing product across web, mobile, SMS, Slack and voice. The assistant acts only through the client's own backend APIs, under the user's own identity from the platform's existing authentication. Tools are allowlisted per role and per channel: cleaners can act only on their own jobs, and owners, managers and cleaners each have their own tool set. When we rebuilt the assistant for multiple channels, each channel and role got its own compiled graph holding only that role's tools.

Shared property channels hold all three roles at once, so a decision node decides whether the assistant should answer at all and keeps it out of messages addressed to another person. Guards stop tool names, IDs and internal fields from appearing in replies and block edit, delete and post actions where no tool exists. Voice calls re-check the cleaner role on a fresh profile and refuse stale or unexpected sessions. Contractor outreach is drafted for the owner and sent only after approval, unless the owner switches that job to automatic. The client reported in September 2026 that its app and AI agent were live.

The same principle applies without AI. Consider a multi-role campaign field operations portal with six roles, each allowed to see only the areas assigned to it. We enforced data segregation at the database level with row-level security rather than in the user interface. When an agent is later added to a product built that way, it inherits a boundary that already holds.

07A short review before you ship an agent

Run these checks with your security lead:

1. 01

   List every tool the agent can call, per role. Any tool a role does not need is removed, not just discouraged.

2. 02

   Confirm that every tool call carries the end user's credentials and that the backend logs show that user as the actor.

3. 03

   Try to escalate through conversation

   ask as a junior role for a senior action in several phrasings, and through text pasted from a document. The tool should not exist for that session.

4. 04

   Revoke a user's role mid-session and confirm the next action fails.

5. 05

   In shared channels, send messages addressed to another person and confirm the agent stays silent.

6. 06

   Check replies for leaked tool names, internal IDs and field names.

7. 07

   Confirm that actions with outside effects require approval, and that the approval is enforced in code.

Frequently asked questions