How to Build an Internal AI Platform for Enterprise AI Governance
A practical guide to enterprise AI governance and internal platform design, with a clear operating model and an AWS implementation reference.
The Problem: Agent Sprawl
The pattern is familiar. One team stands up a model integration, then a second does the same thing slightly differently, then a third. Within months:
- Teams independently build the same capability — document summarizers, internal data lookups, workflow automations — with no reuse
- No one has a complete view of which models are in production, at what cost, or with what access to sensitive systems
- Security and compliance teams can't enforce data handling policies because AI activity is invisible to their existing tooling
- There's no audit trail of what agents did, what data they accessed, or who authorized it
This is agent sprawl. It's the same fragmentation that played out with cloud infrastructure and microservices. The answer isn't to ban teams from building — it's to build a platform that makes the right way the easy way.
An AI control plane is the governance layer that does this. It defines which models, tools, data sources, identities, and workflows are allowed, while the runtime handles execution. Most enterprises don't need more AI experiments — they need a way to let teams build safely without losing visibility.
Governance is a capability, not a tollgate. The platform wins when teams choose it because it's faster than going around it.
What the Platform Must Control Centrally
Some controls belong to the platform because getting them wrong affects the whole organization. Three areas are non-negotiable:
Model access. Maintain an approved catalog of models vetted for data handling terms, licensing, and compliance posture. Use tiered access — baseline models available to all teams, higher-capability or higher-cost models requiring explicit approval. Add per-team quotas to prevent runaway spend. The goal: a clear answer to "can I use this model with customer data?" without a legal review every time.
Tool and data access. The risk profile of an agent is determined by what it can call and what it can reach. Central ownership means: a catalog of approved shared tools with clear ownership; access controls per team or agent type; human-in-the-loop checkpoints for sensitive operations — approval gates enforced at runtime, not just in policy; and data controls that enforce classification boundaries (PII, regulated content, financial records). Policy enforced at runtime, independent of what the agent was prompted to do.
Identity and auditability. Every agent action should be attributable. Agents operate under defined roles with minimal permissions. Human callers authenticate through existing identity infrastructure — no separate AI login. Every tool invocation is logged — who invoked what, with what inputs,
what was returned — and flows to centralized security tooling, not a per-team silo.
what was returned — and flows to centralized security tooling, not a per-team silo.
The Discovery Layer: Agent Registry
A registry lets teams find approved agents and tools before they build something new. Without one, the platform team becomes a human search engine and every request becomes a duplicate implementation.
The registry is the organization's system of record for approved agents, tools, and shared capabilities: what it does, who owns it, what data it can access, what runtime it uses, and whether it's approved for production. It makes three things easier — discovery, approval, and accountability — and gives teams a path to find what's allowed before building around it.
Ownership and Operating Process
Controls without process are aspirational. Two things are non-negotiable:
Clear ownership. Every agent in production needs a named team and responsible engineer. When something goes wrong, there's no ambiguity about who investigates.
An onboarding checklist. Before any agent goes live: approved model, scoped permissions, logging enabled, owner identified. Not a gate — a five-minute confirmation.
Three supporting processes are worth building early: a recertification cycle (annual re-approval; no response in 30 days = agent suspended), an exception process (a documented path for legitimate deviations — without one, exceptions happen invisibly), and an incident process (a defined path from detection to remediation — this is the real test of whether your audit logging works).
The Operating Model: Control Plane, Hosted Runtime, and Team Logic
The most useful framing separates three layers:
Control plane — defines what is allowed, what exists, and who can access what. Owns: model catalog, policy enforcement, credential management, audit logging, agent registry, provisioning, quotas. Does not run agent logic — governs it.
Hosted runtime — the standard production environment. Managed by the platform team. Handles compute, scaling, and runtime security. Default for all production agents.
Team-owned logic — agent behavior, prompts, workflow orchestration, domain tools. Teams own this completely and iterate freely. The platform enforces at the boundary where agents call shared tools or access shared data — not at the logic layer.
The default is centralized runtime with federated implementation — not decentralized operations by default.
Teams can own their agent implementation. In some cases — specialized runtime dependencies, strict data residency, or strong operational maturity — they may own their deployment environment too. But this is an exception, not the starting point. The platform should enforce the same governance boundary regardless of where the agent runs.
This is an important distinction. "Teams own their agent logic" does not mean "every team runs its own mini-platform." It means teams control what their agents do — not the infrastructure they run on.
Why the Separation Matters
Without this separation, two failure modes are common:
- Platform team as bottleneck: They review every deployment, approve every new tool, and become the slowdown they were trying to eliminate.
- Governance theater: Teams run their own infrastructure, the platform publishes policies no one enforces, and the "platform" is just a document.
The control plane / hosted runtime model avoids both. The platform team makes governance decisions once and gets out of the way on implementation. Teams move fast within a runtime that already has the right controls built in.
What Teams Should Own
The corollary to strong central controls is genuine freedom at the logic layer. A platform that governs everything and prescribes every implementation detail isn't a platform — it's a bottleneck with extra steps.
Teams building AI workflows should own:
- Agent behavior — prompts, reasoning steps, output formatting
- Workflow orchestration — how tasks are sequenced, branched, and retried
- Domain-specific tools — tools they've built that only their team uses, maintained by their engineers
- Framework choice — LangGraph, Strands, custom orchestration — whatever fits their stack
- Iteration pace — no approval required to change agent logic, only to change what tools the agent can access or what data it can reach
The platform enforces at the boundary — the point where an agent calls a shared tool, accesses a shared resource, or interacts with infrastructure outside its own scope. That boundary is where team freedom meets organizational governance.
Centralize vs. Federate: A Practical View
The right question isn't "centralize or federate?" — it's "centralize which controls, and federate which implementations?" The answer differs by layer.
Centralize when the blast radius of a mistake affects more than one team, when compliance requires a unified audit trail, or when shared infrastructure benefits from a single implementation.
Federate when a team has clear ownership, domain expertise, and operational maturity — and when the risk is scoped to their own area.
| Layer | Default stance | Rationale |
|---|---|---|
| Model access | Centralize | Compliance, cost, and data agreements are org-wide concerns |
| Policy enforcement | Centralize | Consistency across agents is the whole point |
| Identity and credentials | Centralize for shared services | Credential sprawl is a security failure mode |
| Observability and audit | Centralize | Investigation requires a complete picture |
| Agent catalog (production) | Centralize | One source of truth prevents duplication |
| Agent runtime (production) | Centralize by default | Standard runtime reduces ops burden and enforces controls at host |
| Agent logic and workflows | Federate | Teams know their domain; platform shouldn't prescribe implementation |
| Domain-specific tools | Federate where teams have ownership | Central review for shared tools; team-owned for domain tools |
| Dev/staging environments | Federate | Speed matters; risk is lower |
A practical heuristic: if another team would need to call you to rotate a credential, fix a bug, or explain what something does — own it centrally. If a team has engineers who can build, maintain, and be accountable for it — let them own it, within the platform's governance controls.
One thing to avoid: "centralize everything first" as a blanket rule. Centralizing everything in the early stages often means centralizing the wrong things (framework choices, deployment tooling) while leaving the right things (policy, observability) under-invested. Prioritize centralizing high-blast-radius, compliance-sensitive, and shared controls. Let teams own implementations from the start.
How This Maps to AWS (Implementation Reference)
The principles above apply regardless of tooling. If you're building on AWS, here's how the layers map — treat this as an implementation example, not the thesis.
| Governance area | AWS service(s) | What it handles |
|---|---|---|
| Model access | Amazon Bedrock model access controls; per-account service quotas | Approved models per account; invocation quotas per team |
| Tool access + policy | Amazon Bedrock AgentCore Gateway; Cedar-based policy engine | Allowed tools per caller identity; enforced at runtime |
| Hosted agent runtime | Amazon Bedrock AgentCore Runtime | Managed execution environment for production agents |
| Human-in-the-loop | AgentCore Runtime checkpoints | Approval gates for sensitive operations |
| Data isolation | AgentCore Memory (namespace isolation); IAM condition keys | Per-team memory partitioning; scoped data access |
| Credential management | AgentCore Identity; IAM; corporate IdP | Central secret store; JWT auth for human callers |
| Agent + tool catalog | AWS Agent Registry | Searchable catalog; curator approval workflow; EventBridge integration |
| Audit + observability | AgentCore Observability; Amazon CloudWatch; Amazon EventBridge | Control plane logging; runtime metrics; catalog events |
On the catalog: AWS Agent Registry supports hybrid semantic + keyword search and fires EventBridge events on submission, so you can route approvals through whatever workflow tooling you already operate — no new process required. Approved tools are exposed via a native MCP endpoint, so MCP-compatible agents and AI IDEs can discover them programmatically.
On policy: Cedar policies are human-readable and version-controllable. Store them in version control, review via pull request, deploy via IaC.
On credentials: Agents reference a credential provider ARN — they never see the actual secret. For human callers, JWT auth from your existing identity provider (Okta, Azure AD, Cognito) means business users invoke agents with their standard login — no AWS account required.
Where to Start
You don't need to implement everything before your first team onboards. A sequence that has worked in practice:
1. Define your governance posture before writing agent code. Decide your approved model list, initial policy tiers, what "production-ready" means for an autonomous agent, and who owns the curator role. These decisions are hard to retrofit once teams have built around them.
2. Build a minimal end-to-end example. A simple agent calling a real tool through a real policy boundary — with allow and deny cases both tested — validates your identity flow, surfaces any IaC issues, and gives teams a working reference.
3. Automate account and environment provisioning. The provisioning queue is usually the highest-friction, highest-ROI first automation. A workflow that takes a structured request, runs your standard setup playbook, and includes an authorization checkpoint can cut weeks of wait time to minutes. Thomson Reuters took this approach as their first agent on Amazon Bedrock AgentCore, using it to automate their most repetitive provisioning workflows and reduce ticket burden for their platform team. (Full case study )
4. Stand up the catalog early. Before onboarding a third team, publish your approved tools to a searchable catalog. Even a handful of entries is enough — the goal is establishing "search before you build" as the default habit before duplication takes root.
5. Commit policy templates to version control. Once the second team onboards, define your standard policy tiers and commit them. Enforce the convention that all new policies derive from a template. An afternoon of work now prevents weeks of untangling later.
Conclusion
The right enterprise AI platform is not one where every team runs its own stack. It's one where teams can move quickly within a governed runtime — with shared controls for identity, policy, observability, and high-risk tools — while retaining ownership of their agent logic and domain workflows.
The platform's job is to make the safe path the fast path, then get out of the way on everything else.
Resources
- Fine-Grained Access Control for Multi-Tenant MCP Servers with AgentCore Gateway and Policy
- How Thomson Reuters built an Agentic Platform Engineering Hub with Amazon Bedrock AgentCore
- A governance framework for building trustworthy agentic AI (AWS Public Sector Blog)
- AWS Agent Registry Developer Guide
- Organizing Agents' Memory at Scale: Namespace Design Patterns in AgentCore Memory
- Multi-Tenant Agentic AI Prescriptive Guidance
- AgentCore Policy Documentation
- Amazon Bedrock AgentCore Gateway
- Governing AI agents at scale: Lessons from our journey at Microsoft
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article