AI Agent Guardrails Don't Work. Safer Platforms Do.
- Abby Bangser
- 1 day ago
- 9 min read
An AI agent that behaves exactly the same way with every prompt or request isn't AI. It's an expensive if-statement. But that's what most "safe AI in production" conversations are actually asking for: a model dependable, repeatable, and reliable enough to trust with a database upgrade. Dependability was never the point of AI. Bolting it on after the fact solves for the wrong property entirely.
AI is useful because it's creative and can reason through ambiguity. Ask it the same question twice, and you might get two different, both reasonable, answers. That reasoning quality lets it work through a situation nobody wrote rules for. It's also exactly what gets dangerous the moment you point it at production infrastructure. You don't want to improvise a database upgrade. Platform teams have been managing this risk for years with human operators. Entire classes of tools like Infrastructure as Code (IaC) and Configuration as Code (CaC) were invented to bring repeatability to what had been ad hoc, one-off reasoning work.
AI agent guardrails try to fix the wrong thing
Most guardrail conversations treat the AI as the thing that needs constraining with a stricter system prompt, tighter review, and countless gates before anything ships. These controls can be useful as defence in depth, but they don't solve the underlying architectural problem. If an AI agent can directly execute arbitrary infrastructure changes, you're still relying on a fundamentally improvisational system to behave predictably at exactly the point where predictability matters most.
Gregor Hohpe puts this more sharply when, using the analogy of driving a car along a mountainous road, he describes the problem with treating platform governance as a guardrail. Yes, a guardrail may succeed by keeping you from going over the cliff, but the fact you hit it means both the rail and the car are a bit wrecked. While this is better than tragedy, it is still a failure case in its own right. What you actually want is lane assist providing continuous feedback that lets teams autocorrect before they're anywhere near the edge. A guardrail that only stops the AI after it's already tried the wrong thing might catch the mistake, but the mistake still happened, got logged, got escalated, and likely cost someone an afternoon of debugging and incident managing.
Across the platform teams we've worked with this year, from retail to hospitality, from banking to energy utilities, we're seeing the same architectural question emerge: rather than relying on the AI itself to behave predictably, how do you create an environment in which its actions are safe by default? The answers increasingly move the safety boundary away from the model and into the systems around it.
The safety layer already exists. It's called a platform.
Or, more precisely, a platform that exposes governed capabilities rather than raw infrastructure. The platform defines the operations consumers are allowed to perform and codifies how those operations are executed.
In Kratix, platform capabilities are defined as Promises: a versioned, tested, organisation-specific definition of exactly how a piece of infrastructure or other capability gets created, upgraded, and torn down. A Promise takes a request, whether it comes from a human or an AI agent, and routes it through the same codified, testable, governed execution path every time. The AI can wander in its reasoning because the road it's driving on goes only one way and is clearly signposted, making the “lane assist” feature implicit.
Promises aren't a filter that catches bad AI output after the fact; they're the only execution surface the AI is ever offered. Instead of generating infrastructure definitions from scratch, an agent interacts with safe interfaces that provide a discoverable capability, a validated schema, and a deployment workflow that already encodes the organisation's standards. It gets bounded autonomy, not supervision.
This is the same principle behind good developer self-service: don't give consumers unrestricted access to the underlying machinery; give them safe capabilities that encode the organisation's expertise. AI agents make the importance of that boundary even clearer.
Promises bundle everything required to safely run operational lifecycle actions: a consumer-facing API (a Kubernetes CRD behind the scenes) with a schema, a set of reconciliation workflows, and destination rules for managing complex organisational topologies. When someone or something requests a database, they get the same workflow every time, whether the request comes from a developer filling out a Backstage form or an AI agent that decided a database was needed.
This pattern of central governance with local autonomy keeps surfacing in our customer proof-of-value engagements. The designs keep coming back to platform orchestration, enabling a platform team to set the rules once, with every rollout versioned and checkable for drift against the baseline. Individual teams can then self-serve these managed services with the same lifecycle management platform teams have always aspired to provide, now provided to a new kind of requester.
AI proposes, the Promise disposes
In practice, this looks like AI being fed a high-level instruction such as "roll out the new version of my application," then assembling that rollout entirely from build, deploy, and validation steps that were version-controlled and tested long before any AI was in the room. The AI decides what needs doing. The Promise decides what "doing it" is allowed to mean. Reasoning can remain dynamic; execution doesn't have to be.
A recent Syntasso webinar showcased how this isn't just theoretical. Shane Dowling shared lessons from Putting AI in Front of a Platform after giving two AI agents the same task: provisioning a production PostgreSQL database for a payments team. Both used the same model and the same prompt, and both produced a working Postgres database. Only one produced something a platform team could confidently operate long-term.
One agent had worked directly against Kubernetes while the other worked through a Kratix Promise, which provided usable configurations such as consistent labels, real network policies, and lifecycle management. A generic infrastructure provider, such as a public cloud or Kubernetes cluster, can't codify the operational requirements unique to a business. Not only that, but re-running the Kubernetes-native agent can't guarantee a compliant implementation each time.
In contrast, a Kratix Promise codifies known best practices as defined by your organisation. Re-running the Promise-based experiment sends every request through the same governed workflow, so variation in the agent's reasoning doesn't become variation in how the infrastructure is configured and managed.
The pattern holds across very different organisations, from highly regulated financial services firms to fast-moving e-commerce companies. An AI agent proposes an upgrade path across a fleet of services; the platform lets it choose what needs doing while the Promise controls how it can possibly happen. One team needed the AI's proposed changes routed through the same change-approval process a human change would go through, with an audit trail, rather than a separate AI-shaped exception path. Another needed the same agent configuration validated identically whether it landed via kubectl, a Backstage form, or an MCP call from an agent. Neither problem was solved by a smarter AI. Both were solved by making sure every entry point led to the same trusted execution layer.
This is a different shape of safety than reviewing everything the AI does. Reviewing every action doesn't scale, and it defeats the point of using AI if a human still has to re-derive every step by hand. What scales is narrowing what the AI can do wrong. If the only actions available are pre-coded, versioned, already-approved workflows, the AI's dynamic thinking stays contained to the layer where you actually want it: deciding what needs doing, not how infrastructure gets touched.
This is architecture lane-assist, not a guardrail
The word "guardrail" gets used loosely and, when pushed on, often doesn't support the outcomes we are looking for. A guardrail gets bolted onto a system that wasn't designed with it in mind, and you only find out it works when something hits it. What we’re describing here was built in from the start. It's the same fix Infrastructure and Configuration as Code already applied to human reasoning, moved up the stack to cover business processes and rules too. Ad hoc improvisation is replaced with pre-tested, versioned execution, validated for your context and your company.
Platform orchestration frameworks were built this way before agentic AI was a serious conversation, because the underlying problem was never really about who's doing the reasoning. AI just increases the pace and raises the stakes. That is why Syntasso Kratix Agentic (SKA) builds on the existing Kratix orchestration foundation rather than introducing a separate execution path for AI. The governance an organisation already has for its Promises is the governance an AI agent inherits when it uses the same platform.
While it is the same foundation, we do need to keep in mind Shane's fantastic quote from his webinar: "Humans can ask Jenny. AI needs an API." Neither people nor AI have perfect information for every scenario, but humans can navigate ambiguity by knowing who to ask. AI agents don't have a Jenny to ask, so whatever isn't encoded as an explicit contract simply doesn't exist for them, and they are happy to make assumptions.
The most successful organisations today have moved past asking how to create novel solutions with AI and have moved on to governance, versioning, and trusted infrastructure workflows. The next phase is investing in how to safely point AI at what they've already built. When they have invested in their platform orchestration layer, AI simply becomes the newest, fastest thing trying to use it.
Five questions to ask before giving AI agents access to your platform
If you're considering letting AI agents operate against your infrastructure, answer these five questions before writing a single line of agent integration code:
Does every entry point resolve to the same workflow? If a human using kubectl, a developer using a portal, and an AI agent calling an MCP server can all end up executing different code paths for "the same" action, you don't have a unified layer yet.
Is the AI's output a plan, or an action? An AI that proposes a staged rollout can operate within a safer architecture if the rollout itself is made of pre-approved steps. . An AI that executes arbitrary commands isn't safer just because you reviewed the prompt carefully.
Can you answer "what changed and why" without asking the AI? If your audit trail depends on the AI having explained itself accurately, you don't have an audit trail. You have a transcript that may not stand up to scrutiny by the compliance team or regulators.
Does drift detection cover AI-initiated changes the same way it covers human ones? Config drift doesn't care who caused it. Your detection shouldn't either.
Where does the approval gate live? A step the AI is supposed to remember to pause for can get skipped. A step the workflow enforces regardless of who's asking can't be.
These aren't really AI questions. They're the questions platform engineering has always asked about self-service, governance, and lifecycle management. AI is simply a new kind of platform consumer.
AI Agent Guardrails FAQ
Q. What is a guardrail in AI?
A guardrail is a control intended to constrain an AI system's behaviour, such as system prompts, output filters, permissions, policy checks, or human review gates. These controls can reduce risk, but they don't remove the need for a safe execution layer underneath the AI. For infrastructure operations, the stronger boundary is architectural: constrain what the agent can actually execute, not just what you hope it will decide to do.
Q. Do more guardrails make AI safer in production?
Not by themselves. Guardrails can reduce risk, but they don't solve the underlying architectural problem. If an AI agent can directly execute arbitrary infrastructure changes, you're still relying on those controls to catch every bad decision. Making AI safer around production infrastructure means narrowing what it can do wrong in the first place, not just adding more controls around its reasoning.
Q. What are examples of AI guardrails?
Typical guardrails include stricter system prompts, output filters, human-in-the-loop review gates, and policy checks layered on top of a model's response. Syntasso argues that these operate on the AI itself, while a more durable fix is to constrain the platform layer the AI is allowed to act through.
Q. What's the difference between AI guardrails and safe platform orchestration?
Guardrails try to make a complex and necessarily dynamic system behave predictably by constraining its output. Safe platform orchestration, using something like a Kratix Promise, doesn't try to change how the AI reasons at all; it gives the AI a fixed, versioned, pre-approved set of actions to choose from, so execution follows the same governed workflow regardless of how the AI got there.
Q. Can AI agents operate safely without traditional guardrails?
Yes, if the platform layer they act through only exposes safe, pre-approved workflows. The AI's dynamic thinking stays contained to deciding what needs doing; it never touches how the action is actually executed, which is where the real risk sits.
Final thoughts
AI doesn't need to reason deterministically to operate safely around production infrastructure. It needs an execution environment that turns dynamic intent into governed, repeatable operations.
That's not a new requirement created by agentic AI. Good platforms have always taken what a consumer wants and translated it into an organisation-approved way of doing it. Promises existed before AI agents showed up asking to use them because developers needed the same boundary too.
AI simply raises the stakes. Humans can work around gaps in a platform, ask Jenny, interpret documentation, and exercise judgement about when something doesn't look right. Agents can operate faster and at greater scale, making those gaps much harder to tolerate.
The answer isn't to make AI less capable. Give it room to reason, guardrails as defence in depth, and a platform that determines what can actually happen.
If you're keen to learn more about why we built Syntasso Kratix Enterprise (SKE) and Syntasso Kratix Agentic (SKA) to address these challenges, check out the rest of the website or reach out to us.
Comments