Inventory AI Models in SageMaker, Vertex AI and Azure AI Foundry

To inventory the AI models you run in Amazon SageMaker AI, Google Vertex AI and Azure AI Foundry, give each cloud a dedicated read-only identity that can list models, registry versions and endpoints, then record for every model where it came from, which version each endpoint serves, whether the endpoint is reachable from the public internet, which encryption key protects it and how much access its runtime identity holds. Do it on a schedule, not once, because endpoints get created and deleted faster than any spreadsheet can follow. The identity should never be able to call an endpoint or read model files, so the inventory itself does not become a new path to your data.

This post walks through how to do that with the cloud consoles and CLIs you already have, which read permissions each cloud needs, what to record and what to flag. Then it shows how Safeguard's Amazon SageMaker AI, Google Vertex AI and Microsoft Azure AI Foundry integrations do the same reads on a schedule and turn them into an AI asset inventory with continuous tests.

Key takeaways

• An AI model inventory is a governance requirement, not a nice to have. NIST's AI Risk Management Framework names it in GOVERN 1.6, and US federal agencies must publish an AI use case inventory at least annually under OMB M-25-21.
• The cloud ML platforms each hold the facts you need in their control plane: models, registry versions, endpoints, deployments, encryption settings and runtime identities. You can read all of it with list and describe permissions alone.
• The six questions worth asking of every deployed model are: where did it come from, is the version pinned, is the endpoint public, is it network isolated, is it encrypted with your own key, and how broad is its runtime identity.
• Safeguard's Amazon SageMaker AI, Google Vertex AI and Microsoft Azure AI Foundry integrations (GA) read that control plane with a read-only identity, never invoke an endpoint, and store the results as AI asset inventory entries with continuous tests.
• The tests cover asset inventory, public access, network isolation, customer-managed keys, least-privilege identities, pinned model versions, licence risk and model provenance.
• AI-BOM discovery (GA) pulls these cloud assets together with AI SDK imports, model files, prompts and agents found in code.
• AI-SPM (GA) is static scanning of model files (pickle, PyTorch, safetensors, GGUF and ONNX) for hidden code-execution instructions and unsafe references. The cloud integrations in this post do not read model files today.
• Policies and gates (GA) act with Block, Warn or Notify, and approvals run through exceptions.

The situation

The request usually arrives from one of three directions. An auditor or a customer questionnaire asks "list every AI model in production, with its source and owner." A platform team finds an inference endpoint nobody remembers creating, still running, still billed. Or a security lead reads a model supply chain advisory and asks the obvious follow-up: do we run that model anywhere, and if so, who can reach it?

In most organisations the honest answer starts with "it depends which cloud." Data science teams in one business unit use Amazon SageMaker AI with JumpStart. Another group uses Google Vertex AI and pulls from Model Garden. A product team built on Azure AI Foundry because the rest of the company already runs on Microsoft Entra ID. Each platform has its own registry, its own idea of an endpoint and its own way of expressing who can call it. Nobody has a single list.

A bad week looks like this. The questionnaire is due Friday. Someone exports a spreadsheet from each console by hand. The SageMaker export misses two regions. The Vertex AI export lists models but not which ones are deployed. The Foundry export comes from one subscription out of several. By the time the spreadsheet is merged, an endpoint has been deleted and two new ones exist. The answer that goes out is already wrong, and nobody can say which rows are.

The fix is not a better spreadsheet. It is a repeatable read of each cloud's control plane, with the same fields recorded for every model, kept current on a schedule, and diffed so that an asset that disappears is marked rather than silently dropped.

The rules behind the inventory

None of the frameworks below tell you which tool to use. They do tell you what an examiner, a customer or an internal auditor will expect to see. This is not legal or audit advice; read the primary text for your own obligations.

NIST AI RMF, GOVERN 1.6

The NIST AI Risk Management Framework (AI 100-1) organises AI risk work into four functions: Govern, Map, Measure and Manage. Subcategory GOVERN 1.6 reads: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities." The NIST AI RMF Playbook expands on it, describing an AI system inventory as an organised database of artifacts and the information about them. The two phrases that matter for this post are "mechanisms" and "resourced": a one-off export is not a mechanism, and an inventory nobody owns is not resourced.

The same framework's MAP function asks you to understand the context each system runs in, which is where provenance, network exposure and runtime identity come in. An inventory that lists model names without those attributes satisfies the letter of GOVERN 1.6 and very little of its purpose.

OMB M-25-21, Section 3(b)(v)

For US federal agencies, OMB Memorandum M-25-21 (April 2025) sets the current rules for AI governance. Section 3(b)(v) requires each agency, other than the Department of Defense and the Intelligence Community, to inventory its AI use cases at least annually, submit the inventory to OMB and post a public version on its website, and it encourages agencies to update the public version on an ongoing basis. A use case inventory is broader than a model inventory, but you cannot build the first without the second. Contractors and software suppliers to agencies should expect the questions to flow down to them.

OWASP Top 10 for LLM Applications, LLM03:2025 Supply Chain

The OWASP Gen AI Security Project lists supply chain as LLM03 in its 2025 list. It describes how LLM supply chains can affect the integrity of training data, models and deployment platforms, and calls out third-party pre-trained models and fine-tuning methods such as LoRA and PEFT as sources of new supply chain risk. Its prevention guidance includes keeping an inventory of components and vetting model sources. You cannot vet the source of a model you do not know you are running.

CycloneDX ML-BOM

CycloneDX, an Ecma standard (ECMA-424), defines a Machine Learning Bill of Materials (ML-BOM) for "model and dataset transparency." An ML-BOM is the exchange format; the cloud inventory is where most of its facts come from. If a customer asks for an AI-BOM, the model source, version and deployment details in this post are the fields they expect to see populated.

What each cloud calls a model

Before you read anything, align the vocabulary. Each platform splits "the model" into several resources, and an inventory that only reads one of them will miss things.

Naming note: Microsoft's documentation now calls the product Microsoft Foundry, and parts of Google's Vertex AI documentation now appear under the Gemini Enterprise Agent Platform name. This post uses the names on Safeguard's integration cards, Amazon SageMaker AI, Google Vertex AI and Microsoft Azure AI Foundry, because that is what you will search for in the app.

Step by step, with or without Safeguard

The steps below work with the native CLIs and consoles. They are the same reads Safeguard's integrations make, so you can do them by hand first to see what your estate looks like.

Step 1: Decide the scope before you grant anything

Write down, for each cloud, the boundary the inventory must cover.

• AWS: which accounts, and which regions. SageMaker AI resources are regional, and teams often experiment in a region nobody else uses.
• Google Cloud: which projects, or which organization or folders, so that new projects are picked up automatically.
• Azure: which subscriptions, resource groups or management group.

A scope that says "the main account" is how the two forgotten regions happen. If you can, scope to the organization level and narrow from there.

Step 2: Create a dedicated read-only identity per cloud

Use one identity per cloud whose only job is the inventory. Do not reuse a compliance scanner identity, a CI identity or a person's credentials. The reason is blast radius: if the inventory credential leaks, it should reveal configuration and nothing else.

The least-privilege permission sets, taken from the reads Safeguard documents for each integration, are below. They work just as well for a hand-built inventory.

Amazon SageMaker AI. List and describe calls on models, endpoints, endpoint configurations, inference components, Model Registry groups and packages, tags and JumpStart hub content; three IAM reads to judge execution role breadth; and ec2:DescribeRegions to find enabled regions. Safeguard's docs advise against the AWS managed policy AmazonSageMakerReadOnly because it also grants Feature Store record reads, sagemaker:Search and Cognito user lists, which an inventory does not need.

Google Vertex AI. A custom role holding aiplatform.locations.list, aiplatform.endpoints.list, aiplatform.models.list, serviceusage.services.get, resourcemanager.projects.get, resourcemanager.projects.list and, optionally, resourcemanager.projects.getIamPolicy to judge service account breadth. The predefined roles/aiplatform.viewer also works but grants aiplatform.endpoints.explain and aiplatform.locations.evaluateInstances, which an inventory never calls.

Azure AI Foundry and Azure Machine Learning. The built-in Reader role, which Microsoft describes as able to view all resources without making changes, on the subscriptions or resource groups that hold your workspaces and Foundry resources. Every read is an Azure Resource Manager call, so no Azure Machine Learning data-plane role is needed.

Step 3: Enumerate every serving surface, not just the registry

A registry tells you what could be deployed. An endpoint tells you what is running. You need both, joined.

For SageMaker AI, that means listing models, endpoints, endpoint configurations and inference components in every region, then the Model Registry groups and their versions. For Vertex AI, it means listing models and endpoints in every location Vertex AI offers each project, and reading which models are deployed on each endpoint. For Azure, it means listing workspaces, hubs and projects, then online endpoints and their deployments, serverless API endpoints, registered model versions, and Foundry resources with their model deployments and projects.

The join key is the model reference on the endpoint or deployment. Every endpoint row should point at a model row. An endpoint whose model you cannot resolve is a finding in itself.

Step 4: Record the same fields for every model

Use one schema across all three clouds so the inventory can be sorted and filtered as one list. The template below is the minimum that answers an auditor and a security reviewer at the same time.

The last two rows are the ones most hand-built inventories skip. Without first seen and last seen you cannot tell a new asset from an old one, and without an owner the inventory has nobody to send a finding to.

Step 5: Flag what needs a decision

Recording the fields is half the job. The other half is a short list of conditions that need a human to decide, written down so the decision is the same every time.

These are stances, not laws. A public endpoint is fine for a public demo. A floating version is fine in a sandbox. The point is that each exception is a recorded decision with a name on it.

Step 6: Run it on a schedule and keep history

Run the read daily or more often, and keep each run's results. When an asset disappears, mark it inactive with the date rather than deleting the row. Auditors ask "what was running in March," and a current-state list cannot answer that.

Step 7: Keep the inventory out of the data path

Two rules keep the inventory from becoming a risk of its own. First, the identity never calls the inference API: no sagemaker:InvokeEndpoint, no aiplatform.endpoints.predict, no Azure data-plane access. Second, it never stores container environment variables. Model containers are a common place for teams to put API keys and connection strings, and an inventory has no reason to read them.

Where does each model come from?

Provenance is the field that turns a list into a risk register, and it is the hardest to get right because the clouds record it indirectly.

SageMaker AI and JumpStart

AWS describes JumpStart as providing pretrained, open-source models you can incrementally train and tune before deployment. When the SageMaker Python SDK or Studio deploys a JumpStart model, it adds tags naming the JumpStart model ID, version, model type and hub content ARN. Reading those tags, plus the hub content entry they point to, tells you which catalog model you are running and whether AWS lists it as supported, deprecated or restricted. Without the tag read, the same model looks like any other container with model data in S3, and its provenance shows as unknown.

Models that are not from JumpStart point either at your own S3 model data location or at a Model Registry package. AWS's Model Registry lets you catalog models for production, manage versions, attach metadata such as training metrics, and view lineage. A registry package with an approval status is stronger provenance than a bare S3 path.

Vertex AI and Model Garden

Google describes Model Garden as a model library for discovering, testing, customising and deploying models from Google and Google partners. Models in the Vertex AI Model Registry record their source: Model Garden, your own training job, or an upload. Reading the public Model Garden catalog entry a model names fills in the display name and category. If the entry cannot be read, the model is still inventoried; you just lose the catalog context.

Azure AI Foundry and Azure Machine Learning

Serverless API endpoints name the catalog model they serve. Online deployments name a registered model and version. Foundry resources (accounts of kind AIServices) list their model deployments and each deployment's version upgrade option. One gap matters here: Azure Resource Manager does not return catalog model licences, so a licence check has to point the reviewer to the model card in the Foundry catalog rather than answer it automatically.

What does a pinned model version look like on each cloud?

A pinned endpoint serves one specific, immutable model version. An unpinned endpoint can change what it serves without anyone redeploying it.

• SageMaker AI: an endpoint configuration's production variant names a model, which names a container and model data. Pinning means that chain resolves to a specific Model Registry version or a specific artifact, not a moving reference.
• Vertex AI: a deployment is fixed to one model version when it references that version rather than a moving alias.
• Azure: online deployments reference a model name and version. Foundry model deployments carry a version upgrade option that decides whether the platform moves the deployment to newer versions on its own.

An auto-upgrade setting is a legitimate choice for some workloads. It should still be a recorded choice, because it means the model your evaluation tested may not be the model in production next month.

Is the endpoint reachable, and can it reach out?

Public reachability and network isolation are two different questions.

Public reachability asks whether anyone with credentials can call the endpoint over the public internet. On Vertex AI that is whether the endpoint is served on the public API or only over private networking. On Azure it is the public network access setting on the workspace, endpoint or Foundry resource.

Network isolation asks whether the model's container can call out. AWS's documentation states that SageMaker AI training and deployed inference containers are internet-enabled by default, and that you can turn on network isolation by setting EnableNetworkIsolation to true when you create the model. Azure Machine Learning's managed network offers an "Allow only approved outbound" mode, which Microsoft describes as a way to minimise the risk of data exfiltration. A model that loads a file at start-up and then fetches nothing should not have open egress.

Whose keys encrypt it?

Each cloud encrypts at rest by default with provider-managed keys. Google's CMEK documentation says Vertex AI handles encryption without any action on your part, and that customer-managed encryption keys are the option when you want to control the keys yourself. The inventory question is not whether data is encrypted. It is whose key it is, because that decides who can revoke access in an incident and what you can show an auditor who asks for key ownership. Record the key, or record that there is none, for every endpoint.

How broad is the runtime identity?

A model endpoint runs as an identity. If that identity can read every bucket in the account, then a model that misbehaves, or a container that is compromised, can too.

• SageMaker AI: read the execution role's attached managed policies and inline policies. A role with AdministratorAccess or a wildcard s3:* on all resources is the finding. If the role lives in another account, an inventory scoped to this account cannot judge it; record that it was not judged rather than guessing.
• Vertex AI: read the project IAM policy and check whether the deployed model's service account holds Owner, Editor or Vertex AI Administrator on the project.
• Azure: read the role assignments of each endpoint's, workspace's and project's managed identity.

If you choose not to grant the IAM read permissions, the inventory still works. The breadth field just reads "not judged," which is honest and better than a silent blank.

How Safeguard does this

Safeguard's Amazon SageMaker AI, Google Vertex AI and Microsoft Azure AI Foundry integrations (GA) do the reads above on a schedule, with a read-only identity, and store the results in the AI asset inventory with continuous tests. Each one is a separate connection from the matching cloud compliance connection, so its identity holds only the ML inventory reads. Safeguard never invokes an endpoint or sends a prediction request, and its docs state that no customer data from these integrations goes to third-party LLMs.

The steps below are taken from the integration pages at docs.safeguard.sh. The commands and policies are as the docs show them; they were not run for this post.

1. Find the card. Open Integrations and choose the Project/Product tab. The AI Model filter shows only AI model cards. Each integration is switched on per workspace; if you do not see the card, ask your Safeguard contact.

2. Connect Amazon SageMaker AI. Click Connect on the Amazon SageMaker AI card, name the connection, choose the cross-account role method and save. Safeguard generates the connection's external ID on that first save. The dialog's Setup steps section then shows a CloudFormation template, AWS CLI commands, Terraform, the permissions policy and the trust policy with your external ID and Safeguard's principal filled in. The docs give this permissions policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SafeguardSageMakerInventoryRead",
      "Effect": "Allow",
      "Action": [
        "sagemaker:ListModels",
        "sagemaker:DescribeModel",
        "sagemaker:ListEndpoints",
        "sagemaker:DescribeEndpoint",
        "sagemaker:DescribeEndpointConfig",
        "sagemaker:ListInferenceComponents",
        "sagemaker:DescribeInferenceComponent",
        "sagemaker:ListModelPackageGroups",
        "sagemaker:ListModelPackages",
        "sagemaker:DescribeModelPackage",
        "sagemaker:ListTags",
        "sagemaker:DescribeHubContent"
      ],
      "Resource": "*"
    },
    {
      "Sid": "SafeguardExecutionRoleBreadthRead",
      "Effect": "Allow",
      "Action": [
        "iam:ListAttachedRolePolicies",
        "iam:ListRolePolicies",
        "iam:GetRolePolicy"
      ],
      "Resource": "*"
    },
    {
      "Sid": "SafeguardRegionsRead",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeRegions"
      ],
      "Resource": "*"
    }
  ]
}

To deploy the template from the CLI and print the role ARN, the docs show:

aws cloudformation deploy --stack-name safeguard-ml-inventory --template-file safeguard-ml-inventory.yaml --capabilities CAPABILITY_NAMED_IAM
aws cloudformation describe-stacks --stack-name safeguard-ml-inventory --query "Stacks[0].Outputs[?OutputKey=='RoleArn'].OutputValue" --output text

The template creates a role named SafeguardMlInventory with a maximum session of one hour; Safeguard assumes it again for each run, so there is nothing to rotate. Paste the role ARN into the dialog, optionally list regions (empty means every enabled region), save, and click Check access. Check access tries sagemaker:ListEndpoints; a success message names the region and role it read as, and a failure names the missing permission. If your installation cannot assume roles, or your policy forbids cross-account roles, the docs offer an IAM user access key with the same policy instead, which you rotate yourself.

3. Connect Google Vertex AI. Create a dedicated service account and the custom role safeguardMlInventory, grant it on each project to inventory, and create a JSON key. The docs show these gcloud commands, with your project filled in inside the app:

gcloud iam service-accounts create safeguard-ml-inventory \
  --project=<PROJECT_ID> --display-name="Safeguard ML inventory (read-only)"
gcloud iam roles create safeguardMlInventory --project=<PROJECT_ID> \
  --title="Safeguard ML inventory" --stage=GA \
  --permissions=aiplatform.locations.list,aiplatform.endpoints.list,aiplatform.models.list,serviceusage.services.get,resourcemanager.projects.get,resourcemanager.projects.list,resourcemanager.projects.getIamPolicy
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member="serviceAccount:safeguard-ml-inventory@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role="projects/<PROJECT_ID>/roles/safeguardMlInventory"
gcloud iam service-accounts keys create safeguard-ml-inventory.json --iam-account=safeguard-ml-inventory@<PROJECT_ID>.iam.gserviceaccount.com

Organization mode adds the same role at organization level plus roles/browser so new projects are found. Then click Connect on the Google Vertex AI card, paste the whole JSON key, optionally list projects, save and click Check access. Safeguard signs in, lists the projects and asks Google Cloud whether the first project grants the four Vertex AI and Service Usage reads; a failure names each missing permission. A service account JSON key is the only method today; the docs say Workload Identity Federation is not available yet. Treat the key file as a secret: paste it, then delete it. If you use Terraform, the docs advise creating the key outside Terraform state, because a key resource stores the private key in the state file.

4. Connect Microsoft Azure AI Foundry. Register an app in Microsoft Entra ID, create a client secret (or use a certificate), and assign the built-in Reader role on each subscription or resource group to read. The docs show this Azure CLI route:

az login
az account set --subscription "<SUBSCRIPTION_ID>"
az ad sp create-for-rbac \
  --name "safeguard-ai-foundry-reader" \
  --role "Reader" \
  --scopes "/subscriptions/<SUBSCRIPTION_ID>"
az role assignment list --assignee "<APP_ID>" --scope "/subscriptions/<SUBSCRIPTION_ID>" -o table

Narrower scopes (one resource group) and broader ones (a management group) use az role assignment create with the matching scope. Click Connect on the Microsoft Azure AI Foundry card, enter the tenant ID, client ID and client secret or certificate, optionally list subscriptions or a management group, save and click Check access. A success message reports how many subscriptions will be read and how many workspaces and AI services accounts are visible in the first one. Managed identity and personal sign-in are not supported for this connection; it signs in only as a service principal.

5. Let the tests run. None of these integrations uses webhooks. The inventory is read each time the connection's tests run, on their schedule or when you run them by hand. Each run produces AI asset inventory entries and continuous tests for asset inventory, public access, network isolation, customer-managed keys, least-privilege execution roles, service accounts or identities, pinned model versions, licence risk and model provenance.

6. Read the inventory. For each asset Safeguard stores names, resource identifiers, regions or locations, images and model data or artifact locations, model ids and versions, instance or machine types, and the network, encryption and identity findings. An asset that disappears is marked inactive, not deleted, which gives you the history Step 6 asked for. Credentials are encrypted at rest and never shown again after you save them.

7. See it alongside the rest of your AI estate. AI-BOM discovery (GA) catalogues AI assets across code, cloud and connected SaaS: AI SDK imports, model weight files, prompt templates, notebooks and MCP server configuration in code; managed inference endpoints discovered through cloud connectors; and unsanctioned AI tools surfaced through shadow-AI detection. The assets for a product are assembled into an AI-BOM, a point-in-time snapshot of that product's AI footprint, which is what you hand to a customer who asks for one.

8. Scan the model files you bring in. AI-SPM (GA) is static scanning of model files without loading them. For pickle and PyTorch files it looks for hidden code-execution instructions, such as imports of dangerous modules and load-time steps, mapped to CWE-502 and CWE-94. It confirms safetensors files are tensor-only, validates GGUF containers, and inspects ONNX graphs for non-standard operators and external-data paths that escape the model directory (CWE-22). Findings land in the unified findings model. This applies to model artifacts ingested through your registries and pipelines, such as the Hugging Face integration; the SageMaker, Vertex AI and Foundry integrations described here read configuration only and do not fetch model artifacts today.

9. Hold the line in CI. Policies and gates (GA) evaluate builds with Block, Warn or Notify, and approval for an exception runs through the exceptions workflow, so a team that needs to ship past a rule records why. Pair that with the inventory's decision table from Step 5, so the same stances apply whether a finding comes from a pipeline or from a cloud read.

What Safeguard reads, and what it never touches

The environment variable rule is worth repeating: Safeguard's docs state that a model's environment variables can hold secrets, and that Safeguard drops them from every response unread and never stores them.

Troubleshooting you will probably meet

• SageMaker AI, JumpStart models show as unknown provenance. The policy lacks sagemaker:ListTags. Add it.
• SageMaker AI, execution roles show as not judged. The three iam: reads are missing, or the role lives in another account. The first is fixable; the second is expected.
• Vertex AI, service accounts show as not judged. The optional resourcemanager.projects.getIamPolicy is not granted. Grant it (it is in the custom role) or accept the result.
• Vertex AI, one location fails. The role lacks a list permission in that location; the other locations are still read.
• Azure, sign-in fails after months of working. The client secret expired. Create a new one, update the connection, then delete the old one.
• Azure, a US Government tenant cannot sign in. The tenant is in another Azure cloud; set the connection's cloud to match.

What Safeguard does not do

• It does not scan model files in your cloud storage today. The SageMaker, Vertex AI and Foundry integrations read control-plane configuration. The artifact read permission is reserved for a later scan and is off by default. If you need model files scanned, bring them in through a path AI-SPM covers.
• It does not test model behaviour. It never sends a prediction request, so it says nothing about accuracy, bias, jailbreak resistance or output safety. Evaluation and red teaming of model behaviour stay with your ML and safety teams.
• It does not decide your stances. It reports that an endpoint is public, unpinned or running with a broad identity. Whether that is acceptable for a given workload is your decision, and the exception should carry a named owner.
• It does not read licences Azure does not return. For Foundry catalog models the licence test points you to the model card; a person still has to read it.
• It does not judge identities it cannot see. An execution role in another AWS account, or a service account without the optional IAM read, is reported as not judged.
• It does not replace your use case inventory. A model inventory feeds an OMB-style AI use case inventory, but purpose, impact and risk classification are judgements your governance process makes.
• It does not fix cloud configuration for you. Turning on network isolation, moving to a customer-managed key or narrowing a role is a change in your cloud, made by your team through your own change process.

Common mistakes

• Inventorying the registry and calling it done. A registry version that is not deployed is low risk; an endpoint serving a model that never went through the registry is the one you need to find.
• Reading one region or one project. Experiments land wherever a notebook's default region points. Scope to every enabled region and to the organization or folder level.
• Using a broad managed role because it is easy. AmazonSageMakerReadOnly and roles/aiplatform.viewer grant more than an inventory needs. Use the narrow custom policy or role.
• Reusing a person's credentials. When that person leaves, the inventory stops, usually without anyone noticing for weeks.
• Exporting environment variables with the configuration. Container environments often hold keys. Drop them before anything is stored.
• Deleting rows when assets disappear. Mark them inactive with a date. History is what answers the auditor's "what was running then."
• Treating "provider default encryption" as a finding everywhere. It is only a finding where your policy requires your own keys. Write that policy down first.
• Leaving long-lived keys unrotated. Prefer the role assumed with an external ID on AWS. For Google service account keys and Azure client secrets, set a rotation date and a reminder.

FAQ

How do I list all models deployed in SageMaker across every region?

Use an identity with the SageMaker AI list and describe permissions plus ec2:DescribeRegions, enumerate enabled regions, and in each region list models, endpoints, endpoint configurations and inference components, then describe each to resolve which model and version every endpoint serves. Add Model Registry groups and packages to see what is registered but not deployed.

What is the least-privilege role for a Vertex AI model inventory?

A custom role with aiplatform.locations.list, aiplatform.endpoints.list, aiplatform.models.list, serviceusage.services.get, resourcemanager.projects.get and resourcemanager.projects.list, plus resourcemanager.projects.getIamPolicy only if you want service account breadth judged. It is narrower than the predefined Vertex AI Viewer role.

Does the Azure Reader role let someone call my Foundry deployments?

Reader allows Azure Resource Manager reads and no changes. Safeguard's docs state the integration makes no data-plane call, needs no Azure Machine Learning data-plane role and never needs listKeys, so Reader alone does not give it endpoint keys.

Does Safeguard send my model data to an LLM?

No. Each integration page states that no customer data from the integration is sent to third-party LLMs, and that Safeguard never invokes an endpoint or sends a prediction request.

Can Safeguard scan the model weights stored in S3 or Cloud Storage?

Not through these integrations today. They read configuration only; the artifact read permission is reserved for a later model-artifact scan. AI-SPM (GA) statically scans model files ingested through registries and pipelines it covers, such as Hugging Face.

What counts as an unknown model source?

A model whose origin cannot be traced to a public catalog entry (JumpStart, Model Garden, the Foundry catalog), a registry version or your own training job. On SageMaker AI, a JumpStart model can show as unknown if the inventory identity lacks the tag read permission, so check permissions before you escalate.

How often should the inventory run?

At least daily, and on demand before an audit or after an advisory. Safeguard reads the inventory each time the connection's tests run, on their schedule or when you run them by hand.

Is Workload Identity Federation supported for the Vertex AI connection?

Not yet, according to the integration page. Use a dedicated service account JSON key, rotate it at least every 90 days, and delete the downloaded file after pasting it.

Does this cover Amazon Bedrock or the OpenAI API?

This post covers SageMaker AI, Vertex AI and Azure AI Foundry. AI-BOM discovery (GA) also lists managed inference endpoints discovered through cloud connectors, and Safeguard has separate integrations for hosted model APIs; check each integration page on docs.safeguard.sh for what it reads.

What happens when an endpoint is deleted?

Safeguard marks the asset inactive rather than deleting it, so the inventory keeps a record of what ran and when it stopped.

Related reading: what an AI model risk registry should actually track, an engineering guide to AI bills of materials, how to pin an AI model version and test before you move, does a hosted AI model API count as a component in your product, ML model supply chain: pickle files and weights provenance and discovering shadow AI models in production.

An inventory tells you which models you run and how they are exposed; it does not patch the open source frameworks, serving containers and Python dependencies those models sit on. When a finding traces back to one of those components, the options below close the gap between knowing and fixing.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

This demo is a real CLI session: you install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. The demo fixes a JavaScript dependency, not a model; the same flow applies to the serving code and Python dependencies around the models in your inventory.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once that connection is in place, a platform engineer working through the decision table above can ask about the projects and findings behind a model team's work from the same assistant they already use.

Click through it at your own pace, or open it full screen.

This demo is a real desktop app session: the CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. The same approval step applies when a finding from your model inventory leads to a dependency change in the code that serves the model.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST AI Risk Management Framework
• NIST AI RMF Playbook, Govern
• OMB M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust
• OWASP Gen AI Security Project, LLM03:2025 Supply Chain
• CycloneDX Machine Learning Bill of Materials
• AWS, Model Registration Deployment with Model Registry
• AWS, Run Training and Inference Containers in Internet-Free Mode
• AWS, SageMaker JumpStart pretrained models
• Google Cloud, Introduction to Model Registry
• Google Cloud, Explore AI models in Model Garden
• Google Cloud, Customer-managed encryption keys
• Microsoft Learn, What is Microsoft Foundry
• Microsoft Learn, Azure Machine Learning managed network
• Microsoft Learn, Azure built-in roles
• Safeguard docs, Amazon SageMaker AI integration
• Safeguard docs, Google Vertex AI integration
• Safeguard docs, Microsoft Azure AI Foundry integration
• Safeguard docs, AI-BOM Discovery
• Safeguard docs, AI-SPM
• Safeguard docs, Integrations

Get the Safeguard desktop app, CLI and IDE extensions at safeguard.sh/download, and read the setup guides at docs.safeguard.sh/docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.