Model guardrails, enforced in code the model cannot reach.

In every system SolaryxDev builds, spending money, deleting records and first contact with a customer wait for a named person. The hold lives in ordinary code outside the model, where no prompt can reach it.

Guardrails keep a system from spending money, deleting records or contacting a customer for the first time on its own. The model may read, draft and propose. Those actions run in separate deterministic code with its own permissions and wait for a named person to release them, and no prompt or document the model reads can change that code.

Irreversible and high-value actions wait for a person.

We run our own company on this rule, and it is why a model is allowed near an ERP at all.

The rule comes from how a system is layered. Money and state live in deterministic code with no model in the path, while models do the reading, drafting and classifying inside the product and hold no authority over either. Agents propose. Deterministic code carries out only what has been approved.

Every system we build holds these actions for a person:

Paying, refunding, charging or committing to spend.
Deleting, voiding or overwriting a record.
Contacting a customer for the first time.
Anything beyond a limit you set on value, volume or credit.

Can a prompt talk the system past the gate?

No. The gate takes no instructions from the model. Prompt injection hides instructions in an email, a web page or a file the model reads, and no reliable fix exists inside the model. OWASP says it is unclear whether fool-proof prevention exists, and in December 2025 the UK National Cyber Security Centre warned it may never be totally mitigated the way SQL injection can be, and advised reducing risk and impact.

So the permission to act lives in ordinary code outside the model. OWASP's guidance on excessive agency asks for the same design, with a person approving high-impact actions and authorisation enforced in the downstream system, outside the model's reach.

Outbound contact is on the list because of what Simon Willison calls the 'lethal trifecta'. A system with private data, untrusted content and a way to communicate externally can be tricked into sending that data out. Holding outbound contact for a person removes the third leg.

The gate is built from seven controls.

Narrow, typed tools. Each does one job in your systems, such as creating a draft, reading a record or holding a slot, and none is a raw database connection.
A hard refusal gate. Whatever the model writes, code blocks spending, deletion, sending to a customer and anything over your threshold.
An approval queue. The person releasing a held action sees the system's input, its proposal and its reasons on one screen.
Budgets. Each run has token and call limits with an alert, so a runaway loop stops at its limit.
An audit trail. Input, plan, every tool call, every result and the final state, written so someone who was not there can follow it.
Reversibility. Actions are written so they can be undone, and the undo is tested before launch.
Fail closed. When the gate cannot decide, because a check errored or a setting is missing, the action is held.

The same gates run our own company.

Three of them run in our own platform today:

Customer email. Every message to a client goes to an outbox first and sends without a person only when its category is approved for automatic sending. A missing category counts as unapproved, so the message waits.
Refunds. Our operations console records a refund and never moves the money. A person issues it outside the system, and the console books it afterwards.
Duplicate charges. When the check for an existing payment cannot run, the system refuses to record a new one and asks for it to be entered by hand. A test in the release suite proves it.

None of these gates knows whether a person, a script or a model made the request, so the control holds whoever is asking.

A model contacts customers only where you allow.

Automatic messages stay inside relationships you have already approved, and only in categories you approve, such as a reminder about an appointment the customer booked. A first message to someone, anything about money and anything outside an approved category wait in the queue for a person.

You choose the approvers and set the thresholds.

Approvers are named per type of action, for example finance for payments, the account owner for customer messages and an administrator for deletions.

A threshold can be a value, a volume or a list of customers. Thresholds are set during the build, as the refusals are wired, and live in code or configuration outside the model. Changing one is a recorded change through the release gate, and no prompt edit can move it.

The design follows published security guidance.

The main reference is the OWASP Top 10 for LLM Applications, LLM01 prompt injection and LLM06 excessive agency in particular, together with three risks added by OWASP's 2026 list for agentic applications: tool misuse, identity and privilege abuse, and human-agent trust exploitation. Evidence from evaluation and the audit trail fits the Manage function of the NIST AI Risk Management Framework.

We hold no certification for this and claim none. How we test an agent before it goes live is in our guide to evaluating an autonomous agent.

Frequently asked questions

What do model guardrails stop a system from doing on its own?

What are LLM guardrails?

Controls on what a system built on a language model may do. Some live in the model's instructions, where a crafted input can argue with them. The ones this page relies on sit outside the model in ordinary code with its own permissions, so the model can propose a high-impact action and never complete it alone.

What does human in the loop mean for an agent?

A person approves defined actions before they happen. In our systems, spending, deleting and first customer contact queue until a named approver releases them, with the context needed on one screen.

What is prompt injection?

An attack that hides instructions in content a model reads, such as an email, a web page or a file, to make it act against its owner's intent. OWASP ranks it first among risks for LLM applications. No fix inside the model is reliable, which is why the authority to act is kept outside it.

What is excessive agency in an LLM system?

OWASP's term for the damage a model can do with more tools, permissions or autonomy than its job needs, including high-impact actions nobody approves. The remedies are narrow tools, authorisation in the downstream system and human approval.