MonoCloud for Startups
One identity layer for your customers, APIs, and agents
Start new thread

If an AI agent is acting for you, should it get all of your permissions?

by
•

A user gives an agent a task. Maybe it needs to read invoices, update a CRM record, check an internal dashboard, or call a few APIs on their behalf. The easy model is to let the agent act with whatever access the user already has.

But I am not sure that makes sense once the user has a lot of authority. If I can delete a workspace, change billing, export customer data, or invite an admin, does an agent helping me with one task need access to all of that too Giving the agent its own identity and narrower permissions sounds safer. But then another question comes up: how narrow can those permissions be before the agent keeps hitting boundaries halfway through the task?

So I am curious how teams building agents are thinking about this today.

Does the agent inherit the user’s authority? Does it get its own identity with access only to specific APIs or actions? Or are you handling this another way? And where do you draw the line between “the user is allowed to do this” and “the agent is allowed to do this for the user”?

35 views

Add a comment

Replies

Best

Mine gets all of mine, and I'm fine with that, because the permission set isn't where I put the guardrail.

Every server action I write is a public unauthenticated POST endpoint. That's not a design decision, it's just what one is once it's deployed. So no caller ever gets to say who it is.

The one that changed how I write these is a text to speech action. The version takes a string and speaks it. That version has to be permissioned, because a string can be anything, including someone else's. So it doesn't take a string. It takes a row id and a batch number, reads the text server side from a row the caller can already read, and speaks that.

The agent doesn't get fewer permissions than me, it has exactly mine, and it still never hits a boundary halfway through, because the boundary isn't in the permission check. It's in what the verb can express.

Where this stops working is your invoices and CRM example. It only holds while I own both ends and can redesign the verb

 I like the distinction you are making between restricting the caller and restricting what the action itself is capable of expressing. It also makes me wonder how far that pattern survives once the agent starts crossing system boundaries. If the verb eventually has to call Stripe, Salesforce, or some third-party API you do not control, you lose the ability to redesign both ends around that constraint.

Do you then fall back to narrower credentials/scopes for the external system, or do you still try to keep most of the safety in the action design itself?

I like to give my agents loads of credentials. Maybe a bit of risk involved but external actions or irreversible actions are the only ones I'm worried about. If it's internal or takes a few days to become external and it's reversible I say let em have it.

 I like reversibility as a test, but I would still be a little nervous about giving the agent broad credentials just because the action looks internal. An internal change can have external consequences pretty quickly. Updating a CRM field can trigger an email, changing a flag can kick off a workflow, editing a record can affect billing later.

Do you scope the credentials themselves at all, or do you mostly rely on approval gates around the actions you consider risky?

we ran into a version of this building phone calling for agents. the thing that mattered wasn't scoping down what the agent could say on the call, it was giving it its own number and call log completely separate from the human's. the boundary that actually stopped bad outcomes wasn't "fewer permissions," it was "this specific channel is attributable and I can kill it without touching anything else." once a call is placed it's already external and irreversible the second the other person picks up, same as Eric's point above, so scoping permissions after the fact doesn't help much. what helped was making sure every agent action had its own identity to revoke rather than inheriting a slice of the human's

 The separate identity point is interesting because it gives you something very clean to revoke without touching the human account at all. I am curious how you handle the lifecycle of that identity though. Does an agent keep the same number/identity over time, or do you create something more temporary per task or session?

I can imagine the revocation model looking very different depending on that choice.

 leaning temporary, and it's been a real tension rather than a clean answer. a number that persists across many tasks starts to accumulate the same problem it was meant to solve - if it's ever misused you're back to sorting through a long call log to figure out which calls were legitimate, instead of just killing one thing. per-task or per-session numbers keep the blast radius to exactly one call log, which is the property we actually wanted. the cost is that the person on the other end sees a new unrecognized number every time, which hurts pickup and trust on repeat contact. so we're landing on something in between - stable enough per relationship that a recurring contact recognizes it, but killable and reissuable the moment something looks wrong, rather than either fully permanent or fully disposable.

I run a lot of agent actions daily across several products, and the pattern that has held up for me is scoping by verb inside a system, not by system boundary. Stripe is one login but it contains read balance, list charges, and issue a refund, and those should never sit behind the same permission. The read actions run fully autonomous. The refund needs an explicit go ahead from me every time, no matter how small. What decides which bucket a verb goes into is not whether it is internal or external, it is whether the action moves money, sends something in my name, or changes a public or contractual state, because those are the ones I cannot quietly discover went wrong before someone else does. Plenty of external and technically irreversible actions, like sending a routine reply, run on their own with no gate at all. To your question to Siarhei directly: yes, narrower scopes for the third party API, but the harder part is not writing the scope, it is classifying every verb the agent might call against that test before it ever runs, not after.

 The verb-level model makes a lot of sense, but I wonder if the verb alone is enough once the same action can have very different risk depending on context. “Refund” is one verb, but $5 to a known customer and $50K to a new destination are obviously not the same decision. Same with sending a message internally versus sending it publicly in someone’s name.

Do you add conditions around the verb as well, like amount, destination, user, environment, or some other context before the agent is allowed to run it?