TL;DR: "Govern your AI" is easy advice and an unhelpfully vague instruction. In a C1 Academy video, C1.ai VP of Product Erik Huckle breaks governed AI into its actual components, the building blocks an organization needs before AI adoption and governance can happen together rather than in sequence.
- It starts where identity always starts: sign-in, "that front door," and authorization, "you have the who, but then what do they have access to?"
- Secrets come next: managed centrally and rotated, then injected through an egress proxy "without a human or agent even seeing them."
- Then the gateways: an MCP gateway governing how agents reach tools, and an AI gateway controlling the cost and performance of the models at the perimeter.
- The architecture choice that follows: assembled from separate vendors, this is "a very fragmented experience"; the alternative is one platform where the pieces already know each other.
- The goal, in Huckle's words: "having the governed path be the easy path."
Most AI governance advice stays at the altitude of principles: know your AI, control your AI, monitor your AI. Fine, but what do you actually stand up? The second video in C1 Academy's Building the Agentic Enterprise series answers at the component level, with Erik Huckle, VP of Product at C1.ai, walking through the concrete building blocks of AI you can adopt with governance built in rather than retrofitted.
Why does governed AI start with sign-in and authorization?#
Because nothing downstream works without knowing who is acting. Huckle starts with sign-in: "This is that front door. Who is coming in the front door, and where they're going throughout your organization." Then authorization: "you have the who, but then what do they have access to?" Whether the person is a senior leader or sits in sales or marketing, the answer should come from rich context, "driven by policy or different attributes at the administrative level," rather than from whatever was hardcoded at build time.
The reason to name these first is that the AI builder era skips them by default. An app assembled by a marketing team has no login screen unless something supplies one, and no concept of who should see what unless authorization is layered in from outside. Sign-in and authorization are what turn a clever local prototype into something that can safely touch company systems, which is why they anchor the C1.ai platform.
Where do secrets fit in the stack?#
Every useful app or agent eventually needs credentials to reach another system, and Huckle's framing makes the stakes plain: "Think about this as a big key." The failure mode is handing that key around: "you don't want to give your engineers or your sales team or your marketing team those API keys that can get lost throughout the organization. You want to be able to manage those in a central place, rotate those, and make sure those are safe and secure."
Central storage and rotation is half the block. The other half is delivery, which is where the egress proxy comes in: taking those secrets and injecting them where they need to go, so the credential reaches the destination system "without a human or agent even seeing them." A credential nobody holds is a credential nobody can leak, paste into a prompt, or carry out the door. It's the same design argument we made in the credential vending launch, here as one block in a larger structure.
What do the gateways govern?#
The last blocks sit in the path of the AI's two outward connections. The MCP gateway handles the tool side, the MCP servers, APIs, and cross-app access an agent or application draws on, and Huckle's point is that this surface deserves no special exemption: it "needs to be managed and governed just like any sort of application within the rest of your organization."
The LLM gateway handles the model side. In his description, it's "that layer where organizations control cost and performance of the models, managing different types of API keys at the perimeter," the infrastructure base that keeps costs from overrunning while still delivering the model value teams need. Together the two gateways are the difference between AI connections you configured once and AI connections something actively governs.
Do the blocks have to live in one platform?#
They can be assembled from separate products, and Huckle names what that costs: "you can have a very fragmented experience of different products in different places and then try to bring it all together." These components reference each other constantly. Authorization needs identity context, secrets injection needs to know which agent is asking, gateway policy needs to know who the agent acts for, and every seam between vendors is integration work that turns incidents into multi-console investigations. C1.ai's strategy is to bring it all into one platform, where the identity established at the front door flows through authorization, secrets, and both gateways without translation.
The closing line of the video doubles as the thesis of this whole series: the point of the blocks is "having the governed path be the easy path."
Watch the full breakdown on C1 Academy, then see the blocks working together.
