Who Approves, Who Acts: Governing AI and Non-Human Identities in the Brazil Release

This post covers the Brazil features that decide who or what can approve, call tools, or act on your instance : Intelligent Approvals, AI Control Tower, MCP Server Console, and the identity controls for integrations and agents. For each one: what it does, what you need, and what to check before go-live.

Brazil GA is expected in November 2026. Some items below arrived in Australia; I've labelled them so you know what is actually new.

1. Intelligent Approvals

What it does

Reads a natural-language policy document (T&E, procurement, CAB guidelines) and extracts the trigger conditions and approval criteria. No rule scripting.
At runtime, evaluates each matching approval and either auto-approves, auto-rejects, or routes it to a human when the outcome is unclear.
Suggests edits to the policy document to make it clearer and raise the automation rate.
Logs every decision with the policy used, the clause that applied, and the reasoning.

What you need

Item

Detail

Source format

PDF today. Knowledge Base articles, IRM policies and external cloud documents are on the roadmap, so check what your Brazil build supports before promising it.

|
|

Licensing

Now Assist for Platform or AI Platform Advanced/Prime for runtime decisions; AI Platform Foundation covers policy creation only.

|
|

Assist consumption

0 assists to create or publish a policy; 25 assists per approval evaluated at runtime.

|
|

Who builds it

The policy owner uploads, tests and publishes. No developer is needed.

Before go-live

Size the cost. 2,000 approvals a month × 25 assists = 50,000 assists a month. Do this sum before you pick a policy with high volume.
Start with one well-written policy. A T&E policy with clear thresholds by region, role and amount is the classic first candidate. Vague policies produce more human fallbacks.
Run the built-in test results and act on the suggested improvements before publishing.
Agree who owns the policy document. Once it drives approvals, editing it is effectively a production change. Put the document under the same change discipline as a flow.
Keep a human path. Check that the fallback approver group is staffed and has an SLA.
Know where it sits. Classic approval rules are replaced by the Workflow Studio Ask for Approval action, so plan Intelligent Approvals alongside your existing approval flows rather than as a separate engine.

2. AI Control Tower

What changes in Brazil

AI asset usage policies can now respond automatically to detected threats, including blocking an AI agent, domain or model.
Domain separation is supported for AI Control Tower, which matters for MSPs and multi-company instances.
Recommendations apply automatically: in AI Risk and Compliance, an accepted recommendation is applied to the AI asset straight away.
Version 23.0 of AI Risk and Compliance adds updated playbooks and risk classification for unmanaged AI assets.

What gets installed

AI Control Tower is several plugins, not one. Check you have all of them at the required versions:

Plugin

AI Asset Management

sn_ai_asset_mgmt

|
|

AI Control Tower Core

sn_ai_governance

|
|

AI Risk and Compliance integration

sn_grc_ai_irm_intg

|
|

Engagement dashboard

sn_ai_engagement

|
|

Value dashboard

sn_ai_value

|
|

AI Discovery

sn_ai_disc

Before go-live

Upgrade AI Risk and Compliance step by step. The release notes say to go through each version in sequence rather than skipping.
Decide managed vs unmanaged. Marking an asset unmanaged cancels its active workflows, tasks and governance processes. Agree the rules before people start toggling.
Test enforcement policies in sub-production first. A blocking policy that fires on the wrong agent stops a business process. Run each policy in a non-production instance with realistic agents before enabling it in production.
Name an owner per asset. Failed indicators create issues for the asset's product owner, so every asset needs one.

3. MCP Server Console and AI Gateway

Two directions to govern

Inbound: external AI clients (for example Claude or an enterprise agent platform) calling tools on your instance. Managed in MCP Server Console.
Outbound: your agents (including Build Agent) calling external MCP servers. Routed through the AI Gateway.

MCP Server Console: key facts

OAuth client registration is built into the server-creation wizard, and a preconfigured Quickstart Server gives you incident and case lookup and summary tools. (These arrived in Australia.)
Tool annotations can be set on all supported tool types. They appear in the tools/list response, so MCP clients can apply the right permission policy.
OAuth inbound integrations are created in the Machine Identity Console, one per client.
Supervised vs autonomous mode is a client setting. Whether a tool call needs human confirmation is controlled by the connecting MCP client, not the server, so your governance policy must cover client configuration too.
Usage telemetry (usage, latency, connection health per server, tool and client) is visible in AI Control Tower.

Third-party identity provider for MCP

Requirement

Detail

Minimum version

Australia Patch 3 or Zurich Patch 10

|
|

Microsoft Entra

Australia Patch 4 or Zurich Patch 11 onwards

|
|

Setup

OIDC provider record in oidc_provider_configuration, then create the server in MCP Server Console

|
|

Role

admin

AI Gateway (outbound)

Agent-to-MCP traffic goes through the gateway, not directly to the external server, so authentication, policy and tool-call logging sit in one place.
Tools are scanned before activation. Detected risks include tool poisoning (tool descriptions that try to manipulate the agent) and unauthorised file-system writes.
System properties control whether Now Assist Guardian tool scanning and the deeper scanning are on. Check both are enabled.

Before go-live

Start read-only. Expose read-only tools first and mark them as read-only with annotations.
One OAuth integration per client. Never share client credentials between tools or teams.
Allow-list external servers behind the AI Gateway and give each one a named owner.
Write a client policy that states which MCP clients may run tools autonomously, since the server cannot enforce it.

4. Non-human identity controls

Integrations, flows, agents, MCP clients and clone jobs all act on your instance under some identity. These are the controls to review.

Brazil authentication updates (confirm each in the Platform Security release notes for your patch)

Policy-based, identifier-first login.
Expiry alerts for SAML signing and encryption certificates.
Controls to restrict Basic Authentication.
Federated identity for Azure and Google Cloud connections, so those integrations don't need static secrets.
Trusted token issuers for MCP clients.
SSL/TLS certificate policies per endpoint.

Flow roles: rules that catch people out (not new, but newly relevant with agents)

Rule

Why it matters

Roles can only be assigned to flows that run as the initiating user. System-user flows run with the system role.

Check which run-as mode each sensitive flow uses.

|
|

admin, security_admin and application admin roles cannot be assigned.

Flows can't be used to hand out admin access.

|
|

Subflows do not inherit roles from the parent flow.

A parent flow with the right role can still fail, or behave differently, in its subflow.

|
|

Flow roles override AI agent roles.

An agent calling a flow runs with the flow's roles, not its own. Audit flows that agents can trigger.

|
|

Copying a flow removes its assigned roles.

Copied flows silently fall back to system or user roles.

|
|

To edit a flow you need the same roles as the flow.

Plan this into your delegated-developer role design.

Clone authentication (Australia, now standard)

Clone targets use OAuth 2.0 instead of a stored admin username and password. The source instance is the OAuth client; the target is the authorisation server.
Each clone request uses a short-lived JWT token. oauth_admin is needed on the target only for the one-time setup.
If a token expires, the Clone Admin Console asks you to re-authorise before a clone can be requested. Build that into your clone runbook so scheduled clones don't stall.

Before go-live

Inventory every non-human identity: integration users, OAuth clients, MCP clients, agents, and flows with assigned roles.
Turn off Basic Auth wherever an OAuth or federated option now exists.
Route certificate expiry alerts to a monitored queue, not one person's inbox.
Review flows that AI agents can trigger, because flow roles override agent roles.

Quick checklist

Assist budget calculated for each Intelligent Approvals policy
Policy documents that drive approvals placed under change control
All AI Control Tower plugins at the required versions; AI Risk and Compliance upgraded in sequence
Enforcement policies tested in sub-production
One OAuth inbound integration per MCP client; read-only tools first
Client-side policy for autonomous tool execution written down
External MCP servers allow-listed behind the AI Gateway, with tool scanning enabled
Non-human identity inventory complete; Basic Auth removed where possible
Flows callable by AI agents reviewed for their assigned roles
Clone runbook updated for OAuth re-authorisation

Part 2 covers the operational side of Brazil: Log Export Service, Live Connect, change lockdowns, incident timers, and upgrade readiness.

News Jace Pro NJP

Who Approves, Who Acts: Governing AI and Non-Human Identities in the Brazil Release

1. Intelligent Approvals

2. AI Control Tower

3. MCP Server Console and AI Gateway

4. Non-human identity controls

Quick checklist

Sources