An AI agent doesn’t just answer a question anymore. Ask one to pull a customer record and draft a follow up email, and somewhere between the request and the sent message, that agent has to read a database, decide what belongs in the email, and hand it to a delivery system. Each of those is an action, not a sentence, and each one gets checked before it happens. Walking through what actually happens in that gap, between a request and the result, shows how the pieces work together better than describing them separately ever does.
The request arrives
Someone types a request. Before that text ever reaches the underlying model, it passes through a check on the content itself. Is this a normal request, or does it look like an attempt to manipulate the model into ignoring its instructions? Prompt injection attempts, jailbreak patterns, and other manipulation get screened out at this stage. This is the guardrail layer, and its job here is narrow on purpose: look at the words going in, not at what the agent is about to do with them.
Most requests pass this check instantly and without friction, because most requests are exactly what they look like. The point of this layer isn’t to slow down normal use. It’s to catch the request that isn’t normal before it ever gets a chance to influence what the model does next.
The model decides what to do
Once the request clears that first check, the model figures out what action it implies. Pull this record. Draft a message. Attach a file. This is where a lot of security thinking stops, treating the model’s output as the finish line. It isn’t. Deciding to take an action and being allowed to take it are two different things, and the second one belongs to a different layer entirely.
The action gets evaluated
This is where agent constraints take over, and where the actual boundaries live. Before the pull request against the customer database executes, the system checks whether this agent, in this context, is allowed to touch this data at all. It validates the specific parameters of the request, not just whether database access is permitted in general, but whether this particular record, this particular field, this particular action is inside the lines that were drawn for it.
That check happens at the point of execution, not somewhere upstream in a policy document. A rule that only exists in a prompt or a training instruction depends on the model choosing to follow it. A rule enforced at execution applies whether the model remembers it, ignores it, or was never told about it in the first place, because the check happens outside the model, on the action itself, every time.
Risk decides who reviews it
Not every action carries the same weight, and agent constraints don’t treat them like they do. Pulling a customer’s publicly listed contact name is a low stakes action that proceeds immediately. Attaching a document that includes financial details, or sending a message to someone outside a pre approved domain, crosses into higher risk territory, and that’s where a human reviewer gets pulled in before the action completes rather than after.
This is the part that makes the difference between a security layer people work around and one they don’t. A system that escalates everything creates so much review queue that people stop reading it. A system that escalates nothing removes the one checkpoint that catches the case a policy document didn’t anticipate. Matching the review requirement to the actual risk in front of it is what keeps both of those failure modes from happening at once.
The output gets checked again
Say the action clears every constraint and the agent drafts its email. Before that draft goes anywhere, guardrails check it one more time, this time on the way out instead of the way in. Does the response contain sensitive data that shouldn’t be there. Does it contain a claim that isn’t actually supported by the source record it was pulled from. Is there bias or inappropriate content in how it’s phrased. This output check catches something the earlier layers were never built to catch, because a perfectly authorized action can still produce a response with a problem inside it.
Why the request needs both layers, not one
Guardrails alone would have let the entire scenario play out based only on whether the initial request looked suspicious, with no check on what the resulting action actually touched. Agent constraints alone would have controlled data access correctly but had nothing to say about whether the eventual email contained something it shouldn’t. Neither layer, running by itself, covers the whole sequence between a request and a result. Running together, each one covers exactly the part of that sequence the other wasn’t built for.
That’s the part that’s easy to miss when these two get discussed as competing approaches. They aren’t solving the same problem from different angles. They’re solving two different problems that happen to sit next to each other in the same request, one about the content moving through the system and one about the actions that content sets in motion.
It’s worth being specific about why swapping the order wouldn’t work either. Checking the action before checking the request means a manipulated prompt could still shape what the model decides to attempt, even if the attempt itself later gets blocked. Checking the request twice and skipping the action check means a perfectly normal seeming prompt could still trigger an action that reaches further than it should. The sequence matters as much as having both checks in the first place, because each one is positioned to catch what came immediately before it.
This layered check is now a verified standard, not just a best practice
The action level check described above, the one that intercepts a request before it executes and decides whether it’s allowed, is no longer just a design choice individual vendors make on their own. In August 2026, the Cloud Security Alliance introduced the Autonomous Action Runtime Management specification, an open standard that defines exactly what a runtime security system has to do before an agent is allowed to act. Airia announced it had achieved conformance under that specification, joining fewer than ten platforms worldwide to do so.
What conformance actually certifies maps directly onto the action level check walked through earlier: every agent initiated action gets intercepted before it executes, evaluated against policy and session context, and resolved into one of five outcomes, allow, deny, modify, defer, or step up for human review, before it ever reaches a downstream system. Each decision produces a signed, tamper evident receipt an auditor can check independently, rather than a vendor’s word for it. That distinction, a verified outside standard instead of a self reported one, is quickly becoming what security and procurement teams expect to see before they’ll trust a runtime layer at all.
What this actually buys you
None of this has to slow down the agent doing normal work. Low risk requests still move through in the same moment they’re made. What changes is what happens at the edges, the request that looks off, the action that reaches too far, the output that shouldn’t have included what it did. Building both layers in from the start means those edge cases get caught as part of the same flow every request already runs through, instead of depending on someone noticing after the fact.
Secure what your agents actually do, not just what they say. Talk to the Airia team about enforcing both content checks and action level constraints on every request your agents handle.
Put these ideas to work.
Schedule a 30-minute walkthrough with our team.