You wouldn’t deploy a new hire on day one with root access to your production database, an unlimited expense card, and zero supervision.
But that’s essentially what most teams do when they ship an autonomous agent.
The agent is capable. The tools are wired up. The prompts are refined. And then it runs in the real world, on real data, with real consequences, held in place by nothing except a system prompt that can be reasoned around, forgotten across context windows, or simply overridden by a sufficiently creative request.
This is the state of agent safety today: mostly vibes.
There’s a better approach: make guardrails structural. Not instructions but architecture. Not “don’t do X” but “X is not possible here.” We’ve been building this into School for Agents, an open training platform where every skill an agent acquires includes its own safety contract. More on that at the end.
First, the ten guardrails.
1. Constrain capabilities, not intelligence
The instinct is to write better instructions. “Don’t do X.” “Always check Y first.” This is the wrong layer.
Instructions can be misinterpreted, overridden, or simply lost in a long context. Capabilities cannot be.
If an agent doesn’t need write access to a database, remove that tool entirely. If it shouldn’t send emails, don’t give it an email integration. The most reliable guardrail is a missing capability, not a reminder to use it carefully.
Start every agent deployment by asking: what is the minimum set of tools this agent needs to do its job? Then remove everything else.
2. Three tiers of human involvement
Not every action needs the same level of oversight. Define your tiers explicitly:
Tier 1: Act, then notify. The agent acts autonomously and surfaces a summary after. Low-risk, high-volume tasks. Reading, summarizing, routing.
Tier 2: Confirm before acting. The agent proposes, a human approves. Medium-risk actions: sending external communications, updating records, initiating workflows.
Tier 3: Human initiates. The agent never acts on this class of action without an explicit human trigger. High-stakes, irreversible, or regulated: financial transactions, data deletion, legal communications.
The mistake is treating everything as Tier 1 until something goes wrong. Map your action space to tiers before deployment.
3. Dry run mode is not optional
Every agent action class should have a dry-run path: the agent constructs what it would do, returns it as structured output, and waits.
{
"action": "delete_user",
"target": "user_123",
"impact": "removes all associated orders",
"confidence": 0.62
}
This is not a testing convenience. It is an operational requirement for any agent that touches external systems.
The structured output discipline has a second benefit: it forces the agent to be explicit about its intent. An agent that can articulate exactly what it’s about to do, in parseable format, is an agent you can audit, review, and catch before a mistake becomes permanent.
4. Hard limits beat soft instructions
“Be careful with customer data” is a soft instruction. It competes with everything else in the context window.
“You do not have access to the customers table” is a hard limit. It doesn’t compete with anything.
The hierarchy: infrastructure constraints > hard limits in system config > role definitions > task instructions. Soft instructions at the bottom. Hard limits as close to the infrastructure layer as possible.
This is exactly how the skill manifests in School for Agents are structured: each skill includes a hard_limits block, machine-readable rules that encode the constraint at definition time, not at runtime. An agent importing the skill can’t “forget” the limit because the limit isn’t in a prompt. It’s in the skill’s contract.
When you’re designing an agent system, every “don’t forget to…” in a prompt is a signal that something should be hardcoded instead.
5. Environments are not suggestions
Staging and production are different environments for a reason. An agent with production credentials, running in a staging workflow, is a production agent with plausible deniability.
Enforce environment separation at the credential level. Staging agents get staging API keys, staging databases, staging webhooks. They cannot reach production, not because you told them not to, but because the keys don’t work.
Same for sandboxing: if an agent can run code, that code should run in an isolated container, not on the host. The principle: the blast radius of any agent failure should be structurally bounded, not just instructed-to-be-small.
6. Logging as black box recorder
Airplanes have flight data recorders not because they prevent crashes, but because they make crashes understandable and therefore preventable.
Agent logs should work the same way. Every tool call: logged. Every decision branch: logged. Every input that arrived and output that left: logged. Immutable, timestamped, attributable.
This is not for debugging (though it helps). It’s for accountability. When an agent does something unexpected, you need to be able to reconstruct exactly what happened, what it saw, and what it chose.
If your current agent can’t answer the question “why did you do that?” with a verifiable trace, your logging is insufficient.
7. Rate limit everything
An agent that can call an API once can call it ten thousand times. The limiting factor is usually nothing except token budget and execution time.
Set explicit rate limits on every tool: calls per minute, calls per session, total spend ceiling. Treat these as hard stops, not warnings.
Rate limits do three things: they prevent runaway cost from bugs, they limit blast radius from adversarial inputs, and they force you to be intentional about what normal usage actually looks like.
If you don’t know what “normal” tool usage looks like for your agent, that’s the first thing to figure out, before deployment, not after the bill arrives.
8. Kill switches must be independent
A kill switch that relies on the agent to execute the kill switch is not a kill switch.
The termination mechanism must live outside the agent’s execution path: a separate service, a circuit breaker in the infrastructure layer, an out-of-band flag the orchestrator checks before each step. If the agent is in a bad state, it may not be capable of correctly processing a shutdown instruction.
Test the kill switch in production at least once before you need it. Kill switches that have never been fired are usually broken.
9. Validate outputs before execution
The agent returns an action. The action gets executed. This is the default flow.
The better flow: the agent returns an action, a validation layer checks it against a schema, a set of business rules, and only then executes.
Validation catches: malformed tool calls, out-of-range parameter values, actions that are technically valid but contextually wrong, and prompt injection payloads that have been laundered through the agent’s reasoning.
No validation = blind execution.
10. Separate thinking from acting
This is the most important one, and the most commonly ignored.
Most agent architectures conflate the reasoning step with the execution step. The model decides what to do and does it in the same step. This is fast. It is also dangerous.
The better pattern: the agent reasons in a scratchpad, produces a proposed action as structured output, and a separate execution layer evaluates and runs it. The reasoning can be verbose, exploratory, uncertain. The execution step is narrow, validated, logged.
This separation does something subtle but critical: it creates a seam where humans or automated validators can intervene. An agent that can be paused between thinking and acting is an agent you can govern. An agent that thinks and acts in a single step is a system where governance is theoretical.
In School for Agents, this separation is built into how skills are defined. Each skill specifies its human_in_loop_tier: the structural rule that determines whether a human must intervene between a proposed action and its execution. Not a reminder. A contract.
Building this in
These aren’t novel ideas. Most of them are standard engineering practice applied to a new context. The reason they’re not universal in agent deployments is that agents move fast. Demo to production in days. Safety infrastructure takes time to build.
School for Agents is an open training platform that bakes these guardrails directly into skill definitions. Each skill a trained agent acquires comes bundled with its permissions, hard limits, dry-run requirements, and human-in-the-loop tier. The safety contract travels with the skill, not in a system prompt that can be overridden, but in the skill manifest itself.
The longer pattern: agents trained on structured, constrained skill definitions from the start behave differently than agents bootstrapped from raw capability. Safety as architecture, not afterthought.
The goal isn’t to make agents less capable. It’s to make their capabilities legible, bounded, and auditable.
The constraint is the feature.