Top 10 AI Platform Misconfigurations

Managed AI platforms ship with defaults built for fast experimentation, and many of those defaults are wrong for production: open network endpoints, long-lived keys, logging switched off and broad default service identities. This list ranks the ten configuration mistakes we see most often on Amazon Bedrock and SageMaker, Azure OpenAI and Azure AI Foundry, and Google Vertex AI (which Google's documentation now describes under the name Gemini Enterprise Agent Platform). It is a platform configuration list, not an application list: prompt handling, output trust and retrieval design are covered in the Top 10 LLM Deployment Mistakes. It is written for cloud security engineers, platform teams and the people who review AI landing zones. Every setting named here comes from the provider's own documentation, checked in November 2026; providers rename products and change defaults, so confirm against current documentation before you write policy.

The Top 10 at a glance

The table ranks ten misconfigurations by how often they turn up and how much damage they enable. Each is explained below with the specific setting to change.

#	Misconfiguration	Platform example	First fix
1	Key-based authentication left on	Azure AI services account with `disableLocalAuth` false	Disable local auth, use Entra ID and managed identity
2	Public network access by default	Foundry resource accepting traffic from all networks	Default action deny, private endpoints
3	Invocation logging never enabled	Bedrock model invocation logging off (the default)	Enable logging to S3 and CloudWatch with KMS
4	Broad default service identities	Vertex custom training running as the default Custom Code Service Agent	Per-workload custom service accounts
5	Over-privileged human and app roles	`bedrock:*` or Cognitive Services Contributor granted to apps	Scoped roles per model and action
6	Guardrails optional per request	Bedrock calls that never reference a guardrail	Enforce with `bedrock:GuardrailIdentifier`
7	Notebooks with internet and root	SageMaker notebook with `DirectInternetAccess` and `RootAccess` enabled	VPC-only, root disabled, scoped presigned URL rights
8	No data exfiltration perimeter	Vertex project outside a VPC Service Controls perimeter	Perimeter before endpoints and agents are created
9	Unreviewed data handling settings	Azure OpenAI abuse monitoring storage not assessed against data rules	Document retention, review and residency per deployment
10	Unmanaged model access and quotas	Every model enabled, no spend alerts, no inventory	Allow-list models, budgets and an AI resource inventory

1. Key-based authentication left on

The misconfiguration: AI service accounts are created with API keys that work alongside identity-based access. Keys get pasted into notebooks, environment files, CI variables and chat threads, and anyone holding one can call the model from anywhere the network allows. Stolen keys and cloud credentials are the raw material of LLMjacking, where attackers resell or consume model capacity at the victim's expense; see the LLMjacking breach analysis and the LLMjacking Guide.

Fix it:

Azure: set disableLocalAuth: true on the Microsoft.CognitiveServices/accounts resource and assign the built-in Azure Policy "Azure AI Services resources should have key access disabled (disable local authentication)" at subscription or management group scope. Microsoft notes the gateway can keep honouring previously valid keys until its cache refreshes, usually minutes but possibly several hours, so test with an old key and expect HTTP 401 before you declare it done.
AWS: call Bedrock with IAM roles (instance profiles, task roles, IAM Roles Anywhere) rather than long-lived IAM user access keys, and alert on any access key used against bedrock-runtime.
Google Cloud: use attached service accounts and Workload Identity Federation instead of downloaded service account key files.

Keys that must remain belong in a secrets manager with rotation and an owner. See the OpenAI API Keys Security Guide for the same discipline applied to direct provider keys.

2. Public network access by default

The misconfiguration: Microsoft's documentation states that by default, Foundry Tools (Azure AI services) resources accept connections from clients on any network. Combined with mistake 1, a leaked key works from the open internet. Equivalent exposure on other platforms comes from public online prediction endpoints and notebook servers reachable without a private path.

Fix it: in Azure, switch Networking to "Selected Networks and Private Endpoints" (default action deny), then add virtual network rules, public IP rules or private endpoints. Order matters: Microsoft warns that setting the default to deny without allow rules blocks all access, so add rules first. With private endpoints, clients must use the resource's custom subdomain, and Azure OpenAI uses a different private DNS zone from other Foundry Tools, which is the usual cause of "it works in the portal but not from the app". Allow the trusted services exception (networkAcls.bypass set to AzureServices) only where a listed Azure service authenticating with managed identity genuinely needs it, and set it back to None otherwise. On AWS, reach Bedrock through interface VPC endpoints (AWS PrivateLink) and restrict them with endpoint policies.

3. Invocation logging never enabled

The misconfiguration: AWS documents that Bedrock model invocation logging is disabled by default. Without it, a team investigating key abuse, data leakage or a harmful output has CloudTrail management events but not the prompts, responses, model IDs and token counts per request. Similar gaps exist where request and response logging is optional or, as Google notes, unavailable inside a VPC Service Controls perimeter.

Fix it: enable logging (console Settings, or PutModelInvocationLoggingConfiguration) to S3, CloudWatch Logs or both, in the same account and Region. Use an S3 bucket with ACLs disabled and SSE-KMS, with the key policy allowing kms:GenerateDataKey for the Bedrock service principal. Choose modalities deliberately (text, image, embedding, video), because logs now contain the same sensitive data as the prompts. Two details catch teams out: bodies over 100 KB and binary data go only to S3, and calls through bedrock-mantle are not captured. Each record carries identity.arn, so pass requestMetadata tags (application, tenant, user) to make logs attributable. Treat the log store as a sensitive data store, with its own retention and access review.

4. Broad default service identities

The misconfiguration: training jobs, pipelines and endpoints run as a platform default identity. Google documents that custom training runs as the project's Custom Code Service Agent by default, and that the default platform service agent ([email protected]) has access to BigQuery and Cloud Storage. Every job then inherits the union of everything any job needed. Equivalents on AWS are one SageMaker execution role shared across all notebooks and jobs, and on Azure one managed identity with Storage Blob Data Contributor across every container.

Fix it: give each workload its own custom service account (Google allows up to 20 per region per service in a project) or execution role, scoped to the specific bucket, table or prefix it needs. Google's documentation makes a further point worth acting on: changing service agent roles does not change what a prediction container can access; only a custom service account does. Note the documented exception that batch inference still uses the platform service agent for BigQuery and Cloud Storage. These are non-human identities and belong in the same inventory, ownership and review process as every other service account; see the Top 10 Service Account Mistakes and the Top 10 GCP IAM Mistakes.

5. Over-privileged human and app roles

The misconfiguration: applications are granted bedrock:*, the Azure Cognitive Services Contributor role or a project-wide Vertex AI administrator role because the narrower role "did not work". Management rights let a compromised app create new deployments, change content filters, disable logging or attach new data sources, which turns a data-plane compromise into a control-plane one.

Fix it: separate data-plane rights (invoke a named model or deployment) from control-plane rights (create, configure, delete). On AWS, scope bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream (the permissions the Converse APIs also rely on) to specific foundation-model or inference-profile ARNs and keep PutModelInvocationLoggingConfiguration, guardrail and agent management actions for a platform role. In Azure, give apps a data-plane user role on the single resource, not Contributor. Review AI roles with the rest of cloud entitlements; the Top 10 AWS IAM Mistakes covers the general patterns.

6. Guardrails optional per request

The misconfiguration: a guardrail exists, but nothing forces callers to use it. AWS documents that Bedrock Guardrails are applied by specifying a guardrail ID and version on the inference call, or by calling ApplyGuardrail. A developer who omits the parameter, or a stolen credential, gets the raw model.

Fix it: enforce with the IAM condition key bedrock:GuardrailIdentifier, which AWS supports on Converse, ConverseStream, InvokeModel and InvokeModelWithResponseStream. The documented pattern is an Allow with the condition, an explicit Deny with StringNotEquals (or ArnNotLike for any numeric version), and an Allow for bedrock:ApplyGuardrail. Know the caveats AWS lists: roles with this condition should not also be given RetrieveAndGenerate, InvokeAgent or InvokeInlineAgent, which make internal model calls that may fail, and guardrail input tags let a caller exempt parts of the prompt from evaluation (the response is still checked). In Azure, attach a content filter configuration to every deployment and treat changes to it as a privileged change. Guardrails are a filter, not an authorisation control; they reduce harmful output but do not stop a valid credential from reading data the model can reach.

7. Notebooks with internet and root

The misconfiguration: AWS documents that SageMaker notebook instances have direct internet access and root access by default. A notebook is where data scientists hold production data extracts, credentials and model artefacts, so a default notebook is an internet-connected host with an administrator user and a broad execution role. AWS also warns that with a VPC configured, overly permissive inbound security group rules let users with VPC access reach Jupyter without authenticating.

Fix it: create notebooks with a subnet and DirectInternetAccess set to Disabled, reaching services through interface endpoints or a controlled NAT path; set RootAccess to Disabled where users do not need to install system packages; and restrict sagemaker:CreatePresignedNotebookInstanceUrl to named notebook ARNs, because that permission is what grants entry to the notebook. Apply the same thinking to Vertex Workbench and Azure Machine Learning compute instances (no public IP, private endpoints). Self-hosted compute frameworks have the same problem at larger scale; see the Ray and AI Compute Cluster Security Guide.

8. No data exfiltration perimeter

The misconfiguration: training data, models and inference results can be copied out to any project or bucket an identity can write to. Identity controls alone do not stop an insider or a stolen token from moving data to an external project.

Fix it: on Google Cloud, place AI projects in a VPC Service Controls perimeter. Google states the perimeter protects training data, models, online and batch inference and Gemini models, and blocks callers outside it unless allowed by an access level. The documented ordering trap is important: endpoints must be created, and agents deployed, after the project joins the perimeter, or they may fail or remain outside its protection. Plan for the documented limitations (pipeline components cannot download from PyPI, so use Artifact Registry; Model Garden one-click public deployments are not supported; request and response logging is not available). On AWS, combine VPC endpoint policies with resource policies and service control policies; on Azure, private endpoints plus disabled public access give the network half of the same control.

9. Unreviewed data handling settings

The misconfiguration: nobody checks what the provider does with prompts and completions by default, so the privacy assessment and the actual configuration diverge. Microsoft documents that Azure OpenAI abuse monitoring may store prompts and completions for human review when content is flagged, in the Azure geography of the resource (with reviewers in the EEA for EEA deployments), and that approved customers can apply for modified abuse monitoring; when storage is off, the resource's capabilities show ContentLogging with value false. Microsoft also states that prompts and completions are not used to train the base models.

Fix it: for each deployment, record the region and geography, whether abuse monitoring storage applies, the logging you added in mistake 3, retention for both, and who can read them. Check that cross-region or global deployment types match your residency commitments before choosing them. Feed this into the data protection impact assessment rather than writing it from marketing pages. See the Azure OpenAI and Azure AI Foundry Security Guide.

10. Unmanaged model access, quotas and inventory

The misconfiguration: every available model is enabled in every account, there are no budgets or quota alerts, and nobody can list which AI resources, deployments, agents and keys exist. Unused but enabled capacity is what LLMjacking monetises, and missing inventory means misconfigurations 1 to 9 are fixed only where someone remembers to look.

Fix it: allow-list approved models by account or subscription through policy (for example, service control policies that deny invocation of model ARNs outside the approved list), set provisioned quotas and cost anomaly alerts per AI account, and keep an inventory of AI resources tagged with owner and data classification. Run posture checks for mistakes 1 to 8 continuously rather than at launch only. See the AI Platforms Guide and the Top 10 Shadow AI Risks for the unapproved side of the estate.

Detection and measurement

A configuration list is only useful if drift is caught. Track these signals and measures:

Signal or metric	Source	Target
AI accounts with key auth enabled	Azure Policy compliance for the disable local auth definition	Zero outside documented exceptions
AI resources reachable from all networks	Resource network configuration, CSPM	Zero in production
Accounts and Regions with invocation logging on	`GetModelInvocationLoggingConfiguration` per Region	100% of Regions where models are enabled
Invocations without a guardrail	Invocation logs, IAM access denied events from the guardrail deny	Trend to zero; investigate every deny
Workloads on default service identities	Job and endpoint configuration	Zero for production jobs
Model spend against baseline	Cost anomaly alerts per AI account	Every anomaly triaged within one business day

Also alert on control-plane changes: logging configuration deleted, content filter or guardrail modified, network rule set to allow all, and new model access granted. In ATT&CK terms the abuse cases are T1078.004 Cloud Accounts for the credential, T1496.004 Cloud Service Hijacking for LLMjacking and T1530 Data from Cloud Storage for training data theft; MITRE ATLAS lists AI Model Inference API Access (AML.T0040) and Exfiltration via AI Inference API (AML.T0024).

Mapping to OWASP

The OWASP Top 10 for LLM Applications 2025 is application focused, so platform misconfigurations map to it only where they widen an application risk. The NIST SP 800-53 Rev. 5 controls are the more direct fit.

Misconfiguration	OWASP LLM Top 10 2025	NIST SP 800-53 Rev. 5
1. Key auth on	LLM10 Unbounded Consumption	IA-2, AC-2
2. Public network	LLM10 Unbounded Consumption	SC-7
3. No invocation logging	(supports investigation of all)	AU-2, AU-12
4. Default service identities	LLM06 Excessive Agency	AC-6
5. Over-privileged roles	LLM06 Excessive Agency	AC-6, AC-6(5)
6. Optional guardrails	LLM01 Prompt Injection, LLM05 Improper Output Handling	CM-6
7. Open notebooks	LLM03 Supply Chain	CM-7, SC-7
8. No perimeter	LLM02 Sensitive Information Disclosure	SC-7
9. Data handling	LLM02 Sensitive Information Disclosure	SC-28
10. Unmanaged access and quotas	LLM10 Unbounded Consumption	CM-6, CM-7

In NIST CSF 2.0 the fixes sit mainly under PR.PS-01 (configuration management), PR.AA-05 (access permissions managed and reviewed) and DE.CM-09 (monitoring of runtime environments).

Where to start

Inventory first. List every AI account, resource, deployment, notebook and identity with an owner (mistake 10). Policy cannot cover what you cannot see.
Close the credential and network paths. Disable key authentication and public network access in a pilot subscription or account, confirm callers still work through managed identities and private endpoints, then enforce by policy (mistakes 1 and 2). Roll back by re-enabling per resource, never by removing the policy estate-wide.
Turn on evidence. Enable invocation logging in every Region where models are enabled, with KMS and restricted access (mistake 3).
Shrink identities. Move production jobs off default service identities and split data-plane from control-plane roles (mistakes 4 and 5).
Enforce the guardrails and perimeters. Add guardrail enforcement in audit first (watch for access denied events), then deny; build the exfiltration perimeter before new endpoints and agents are created (mistakes 6 to 8).
Write down data handling. Record retention, review and residency per deployment and reconcile with the privacy assessment (mistake 9).