Stopping dangerous agent actions requires layered controls enforced in code, not just careful prompting, because a model can be persuaded or can simply err under ambiguous inputs. The first layer is scoping the agent's tools tightly, granting only the specific API calls it needs rather than broad database or shell access, and making destructive actions such as deletes, transfers or external sends require a separate, explicitly permissioned tool. The second layer is policy enforcement outside the model, such as spending caps, rate limits, and rule-based checks that block an action regardless of what the model decided, plus sandboxing any code execution in an isolated, network-restricted environment. The third layer is human approval for the highest-risk actions, combined with full audit logging of every tool call, its arguments, and its outcome so incidents can be reconstructed. Testing with adversarial prompts and unusual inputs before launch, and running continuous monitoring for anomalous action patterns after launch, closes the loop between design-time and run-time safety. Nanobase AI builds these guardrails as infrastructure-level controls around the agent, treating the model itself as untrusted input to a permissioned system rather than the final authority.
Treat the model as untrusted input to a permissioned system
The mental model that produces reliable safety controls is to stop treating the language model as the authority that decides what is allowed, and start treating it as an untrusted component whose output happens to be a proposed action. Every proposed action then passes through a system that was designed assuming the model could be wrong, manipulated, or simply confused by ambiguous input, the same way a web application does not trust raw user input just because it came from an authenticated session. Safety comes from what surrounds the model, not from how well the model was prompted to behave.
Reducing blast radius at each layer
No single layer below is sufficient alone; each one catches a different class of mistake the others do not.
| Layer | Control | What it limits |
|---|---|---|
| Identity and permissions | Scoped API credentials per tool, no shared admin account | What the agent can technically reach at all |
| Policy enforcement | Spending caps, rate limits, allowlisted actions in code | What executes regardless of model output |
| Execution environment | Sandboxed, network-restricted runtime for any code execution | What a compromised or buggy action can touch |
| Human checkpoint | Approval required for the defined high-risk action set | What runs without a person confirming intent |
| Audit trail | Full log of every call, argument and outcome | How fast an incident can be diagnosed and contained |
Why scoping permissions is the highest-leverage layer
Of the five layers, the one that prevents the most incidents before they can even start is scoping what the agent's credentials can reach. An agent given a narrow, purpose-built API key for exactly the actions its task requires cannot cause damage outside that scope, regardless of what the model decides to attempt, whereas an agent given broad database or shell access relies entirely on the model's judgment holding up under every possible input, which is a much weaker guarantee. Granting the narrowest credential that still lets the agent do its job is worth more than any amount of prompt-level instruction telling the model to "be careful." This is also the layer most projects under-invest in, because reusing an existing broad service account is faster to set up than provisioning a new scoped one.
Sandboxing code execution specifically
Agents that execute code, whether for a coding assistant or a data-analysis task, need an isolated runtime that assumes the generated code could be wrong or hostile. A practical sandbox restricts network egress to only the specific destinations the task requires, runs with no access to credentials or file systems beyond what that task needs, enforces CPU, memory and time limits so a runaway process cannot degrade shared infrastructure, and is torn down after each task rather than persisted, so nothing from one run can leak into the next. Skipping any one of these controls turns a productivity tool into a real security exposure the moment an unexpected input triggers unintended code.
Closing the loop before and after launch
Safety is not a one-time launch checklist; it needs a before-launch and an after-launch half, and most teams under-invest in the second.
- Before launch, run adversarial and unusual-input testing specifically targeting the highest-risk actions in the catalog, not just the happy path.
- Classify every tool into the risk tiers described for human approval design, and confirm destructive actions require the hard-gate path.
- After launch, monitor for anomalous action patterns, such as an unusual spike in a specific tool's call volume or arguments outside the normal range.
- Review the audit log periodically even without an incident, since patterns worth fixing often show up before they cause visible harm.
Frequently asked questions
Isn't careful prompting enough to prevent dangerous actions?
No. Prompting can reduce the frequency of certain mistakes, but it cannot guarantee behavior the way a code-enforced limit can, because a model can misinterpret ambiguous input or be manipulated by content it processes, such as a prompt injection embedded in a document. Prompting is a helpful supplement, not a substitute for enforced controls.
What is the single most common gap in early agent deployments?
Reusing a broad, pre-existing service account or admin credential instead of provisioning narrowly scoped access for the agent specifically. It is the fastest way to get a prototype working and the most common root cause when an agent does something outside its intended scope.
Does sandboxing slow down agent performance meaningfully?
There is some overhead to spinning up an isolated execution environment per task compared to running code directly, but for most enterprise workloads this is a small fraction of total task latency, especially against the cost of a single serious incident from unsandboxed execution.
How do we decide which actions go on the blocked list versus the hard-approval-gate list?
Blocked actions should be irreversible or high-consequence enough that no autonomous path, even with approval, is acceptable, such as permanently deleting production data. Hard-gate actions are reversible or bounded in impact and become acceptable once a specific person has confirmed the intent.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, builds these layered controls as infrastructure around every agent it deploys, scoping credentials, enforcing policy in code, and sandboxing execution rather than relying on prompt instructions for safety. This work is detailed further in human-in-the-loop approval design and in defending agents against prompt injection.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.