Use these 6 guardrails to deploy AI agents to production, giving them write access in stages: read-only first, allow and deny lists, approval for changes, blast-radius limits, tested rollback and an audit trail.
Short moments from the session. Click one to play it.
Webinar 01 asked how an AI agent earns write access to production, and which guardrails make that safe. Arnab Chatterjee, Senior Vice President at Nomura, argued that access has to be earned through evidence and controls, because capability and authority are two different things. Rakesh Rajendran moderated and compared it to the trust teams once had to build in cloud and Kubernetes.
Shiv Pratap Singh pointed to guardrails teams already use: GitOps, where the system raises a pull request and a human merges it, and benchmarks that measure an agent before it is trusted. The panel worked through six guardrails, took audience questions on accountability and approval fatigue, and closed on one idea: let the agent earn autonomy one proven action at a time.
Read-only diagnostics. Arnab said an agent should first tell you what needs to be done, using a separate identity that can only inspect pods, deployments, events and logs. That limit must be enforced by Kubernetes RBAC and platform security controls, not by a sentence in the system prompt. Trust then grows as you measure its diagnostic accuracy.
Both, starting with the allow list. Arnab said a deny list only covers what you thought of preventing, while an allow list states what the agent is authorized to do, which matters because agents meet situations nobody anticipated. Dangerous operations, such as deleting a namespace, should be rejected outright, even in non-production.
Make every approval readable at a glance. Arnab said a wall of JSON at 3 a.m. is how approval fatigue starts. A good request shows what is wrong, what the agent proposes to change, the evidence, the blast radius and the rollback plan, together on one approval card.
Set the limits in the platform, not the prompt. Arnab said an engineer might approve scaling a service, but that does not mean the agent may take it from 3 replicas to 500. Limit the blast radius by service, namespace and cluster, and by how many actions an agent can run in a given period.
Only once the rollback has been tested. Arnab said very few organizations have consistently proved their rollback works, and a backup is not the same as a proven rollback. The platform should reverse a failed change without asking the agent to invent another fix, and anything that touches data stays under human control.
The person who deployed the agent. Arnab said an AI agent will never be accountable, so ownership stays with the team that runs it. That is why the last guardrail is an audit trail that lets you replay and reconstruct every decision the agent made.
The capability and authority are completely two different things.
Never automate a change before you have proved a recovery path.
56:21
Teams already know where cloud money leaks. The gap is acting on it safely across multi-cloud, hybrid and regulated estates.
56 min · recorded 29 Oct 2026
New sessions are announced on LinkedIn. Recordings and clips go up on the NudgeBee YouTube channel.