Two access changes worth understanding: AI ACLs and granular roles

[Claire_Conant]

If you're setting up AI agents or managing who can administer your instance, two access changes are worth knowing about before you run into them unexpectedly. You could interpret both as "access got stricter" but they're separate: one controls whether specific AI ACL types have access by default, the other gives you finer-grained roles to hand out instead of the full admin role. They trigger differently and ship in different releases (Australia and Brazil), so it helps to keep them apart from the start.

What's changed for AI ACL types?

You'll run into this one if you're on a new or freshly reset instance (wiped back to base system defaults).

Starting with the Brazil release, these instances default to denying access to specific AI ACLs rather than allowing access wherever no ACL exists. You grant access deliberately through an ACL, per record, instead of relying on a permissive default.

The deny-by-default ACL configuration applies to these five AI ACL types:

• gen_ai_agent
• gen_ai_workflow
• gen_ai_skill
• flow
• flow_action

For flow and flow_action, the deny only applies when a flow or action is invoked by AI. Flows triggered any other way aren't affected, and access is set through an Allow If ACL using the invoke_from_ai operation, not through the setup used for agents and workflows.

A separate platform property, glide.sm.default_mode, also uses a deny-by-default approach but works differently and isn't covered here.

The ACL configuration change reflects a deliberate shift: an AI agent applies its permissions at machine speed across every task it runs, so a permission a person might over-use once, an agent uses repeatedly. Starting from deny keeps that in check.

How does this affect upgrades?

An instance that's upgraded in place keeps its existing ACLs and isn't moved onto this deny-by-default starting point just by upgrading. That's why two instances can behave differently even on the same release: the starting posture depends on how the instance came to be, not just the version it's running. You're not stuck on the old default, though. When you're ready, you can opt-in through Security Center.

If you're working with an agent, skill, workflow, or flow and access looks different than you expected, this is the change worth checking first—it can apply without anyone having touched a configuration setting.

What's changed for admin access?

The second change is a different kind of thing entirely. Unlike deny-by-default, this one shows up on upgraded instances too.

The Australia release introduces more than 300 granular admin roles, built around specific features and tasks, so you can grant users only the access they need instead of the full admin role. Australia also adds the instance_operator role, built for people who keep instances running day to day reviewing logs, diagnosing problems, or keeping workflows moving. It deliberately does not grant scripting access, the ability to modify flows or code, or the ability to assign roles.

This one is opt-in. The admin role works exactly as it did before, and nothing stops working if you don't adopt granular roles. Existing admin users keep all their current access. If you're wondering whether existing ACLs or scripts that rely on the admin role will suddenly stop working: they won't. Access that worked before continues to work. Moving toward least privilege is a decision you can make on your own timeline, not something Australia forces on you.

Because of that, granular admin roles are rarely the reason a previously working component suddenly returns an access error. If you haven't adopted them, they haven't changed anything.

Which change applies to you?

The quickest way to orient yourself is to check how your instance was set up. If it was created fresh or fully reset to base system defaults, and the errors involve an agent, skill, workflow, or flow, the deny-by-default ACL configuration is the first place to look. Access that used to be available by default may now need to be defined.

From there, you can set access controls for the affected record type and choose who gets in: any authenticated user, users with specific roles, or public access.

If instead you're weighing granular admin roles, treat that as a planning decision rather than a repair. It's worth thinking through.

More info on this topic

Deny-by-default ACL configuration

Configuring user access and data permissions for agentic workflows

Granular admin roles