Vendor-specific Model Endpoints vs. AI Control Plane

Prediction Guard offers a secure, self-hosted, and vendor-agnostic AI control plane with built-in governance enforcement allowing organizations to audit, observe and control AI application and agent behavior.

AWS Bedrock and Microsoft Foundry primarily focus on access to AI models via API endpoints. These model endpoints can be integrated (as the model components) within the Prediction Guard control plane, and, thus, these platforms are generally complementary rather than competitive. However, software vendors relying solely on Bedrock or Foundry in their agentic AI development: (1) lack key AI governance, supply chain and security functionality; (2) lock themselves into vendor specific platforms; and (3) limit deployment possibilities (e.g., within on-premise environments).

Note - Azure is packaging various services under Microsoft Foundry other than model endpoints. However, these are still opinionated and vendor-specific (resulting in vendor lock-in), and require the costly and complicated stitching together of fragmented APIs and various cloud services to achieve even a fraction of the required AI governance, supply chain, and security functionality (as shown below).

Evaluation Criteria	AWS Bedrock	Microsoft Foundry
Model endpoint access API endpoints allowing access to LLMs, LVMs, embeddings, etc.	✓	✓	✓
Self-hosted model deployment Deployment and management of self-hosted models on GPU or CPU.	✕	− Some functionality via Foundry Local, but reliant on integration with Azure Local.	✓ Cloud and vendor agnostic model hosting built in.
Vendor-agnostic model gateway Consolidated API integrating models from various vendors with aliasing, routing, etc.	✕ Only routes through Bedrock endpoint models, even when some come from non-AWS vendors.	✕ Only routes through Foundry endpoint models, even when some come from non-MSFT vendors.	✓
Built-in MCP proxy Securely integrate MCP servers, manage authentication, control tool access, etc.	− Some functionality, housed behind an AWS managed service that isn't portable to on-premise or other cloud environments.	− Some functionality, housed behind an MSFT managed service that isn't portable to on-premise or other cloud environments.	✓ MCP proxy that is cloud and vendor agnostic.
Single-tenant network isolation Isolation of "AI systems" for individual customers or products to limit blast radius.	✕ Would require custom tooling on top of AWS PrivateLink and VPCs.	✕ Would require custom tooling on top of Azure VNets, RBAC, etc.	✓
Flexible deployment On-premise, in any cloud VPC, hybrid, or even air-gapped.	✕	− Some functionality via Foundry Local, but reliant on integration with Azure Local.	✓
Fixed licensing cost No ballooning usage-based fees.	✕ Basically all pay-as-you-go, usage-based APIs.	✕ Basically all pay-as-you-go, usage-based APIs.	✓
Runtime Governance: Content filtering Filtering for on or off topic inputs and toxicity.	− Requires separate configuration per model endpoint and reliance on the developer to change their code for safety.	− Requires separate integration of the content safety API, and thus more cost and reliance on the developer to change their code for safety.	✓
Runtime Governance: Prompt injection blocking Blocking and logging of prompt injections.	− Requires separate configuration per model endpoint and reliance on the developer to change their code for safety.	✓ Enabled via Prompt Shields in MSFT Foundry.	✓
Runtime Governance: Grounding verification Ensuring context is present for agent responses.	✕ Would require the developer to pass generated output through separate evaluation filters.	✕ No runtime enforcement, with some development-focus "evaluators" available instead.	✓
Runtime Governance: Retrieved knowledge logging Logging and tracking of retrieved knowledge injected into AI inputs.	− Requires an extra service and custom integration with AWS CloudTrail.	− Only supports MSFT specific logging in the Foundry Portal and not generic traces.	✓
Runtime Governance: PII filtering, masking, faking Filtering, masking, and faking of personally identifiable information.	− Requires separate configuration per model endpoint and reliance on the developer to change their code for safety.	− Requires separate integration of cognitive skills, adding cost and reliance on the developer to change their code for compliance.	✓
Cost Control: Token-based limits Per API key or single-tenant AI system.	✕ Requires integration of a separate service, e.g., AWS IAM quota definitions.	✕ Requires integration of a separate service, e.g., Azure API Management.	✓
Cost Control: Governance enforced before API hits Enforced before AI inputs or agent context hits any pay-as-you-go, usage-based API.	✕ Requires using pay-as-you-go APIs to evaluate content before it goes to other pay-as-you-go APIs.	✕ Requires using pay-as-you-go APIs to evaluate content before it goes to other pay-as-you-go APIs.	✓
System topology visualization Understanding which models are connected to which MCP servers, API keys, and applications.	✕	✕	✓
AI model risk scoring Based on non-public safety and security benchmarks.	✕ Requires a separate service, Model Evaluation, and someone with data science experience to set it up.	✕ Requires integration of other frameworks or utilities like PyRIT, which are open source and tainted/available to model builders.	✓
AI Bill of Materials (AIBOM) export Export in compatible formats like CycloneDX.	✕	✕	✓
One-click governance alignment Alignment of governance enforcement, across all applications using an AI system, to standards like NIST 600-1 or OWASP Top 10 for GenAI.	✕	✕	✓
SIEM/SOAR integration Integration of AI security events into popular SIEM/SOAR systems (Datadog, Splunk, etc.)	− Requires yet another integration, e.g., Kinesis Data Firehose.	− Requires yet another integration to Azure Monitor and more complication, resulting in a vendor-specific implementation.	✓
System-wide audit log Recording any changes to AI systems configuration (e.g., model or tool updates) and governance configuration.	− Requires further complication and integration of yet more AWS-specific services, not included in Bedrock out-of-the-box.	− Requires further complication and integration of yet more services like MSFT Purview and Azure Activity Logs.	✓
Built-in tools: Secure code-execution sandboxes Sandboxes for agent code execution.	✓ Not portable to non-AWS environments.	✓ Not portable to non-Azure environments.	✓ Portable to any environment.
Built-in tools: Web search MCP server Native web search capability for agents.	✓ Relies entirely on a web index operated internally by Amazon, leveraging technologies from Alexa+ and Amazon Q Business.	✓ Limited to Bing.	✓
Built-in tools: Document structure parsing Parsing and standardization of document structure.	✓ Incurs an extra usage charge.	✓ Incurs an extra usage charge.	✓ Built into the fixed-price licensing, no extra charge.
Agent App Layer: No-code agent building Building agents via natural language, without a line of code.	✕	✕ Would require Copilot Studio licenses, and then work would be locked into Copilot Studio.	✓
Agent App Layer: Agent workspaces Workspaces to isolate agents per team, department, product, etc.	✕	✕	✓
Agent App Layer: Web app embedding Embedding of agents in web apps via embed code.	✕	✕ Would require Copilot Studio.	✓
Agent App Layer: Public sharing links Public sharing links for agent interaction.	✕	✕ Would require Copilot Studio.	✓
Agent App Layer: Knowledge base curation Curation with adjustments for embedding model, chunk size, retrieval mechanisms, etc.	✓	− Requires yet another service, Azure AI Search.	✓
Agent App Layer: Usage and analytics tracking Tracking of usage messages and agent interaction analytics.	✓ Vendor specific to the AWS console, not portable to any environment.	✓ Vendor specific to the Foundry console, not portable to any environment.	✓ Tracks in any on-premise or cloud environment.
Agent App Layer: Single-tenant deployment Deployment of single-tenant agent building/interaction platform on-prem, cloud, or hybrid.	✕	✕	✓
OAuth 2.0 for MCP authentication OAuth 2.0 support for MCP server authentication.	✓	✕ Requires yet another service, Azure API Center registry.	✓
MCP tool listing limitation Limitation of MCP tool listing and access per AI system to limit blast radius.	✓ Enabled at the developer, not the control plane, level.	✓ Enabled at the developer, not the control plane, level.	✓ Developer doesn't have to make any change.
Developer Experience: Zero code changes No code changes required in a codebase for governance to be enforced (no special SDKs).	✕ Requires developers to integrate multiple APIs for model access, monitoring, and governance.	✕ Requires developers to integrate multiple APIs like content safety.	✓
Developer Experience: Single API base URL Integration via a single API base URL without relying on multiple stitched-together services.	✕	✕	✓

✓ Covered

− Partial / unclear

✕ Not covered

AWS Bedrock, Microsoft Foundry and Prediction Guard: Vendor-specific Model Endpoints vs. AI Control Plan

Detailed feature comparison between Prediction Guard, AWS Bedrock, and Microsoft Foundry

Architecture for utilizing Bedrock models or Foundry models within Prediction Guard