AI Command Center discovers and monitors AI resources across AWS, Azure, and GCP, and correlates configuration data with runtime activity to identify security risks in custom-built AI agents, enterprise chatbots, and model serving deployments. Each finding traces the specific resources and policies involved, for example an agent, the gateway it uses, the knowledge base it queries, and the IAM role it assumes.
AI Platforms We Cover
This capability discovers AI building platforms across AWS, Azure, and GCP. It also correlates these platforms against supporting cloud controls, including IAM, networking, storage, encryption, and policy governance.
AWS – 5 Platforms
| Platform | What it does | Key resources monitored |
|---|---|---|
| Amazon Bedrock | Foundation model access and fine-tuning | Foundation models, custom models, guardrails |
| Bedrock Agents | Agent building with tool use and knowledge bases | Agents, action groups, knowledge bases, data sources |
| Bedrock AgentCore | Agentic platform with gateways, memory, and sandboxes | Agent runtimes, MCP gateways, gateway targets, browsers, code interpreters, evaluators, memory stores, token vaults, credential providers, Cedar policy engines |
| Amazon Q Business | Enterprise AI assistant over internal corpora | Applications, web experiences, chat controls, indexes, retrievers, data sources |
| Amazon SageMaker | ML platform for training and serving | Domains, models, endpoints, inference components, training jobs, notebooks, feature groups, HyperPod clusters, model cards, monitoring schedules |
Azure – 4 Platforms
| Platform | What it does | Key resources monitored |
|---|---|---|
| Azure AI Foundry | Agent building and model deployment | Projects, agents, deployments, connections, indexes, knowledge bases, memory stores, vector stores, evaluations, red-team assessments, fine-tuned models, RAI policies |
| Cognitive Services / Azure OpenAI | Model serving and inference | Cognitive service accounts, available models, Defender for AI settings, capability hosts |
| Azure Machine Learning | ML platform for workspaces, training, and endpoints | Workspaces, registries, online/batch/serverless endpoints, compute instances, jobs, models, data assets, feature stores |
| AI Search | Enterprise knowledge retrieval | Search services, indexes |
GCP – 4 Platforms
| Platform | What it does | Key resources monitored |
|---|---|---|
| Vertex AI | Model serving, training, and tuning | Models, endpoints, publisher models, tuning jobs, training pipelines, datasets, notebook runtimes |
| Vertex AI Agent Builder | Low-code agent building with enterprise grounding | Low-code agents, data stores |
| Vertex AI Reasoning Engine | Code-first agent platform | Reasoning engines, RAG corpora and files |
| BigQuery ML | ML inside the data warehouse | BQ models, datasets, tables, routines, connections, data policies, row access policies |
Supporting Cloud Controls
This capability correlates AI resource findings against the following supporting controls:
- AWS: IAM roles, policies, and permission boundaries; S3 bucket ACLs, policies, and encryption; EC2 instances.
- Azure: RBAC role assignments and definitions; deny assignments; Azure Policy definitions, initiatives, assignments, and compliance state; key vaults; managed identities.
- GCP: Service accounts and keys; workload identity pools; IAM policies and custom roles; deny policies; GCS buckets; Compute instances.
Security Posture Checks
This capability performs static configuration analysis against three AI surfaces: custom-built agents, enterprise chatbots, and model serving deployments. Each finding traces the dependency chain between the affected resource and the policies or roles involved. It also ranks the available remediation options.
Custom-Built Agents
A Bedrock AgentCore MCP gateway can expose agent tool access, such as a database or a ticketing system, to external callers. This capability checks the gateway’s authorizer configuration to determine whether it accepts unauthenticated requests. If no authorizer is configured, the resource policy grants broad access, and any attached Cedar policy engine is missing or running in log-only mode, the check triggers a finding.
The finding identifies which gateway targets are reachable, whether those targets store API keys or OAuth tokens, and what the gateway’s runtime identity can reach downstream. It also accounts for compensating controls, such as an external API gateway enforcing OIDC in front of the AgentCore gateway, which inventory alone cannot detect. Remediation options, ranked by strength: add a JWT authorizer, restrict the resource policy to named roles, or enforce Cedar per-tool policies.
The same check pattern applies across clouds. On GCP, the equivalent check evaluates whether a Reasoning Engine’s IAM policy grants broad invocation access and whether a deny policy exists as a compensating control. On Azure, the check evaluates whether AI Foundry endpoints use key-based authentication combined with public network access.
Enterprise Chatbots
An Amazon Q Business application can be configured to answer questions from internal sources such as SharePoint or Confluence. This capability checks the application’s identity configuration: if the web experience has no SAML or OIDC identity provider configured, and the application’s identity type isn’t set to AWS IAM Identity Center, the check flags the application. Severity increases if the indexed data sources include internal corpora such as SharePoint, Confluence, or Salesforce, and decreases if all sources are public web crawls or if topic-based retrieval rules already restrict document access by user group.
Remediation options: bind the application to AWS IAM Identity Center or an OIDC provider so each query is attributable, or constrain retrieval by user group using topic configurations as an interim step. The same check pattern applies to Azure AI Foundry agents serving an internal knowledge base without enterprise identity binding, and to GCP Agent Builder applications with enterprise data stores that lack IAM-based user attribution.
Model Serving
A guardrail attached to a Bedrock model deployment can be present in inventory without enforcing anything. This capability reads each of the guardrail’s sub-policies (content filters, sensitive information policy, topic policy, word policy, and contextual grounding policy). If every sub-policy is set to a non-blocking action, the check triggers a finding. The check distinguishes a guardrail in a deliberate monitor-only rollout, which returns a lower severity, from a guardrail with every filter inoperative and no rollout context, which returns a higher severity. It also checks whether the agent is bound to a draft guardrail version, which can indicate an in-progress configuration change rather than a permanent gap.
Remediation: set blocking actions on the applicable harm categories and add PII entity coverage for the data the model processes. On Azure, the equivalent check evaluates whether an RAI policy is bound to an AI Foundry deployment and whether its content filters are set to block. On GCP, Vertex AI safety settings are configured per request at runtime rather than as a persistent resource, so this check instead evaluates whether the deployment’s capabilities (for example, code execution combined with enterprise data grounding) warrant content controls, and reports missing runtime safety configuration as a gap in available evidence rather than a hard finding.