Building a Governed Model Substrate with Amazon Bedrock for Enterprise AI Agents

DXC Technology replaced a fragmented model‑access layer with a single, governed substrate built on Amazon Bedrock. The change consolidates Anthropic Claude, Amazon Nova, Meta Llama, and open‑weight families behind uniform guardrails and VPC‑only traffic, giving platform teams a predictable, secure foundation for AI agents that act on critical systems.

Why a Governed Model Substrate Matters

AI agents that can modify production environments need more than a capable model; they need infrastructure that limits authority to the task at hand. Bedrock’s built‑in guardrails provide content filtering, PII redaction, and denied‑topic policies across every model, removing the need for separate, ad‑hoc filters. By keeping inference traffic inside the customer’s Amazon VPC via AWS PrivateLink, data never traverses the public internet, satisfying regulatory expectations for banks, hospitals, and government agencies.

Key Architectural Elements

The DXC OASIS stack separates model access from orchestration:

• Ingress: Amazon Route 53 and an Application Load Balancer expose the service inside the VPC.
• Runtime: Agent containers run on Amazon EKS in private subnets.
• Support services: Knowledge bases, AWS Secrets Manager, Amazon EventBridge, and Amazon S3 provide context and storage for agents.
• Model calls: Each request leaves the subnet through a VPC interface endpoint and AWS PrivateLink to reach Bedrock, ensuring traffic never leaves the AWS perimeter.
• Identity: AWS IAM governs which agents can invoke which models, while AWS KMS protects any encrypted data used in the flow.

Bedrock’s serverless scaling eliminates the need for self‑managed GPU clusters, removing a common failure point and reducing operational overhead.

Operational and Security Implications

From an operations perspective, the substrate offers a single API surface for all foundation models, simplifying monitoring, logging, and cost tracking. The uniform guardrails mean that policy changes propagate automatically to every model, reducing the risk of configuration drift.

Security teams gain a clear boundary: data residency is guaranteed within the AWS data boundary, and prompts or completions are not shared with third‑party providers nor used to retrain models. This aligns with the strict data‑handling expectations of regulated tenants. The reliance on AWS PrivateLink and VPC‑scoped endpoints also limits exposure to internet‑facing attacks.

Because the substrate is managed by AWS, DXC can focus its own “harness” on higher‑level concerns—workflow orchestration, escalation logic, human‑in‑the‑loop approvals, and audit trails—without re‑implementing low‑level model governance.

Related CloudNinjas coverage: AWS.

What This Means For Practitioners

Adopting a Bedrock‑based substrate shifts the engineering effort from building custom model gateways to configuring Bedrock guardrails, PrivateLink endpoints, and IAM policies. Teams should evaluate:

1. Whether existing workloads can be migrated to the Bedrock API without code changes.
2. How guardrail policies map to internal compliance requirements.
3. The impact of serverless scaling on cost and latency expectations.
4. Monitoring strategies for the unified API endpoint and audit logging of agent actions.

By treating Bedrock as the foundational model layer, organizations can achieve resilience, flexibility, and regulatory sovereignty while keeping the operational focus on the orchestration and assurance logic that truly differentiates their AI agents.