Your copilot needs identity, permissions, and limits; not just a prompt

An agent inside a SaaS needs a name of its own, permissions per customer, and a cap you can remove. The instructions you give the model do not control access. If it acts on a customer's data, treat it as a service: who it is, on whose behalf, on which account, and how far.

The copilot no longer only drafts. It calls your system, reads the ticket, and proposes a refund. At that moment it stops being a chat and becomes someone who acts. Whoever acts needs identity, permissions, and limits.

When the trial touches customer data, someone asks what permissions it has. If the answer is "it is instructed not to do harm", you do not have security. You have a wish. An agent in a SaaS shares the database, the actions, and the memory with the product. If it acts, treat it as a service.

The OWASP article on the top ten risks of applications with models in 2026 names the biggest problems when you put agents into operation. The first is that someone puts new instructions inside what the model reads, for example in a ticket or a PDF. Another, among the most important, is that the agent has more power than the task needs. Neither is fixed with a sentence in the instructions. They are fixed in how the system is built.

Why calling the agent "secure" is not enough

"Secure" is an adjective. In a meeting it is not enough. What is enough is a list of controls you can show, test, and remove.

The most common mistake is to treat the instructions as if they were a wall: "do not access other customers", "do not delete anything", "ask for confirmation if there is doubt". The model does not sign that promise. A ticket, a PDF, or an action that returns text can put new instructions into what the model reads. It reads them as if they were yours.

The second mistake is to confuse "the person has signed in" with "the agent is authorized". The person signed in with their user. The agent often reuses that session, or a key with more power than the person. Signing in says who called. Authorizing says what that call may do. They are different layers. Mixing them is how a black box is born that worked in the demo.

You have to be able to answer four questions. Which identity it uses. Which concrete permissions it has. On which customer's account it operates. How you stop it. If any of them stays at "the model already knows", the design is not ready. It is the same jump from a demo to production: a demo is not an agent.

The agent's identity is not the person's

In a SaaS with agents there is not a single "who". There are three, and you have to be able to name them.

The person is whoever opened the conversation: support, administration, or customer success. The product is the application that organizes. The agent is the program that decides which action to call. If all three travel on the same session, the record does not distinguish "María asked for a summary" from "the agent exported the CRM". On incident day you will not know whose access to remove.

There are two ways to do it. One is for the agent to use the person's full identity. It is easy, and it gives the agent more power than it needs. The other is to act on their behalf: the agent has its own identity and a narrower pass, marked as "for María". AWS describes this in its guide to agents with several customers and in the scheme for acting on someone else's behalf (RFC 8693). The pass carries the person and the agent, and the system behind can require both.

For example, María can see tickets on her account and cannot issue refunds. If the agent uses a support administrator key, it can refund. If it uses María's session without trimming it, it cannot refund, but you also cannot remove the agent without kicking María out. If the agent has its own identity, with permission to read tickets and without permission to refund, the refund does not exist as an action, no matter what the instructions ask.

The rule is that the agent is not the person. It is someone with its own identity, tied to a person and to a customer account. If you cannot remove its access without kicking the human out, you do not have identities yet. You have a disguise.

Passes, concrete permissions, and keys that expire

OAuth is the way to lend access without sharing the password. The person, or your product's identity system, issues a pass. The pass is not total access. It carries concrete permissions, for example read tickets or refund orders. The action checks the permission. If it is not there, it answers that it cannot. The model does not take part in that decision.

A key that lasts a short time, fifteen minutes or an hour, limits the damage if it leaks. A key that lasts forever in the environment, or worse, pasted into the instructions, is a pass for life. If what the model reads leaks, in a record or in another customer's index, the key travels with it.

The shared plug for connecting agents to actions (MCP) leaves this as a rule. The server that publishes the actions checks the pass. The pass has to be addressed to that server, not usable on any other (RFC 8707). A pass from server A is not reused on server B.

Three rules that avoid most of the scares.

The secret does not live in the instructions. It lives in a store, it is exchanged for a short pass, and it is not written in the record.

The agent's permission is narrower than the person's. If María does not refund, neither does the agent. If María refunds up to 50 euros, the agent has that cap on the action, not in the text.

The pass dies. It expires, it is rotated, and it can be revoked. If the person signs out, changes role, or the customer account is switched off, the pass stops being valid.

OAuth does not make the agent secure. It stops authorization from being a conversation with the model.

One customer's account must not see the next

A customer account is what the trade calls a tenant. Isolating it means the agent on account A does not read, write, or remember account B. Not in the system, not in memory, not in search, and not in the record someone pastes into Slack.

The classic failure is not an attack. It is an action that searches invoices without saying which customer, or a shared memory where B's contract shows up in A's answer. The model did not cross the account. You gave it an index with no separation.

The AWS guide to not crossing customers does not trust that separation to the code that handles the call. If the same function serves many customers, the program asks for credentials trimmed to that account. Even if the code gets it wrong, the credential does not reach the neighbor. The guide to agents with several customers adds what is specific to agents: the account travels in the pass on every hop, including from one agent to another.

A short list of leaks, not of slides.

Every time an action runs, it has to be tied to a customer that comes from a trusted place: the session, the pass, or your server. The agent should not be able to choose the account from the text of the conversation.

Memory and document search are split. One drawer per customer. No "just in case, search everything".

Records do not mix two customers' data in the same file someone can export.

The agent does not have an action to "list every account" except a platform role, outside the product.

If the separation only lives in the instructions, there is no separation. There is hope. In a SaaS that is not a control.

If it is not allowed, it is closed

An action is a door. If it is not allowed, it is closed. Not the other way around. The model does not choose from the full menu of your system. It chooses from a short list you opened for that flow, that role, and that account.

An agent having more power than it needs is almost never a bad model. It is an agent that can run free queries, send emails, refund, and sign in as administrator because the demo looked good. Every extra action is surface. Every free piece of data, a query, an address, or a file path, is a way to move somewhere it should not.

The contract of an action, the one you can actually review, has four fields: name, what it does, on which resource, and with which data. "Search this customer's help articles, maximum 5, without the raw HTML" is a contract. "Query the database" is not.

That is decided before the model.

A list of actions per case. The agent that summarizes cannot refund.

A list of allowed data. The identifier of a ticket on that account, not a free query.

Caps on quantity or amount: money, rows, recipients, and number of calls. A loop of actions with no cap is not only a risk. It is an invoice. We covered that in the token price is not the agent's cost.

If the rule does not answer, it is denied. It is not let through this once.

The minimum power is the list of actions the case needs, and none more. If you opened administrator access for the demo, the demo is not ready for a real customer.

When a person actually has to approve

A person approving or stopping the action is not a way to look serious. It is a risk control. You put it where the failure is expensive to undo, not on every turn so you look prudent.

You need it when the action cannot be undone or hurts a lot: money, writing to a customer's system, exporting personal data, writing to someone outside, or crossing a legal or contract line. Also when the account is new and you have not measured yet. The person is the brake while you measure.

You do not need it to classify a ticket, draft an internal note, or retrieve three help articles. There, an extra person does not add security. They add a queue. If everything goes through a person, the agent becomes an expensive intern and you lose the saving that justified the case.

Two limits. A person who approves in bulk does not read what slipped into the context. They press approve and move on. It also does not remove the problem of instructions hidden in a document. The model can propose a call with the wrong data and, if the screen only shows a summary instead of the action and the real data, that check is not enough. A confirmation screen does not fix an action that should not have existed.

Design the approval by risk: a threshold of amount or of data, a sample once you are measuring, someone to escalate to if nobody answers, and an owner. If everything goes through a Slack channel, you do not have an approval. You have a bottleneck with no trail.

Being able to say who did what, and being able to remove their access

If you cannot say who did what, on whose behalf, on which account, and with which action, you have a black box, however fine the model is.

A useful record, the one a security person asks for and the one that saves you at night, carries the person's identity, the agent's, the account, the action, the data sent without secrets, the decision to allow, deny, or ask for approval, the result, and the version of the instructions and of the model. Without that there is no incident you can recount. There is a conversation.

Removing access is the proof that the identity exists. You can remove the agent's pass without kicking the person out, switch off the agent on one account without taking down the product, and change an action's key without redeploying the model. An emergency switch is not an extra. It is the proof that the agent is not a process with no owner.

A record without the ability to remove access is a museum. Removing access without a record is a switch in the dark. You need both, from the first account of the trial, not when you scale.

A checklist

Before you let an agent write in a real environment, the company should be able to answer these questions.

Does the agent have its own identity, distinct from the person's and from the service's?

Does every pass carry the account, the concrete permissions, and an expiry, and does the action check them, not the instructions?

Does the separation of accounts cover the system, the memory, the search, and the records, not only the case that comes out right?

Are the actions closed by default, with a list of allowed data and a cap on calls?

Is a person's approval placed by risk, with an owner, and is nobody selling it as a guarantee?

Can you remove the agent's access on one account today, and leave a trail of who did it?

If two or more are missing, you do not have a copilot with governance. You have a process with a key. The instructions can be good, but they are not an access control.

Once those lines exist, the rest is engineering. At Devic that chain, identity, rules, action, and record, is operated in the system around the model. Permissions per run, not a stamp that says secure. We do not promise that instructions hidden in a document disappear. We promise that the action can be denied, reviewed, and switched off. The plans are there to measure that on one account before you open it on all of them.

The copilot that convinces in the demo speaks well. The one that holds up in a SaaS has identity, permissions, and limits.