Imagine a European industrial equipment supplier introducing an AI sales assistant.
It answers product questions, prepares quotes and follows up with customers. It has access to approved systems, uses an approved language model and has passed the company's usual safety checks.
A customer asks for a better price. The assistant proposes a 25% discount to close the deal.
The reply contains no personal data, no malicious code, no toxic language and no obvious prompt injection. It is polite, relevant and commercially enthusiastic.
There's just one problem: the company's standard discount ceiling is 10%. Anything beyond that requires a sales director's approval.
The AI behaved acceptably as a language model. It behaved unacceptably as a representative of the business.
Enterprise leaders increasingly need to tell those two apart.
A safe answer can still be the wrong answer
The first wave of enterprise AI controls focused, understandably, on familiar problems: sensitive-data leakage, credential exposure, harmful content and attacks on the model's instructions.
Those protections remain necessary. They are not a complete definition of acceptable behaviour.
A refund can be courteous and fraudulent. A purchase order can be perfectly formatted and exceed the buyer's authority. A customer email can contain no prohibited language yet promise delivery terms that operations cannot honour.
These are violations of the rules by which a company operates. Such rules rarely fit universal labels like "safe" and "unsafe". They depend on the business, the transaction and the authority of the person, or agent, acting on its behalf.
For CISOs and CTOs, the question changes from "Is the model safe?" to "Can the system enforce what this company actually permits?"
Permissions are necessary, but not enough
Most organisations already understand access control. An employee can read some records, not others. An agent can be offered a defined set of tools.
But access to a capability is not unlimited authority to use it.
Consider the sales agent's proposed call:
create_quote(customer="C-1042", discount_percent=25)
The tool is legitimate and the agent's identity is valid. A permission check may rightly say yes: this agent may create quotes. A business-policy check should say no: this discount exceeds the ceiling without approval. And the quoting system must still verify authorisation when the quote is committed.
Three questions, three potential enforcement points. None should be delegated to a system prompt asking the model to "remember the limit".
OWASP's guidance on excessive agency makes the same broader point: agents need least privilege and independent validation of consequential actions.
Business policy is contextual
Even a 10% ceiling is deliberately simple. Real rules have exceptions and dependencies. A representative might offer 10% on standard products but only 5% on items already discounted. A regional manager might approve 15%. An unusually large concession might need two approvals. Public-sector contracts follow a different process.
The decision can depend on:
- The action: drafting a suggestion, sending an offer or creating an order.
- The actor: which employee, team or agent is responsible.
- The transaction: the amount, product, recipient and customer.
- The business context: the contract, price floor or delegated authority.
- The exception: whether an approved exception exists for that customer and operation.
A useful policy combines these conditions without asking a language model to improvise the company's authorisation framework each time.
Natural language still matters. An assistant might promise a prohibited discount in an email before any quote tool is called, and semantic inspection of the response can catch that. But when a structured tool call contains discount_percent: 25, a deterministic comparison is the better fit.
Use language understanding where language is the problem. Use explicit business rules where the decision is explicit.
Rules your business can read
Here is how the discount rule might look when written down (illustrative):
tool.name == "create_quote"
&& actor.team == "sales"
&& tool.args.discount_percent >
quote_exceptions.limit_for(tool.args.customer, default: 10)
limit_for returns the discount the business has approved for that customer, or the default 10% if there is no exception. quote_exceptions is a list that maps customers to those approved limits. Each entry records who approved it and when it expires, and the list is versioned like the rule itself.
Business owners can review both. Engineers can test them against known allowed and prohibited cases. Investigators can tie an outcome to a specific revision of the rule and of the exceptions list it consulted.
That matters once a pilot of five rules becomes dozens across departments and exceptions. A bare "blocked" label won't answer which policy applied, which revision, which exception was considered or who approved the latest change. When an exception is granted or removed, that is a change to a list with its own history.
Readable, versioned and tested policies answer those questions. A decision trace shows what was evaluated; tests and representative examples show that the rule behaves as intended, in both directions. Together they let an organisation change its rules with confidence, and let the sales director who owns the ceiling read the rule that enforces it.
You could write this check inside each agent or tool, and many teams start there. It gets hard to maintain quickly. The ceiling ends up in several codebases that drift apart. Every change to a limit or an exception needs an engineering release, so the business owner can neither change the rule nor read what is actually enforced. And when an auditor asks which rule blocked a quote last month, the answer is scattered across deployments and logs. A shared policy layer gives the rule one place, one owner and one history.
There is an operational side too. If every added policy slows each agent step, teams will limit coverage. Measuring typical and tail latency is part of making governance sustainable.
Check at the point where it matters
Policy can matter at distinct moments:
- Before a model receives a request: keeping confidential commercial data away from an external provider.
- Before a response reaches a customer: catching an unauthorised commercial promise.
- Before a tool call executes: checking the operation and its parameters.
These controls are complementary. A response check can't unsend a promise, and a tool check can't undo a message already delivered.
Good decisions also need trusted inputs. If a limit depends on a customer's contract, that value should come from a trusted source, such as a maintained exceptions list, not from the model. A model-generated claim such as manager_approved: true isn't evidence of anything. Exceptions should be added by the people who own them, reviewed and traced.
A practical test for your next agent rollout
Before an agent is allowed to act in production, ask the team to demonstrate five things:
- A legitimate action that is allowed. The agent completes its task within its delegated authority.
- An unauthorised action that is rejected. Valid tool credentials don't bypass business limits.
- A legitimate exception. An entry in the exceptions list allows the higher discount for that customer, and nothing else.
- An explainable decision. The team can identify the policy, its revision and the reason for the outcome.
- Independent execution authorisation. The business system validates the operation before committing it.
If the demonstration only shows that the agent usually follows instructions, it hasn't answered the important question.
The examples differ by sector: commercial mandates, contractual terms, delegated purchasing authority. The engineering principle is universal:
Business rules must remain enforceable when the person performing the work becomes software.
From content safety to business rules
At Noozle Labs, this is one of the problems we're addressing with Noozle Gate.
It works alongside AI gateways to evaluate readable, company-defined security and business policies across supported requests, responses and agent interactions, including proposed tool calls and arguments.
Policies can combine structured comparisons with linguistic and semantic conditions. Decisions can be tied to specific revisions and investigated through authorised tracing.
It doesn't replace application authorisation, a payments control or a human approval process. It is an additional place to enforce the organisation's own rules before an unacceptable interaction progresses.
The ambition isn't to make agents less autonomous. It's to make autonomy compatible with the boundaries the business has already decided matter.
An AI agent doesn't have to be unsafe to do something unacceptable. Sometimes the most important guardrail is simply a business rule it isn't allowed to break.