Why Data Teams Should Lock OCI Generative AI Models With IAM

A data team signs off on one model for customer-support transcripts. Weeks later someone opens the Console model picker, sees a longer list, and picks another. Nothing errors, which is the problem. OCI Generative AI IAM can now stop that at the policy layer: the September 3, 2026 release note adds a target.model.id condition that limits which models a group can call.

Every model in the picker is a data-sharing decision

Choosing a model means choosing who processes your rows. Legal reviews a model once, but the picker keeps listing everything. The grant that makes everything callable, manage generative-ai-family, is one Oracle's docs recommend only for administrators or sandbox groups. It is also the one that gets handed out when a team is in a hurry.

Embeddings raise the stakes for data teams. Re-embedding a corpus with a different model sends every document to that model. The condition covers generative-ai-chat, generative-ai-text-embedding and generative-ai-text-rerank, so one allowlist governs all three.

Write OCI Generative AI policies as an allowlist

Take the exact model IDs from the model pages Oracle links from its Models by Region page, then write the policy. This follows the examples in Oracle's model access policy docs.

allow group <data-team-group> to inspect generative-ai-model in tenancy

allow group <data-team-group> to use generative-ai-family
in compartment <data-compartment>
where ANY {target.model.id = '<approved-chat-model-id>',
target.model.id = '<approved-embedding-model-id>'}

The first statement is unconditional on purpose. Listing models in the Console sends a request with no model ID, so the conditional policy would decline it. Listing is not invoking: the picker can still show models outside your allowlist, and invoking them is what gets refused.

The condition gates inference only. It does not restrict management operations on the other resource types in the family.

Prefer explicit lists over patterns and exclusions

OCI IAM policy conditions also accept patterns and exclusions. They are tempting, and they are the wrong default for regulated data.

allow group <data-team-group> to use generative-ai-family in tenancy
where target.model.id = /google.gemini-3.*/

Patterns are case-insensitive and automatically grant access to future matching model IDs. Exclusions are not explicit denies: they allow every model you did not exclude, future ones included, and another policy can still grant an excluded model.

An explicit list has a cost. You update the policy whenever you approve, replace or retire a model. That is a small price for knowing what your data can reach.

Remove the broad grants first

Policies are cumulative. If the group, or any other group its members belong to, still holds a broader inference grant for generative-ai-family, generative-ai-chat, generative-ai-text-embedding or generative-ai-text-rerank, your allowlist decides nothing.

oci iam policy list --compartment-id <compartment-ocid> --all \
  --query 'data[].{name:name,statements:statements}' \
  | grep -iE 'name|generative-ai'

This prints each policy name and any statement that mentions Generative AI. It covers one compartment, so repeat it for every compartment that holds policies, then delete or condition the broad statements.

Does the smart model router break model-level control?

The strongest objection: on September 23, Oracle added a smart model router that routes on-demand inference requests across regions, so surely model-level control is moot?

They answer different questions. A routing profile pairs one on-demand model with regions you select within the same realm, and requests are routed only among those regions. The router decides where a request runs. The IAM condition decides which model a group may ask for.

Two caveats keep this honest:

• Oracle's docs say model conditions do not replace regional availability or data-residency planning. Review each profile's region list the way you review the model list.
• The pages I read do not say whether the model condition is evaluated on requests sent through a routing profile. Test it with a real group member before you rely on it.

Your first step this week

Pick the group with the broadest access today. List the models you have actually approved, write the allowlist above, remove the broad grant, and try an unapproved model as a member of that group. Once it refuses, repeat for the next group.

For anyone deploying AI in production, model choice is a data-sharing decision, and this condition finally lets IAM enforce it instead of a wiki page.