How are teams reviewing authentication patterns before approving new Rovo Actions?

[Prashanth]

Hi All,

Happy Friday :)

I wanted to raise a governance question for teams building custom Rovo Actions.

Before a new action goes live, what review process do you follow when deciding whether it should run:

• As the calling user

• As a service identity

• Through an OAuth-authorized external identity

My concern is that service identities can sometimes become the default choice because they're easier to implement and test. However, if an action should really be constrained to the invoking user's permissions, that decision can introduce unnecessary access risk.

A few questions for teams already deploying custom actions:

• Do you have a formal approval checklist for authentication decisions?

• Is security/platform governance involved before an action is added to a production agent?

• Have you performed audits of existing actions to validate that the chosen authentication model still aligns with the intended scope?

• Or does authentication review tend to happen reactively after issues are discovered?

The community has spent a lot of time discussing knowledge boundaries, permissions, and content access. I'm curious whether similar governance practices are emerging around action-level authentication.

Would love to hear what is working in practice.

[Anne Saunders]

We're still planning our roll-out, so this post is incredibly well timed for me. I'm nervous about allowing much access, since an agent can be a very fast (and sometimes not restorable) monkey's paw. 

So far, my plan is to limit access to Rovo Studio by group, then rely on user permissions for access to Rovo Actions. (I don't think Groups or Teams are options for Rovo Action permissions yet). 

My preference would be for the actor to default to the calling user, but I don't have any hard use cases yet where there's an argument for a service identity or OAuth.