Cloud attacks have a new entry point. It's your running applications.

That’s why a new category is emerging: Cloud Application Detection and Response (CADR).

This guide breaks down what CADR is, why runtime is the only place real attacks can be detected, and how security teams are protecting applications, cloud infrastructure, and AI systems in production.

If you’re responsible for securing modern cloud workloads, this is a concept you’ll want to understand.

I wrote a while back about how MCP turns your internal platform into something an AI can act on, not just answer questions about. The follow-up question I kept getting was the practical one: fine, but how much do you actually let it do? This issue is the answer: a straightforward way to draw that line before the assistant does something you can't walk back.

Cheers,

Shreyans Singh

Editor-in-Chief

A simple model for deciding which platform actions an AI can run on its own, and which it shouldn't.

Workshop: Building AI-Native Platform Engineering Systems Saturday, May 30 · Online · live and hands-on (5 hours)

If the guardrails question in this issue is live for your team, the workshop is where it gets the full treatment. It's a hands-on cohort from Packt, in collaboration with FAUN.dev(), on evolving cloud-native platforms into AI-native ones: internal developer portals, golden paths, telemetry, and a dedicated session on policy-as-code, governance, and guardrails (exactly what's below).

It's built for platform engineers, SREs, architects, and tech leads already running cloud-native platforms who want to add AI deliberately, without giving up control. Speakers: Asanka Abeysinghe, Dr. Gautham Pallapa, Mark Peter, and Thiago Shimada Ramos. Every attendee also gets a free Platform Engineering for Architects e-book.

Use code SAVE50 for 50% off

Once you wire an AI assistant into your platform through MCP, it stops being a chat window. It can deploy, scale, roll things back, actually do the work. Which is great, right up until you notice nobody decided what it's allowed to do on its own. On most teams that call never gets made deliberately; it just happens, one engineer and one service at a time.

MCP is good at the wiring. It exposes your operations as tools the assistant can call. What it doesn't hand you is the judgment about which of those tools should sit one approval away and which shouldn't. That part you build yourself.

The model that works is simpler than it sounds. Take any action the assistant could perform and ask two things: if it goes wrong, can you undo it, and how far does the damage spread. That gives you three tiers.

Low-risk actions are reversible and contained: querying logs, reading metrics. Let the assistant just do those. Making someone approve a log query is the kind of friction that teaches people to stop using the tool.

Medium-risk actions are reversible but have real blast radius. Scaling a service is the obvious one. You can scale it back, but in the meantime you've moved cost and capacity for everything downstream. These should draft a plan and route to an approver.

High-risk actions are the ones you can't take back: deleting a database is the standard example. Those stay blocked by default, and the way through is a formal approval path, not a quick thumbs-up in a chat thread.

The tiers themselves aren't really the interesting part, though. The interesting part is deciding the line once, as policy, for the whole org. Skip that and every team draws its own boundary: one ships with approvals, the next one skips them, and you've rebuilt the exact inconsistency you adopted a platform to kill.

The other thing worth saying: this only holds if the safe path is also the easy path. If approval is slow and annoying, people find ways around it, and your guardrails quietly turn into a cage. So auto-execute the genuinely safe stuff generously. That's what makes the gated stuff feel worth the wait. And log everything, every tier, no exceptions.

Decide the tiers before you connect the assistant. Doing it afterward usually means doing it in response to something you wish hadn't happened.

Move from raw MCP tools to composable skills, apply spec-driven development to constrain agent behavior, and design agentic loops that recover when they get stuck. Hands-on with OpenClaw, NetClaw, and Containerlab.

Use Code EARLY40 to get 40% Off