Roles and permission groups for AI

The core principle

AI agents in Fusion ship with dedicated permission groups — not new roles. You add the agent's permission group to existing roles. This means your role taxonomy doesn't explode and your governance process stays the same.

What changes per agent

Each agent typically adds:

• Run permission — the user can invoke the agent.
• View output permission — the user can see the agent's recommendations.
• Take action permission — the user can approve agent-suggested actions (often a higher bar than view).

Some agents also need read access to additional data — e.g., the Cash Forecast agent needs read on AR transactions.

The recommended model

For each agent:

1. Identify the seeded Oracle permission group.
2. Map it to existing job/abstract roles by user persona.
3. Add to those roles in your custom variants (never edit Oracle-seeded roles directly).
4. Test in a non-prod environment.
5. Promote to prod with normal change management.

Anti-patterns to avoid

• One mega "AI user" role that gets all agent permissions. This bypasses the principle of least privilege.
• Service accounts that have permissions a human user doesn't. If a user can't see it directly, don't give the agent (running on their behalf) elevated access.
• Skipping the diff — always export the role definitions before and after, diff, and store the result with your change record.