Do we need this if we are a small business, not an enterprise?

You need it more, because there is no security team to catch what the system did. The version for a small business is lighter — a short permission list, one approval queue, a readable log — but the principle is the same. It is far cheaper to add on day one than after an incident.

Will guardrails make the AI less useful?

They make it usable at all. Without boundaries the only safe way to run an AI system is with a person watching every action, which is not automation. With boundaries you can let it run unattended inside the lines and only look at what crosses them.

Can this be added to an AI system we already have?

Usually, yes. Permission scoping, logging and an approval queue can be wrapped around most existing systems. Where the existing design makes that impossible, I will tell you — that finding alone is worth the review.

What is an autonomy level, in practical terms?

A written statement of what the system may do without a human, from read-only up to irreversible changes. Each level withholds specific actions — deploy, spend, production writes — and moving up a level is an explicit decision made after the system has proven itself at the level below.

Who can see the audit log?

Whoever you decide. It is stored where you control it, in a format a person can read, and it is yours. Nothing about the log depends on me or on a third-party service you might stop paying for.

You want AI in the business but cannot defend it to a client, an auditor, or yourself.

Guardrails and audit

The layer most AI projects skip: permission boundaries, audit trails, and explicit autonomy levels that decide what a system may do without a human.

The situation

The question that stalls AI projects is rarely 'can it work'. It is 'what happens when it does something we did not intend, and how would we even know'. If you cannot answer that for a client, a regulator, an insurer or your own board, the project stays a demo — and it should.

Guardrails and audit is the layer that most AI builds skip because it does not show up in the demo. I do not skip it, because I refused to run an agent on my own machine without it. This work makes an AI system explainable after the fact and bounded before it: it can only touch what it was allowed to touch, and there is a record of everything it did.

How I approach it

Permission boundaries per action, not per system

A system that 'has access to the CRM' is not a boundary. I scope permissions to individual actions: read a record, draft a reply, send it, delete it. Each is granted or withheld separately, and anything withheld is impossible rather than discouraged. The default for every action is no, and the list of yeses is short enough to read aloud in a meeting.

Explicit autonomy levels

Every system gets a stated autonomy level that says, in plain terms, what it may do without a person: read only; propose changes; make reversible changes; make irreversible changes. Deploys, spend above a threshold and production writes sit at levels a system is not granted until it has earned them through weeks of supervised operation. Raising the level is a decision you make deliberately, not a default you inherit.

Audit logs that answer the actual questions

The log records what ran, what it was asked to do, what it touched, what it cost, and what changed. That is the set of questions an auditor, a client or a puzzled colleague asks afterwards. It is written to be read by a person under mild stress, not parsed by a tool nobody has installed.

Approval queues for anything you cannot undo

Some actions should never be automatic, no matter how good the model is. Sending money, deleting data, contacting a customer, changing production. Those go to a queue where a named person approves or rejects them, with the context needed to decide in seconds. The system does the preparation; the human keeps the decision.

Written down, so it survives you and me

The permissions, the autonomy level and the approval rules are a document as well as code. When someone asks 'what is the AI allowed to do here', there is a one-page answer that matches the running system, because the running system is generated from it.

What gets delivered

Zero-trust permission boundaries per action
Full audit logging of what ran, cost and changed
Autonomy levels that withhold deploy, spend and production writes
Human-approval queues for anything irreversible

What it costs to get wrong

An agent with broad credentials that misreads an instruction and modifies something it was never meant to touch, with no record of which step did it.
A client audit or a security questionnaire you cannot answer, so the deal or the renewal stalls on 'what does your AI have access to'.
A team that quietly stops using the system because nobody trusts it, after the budget has been spent.
The discovery, weeks later, that a system has been spending or writing far more than anyone assumed, because nothing was counting.

Why you can believe this

I built a local-first coding agent on exactly this model — no cloud, explicit permission boundaries, comprehensive audit logging — because I was not willing to run one that worked any other way.

Explore the work Read the ai-os case study

Questions buyers ask

Do we need this if we are a small business, not an enterprise?: You need it more, because there is no security team to catch what the system did. The version for a small business is lighter — a short permission list, one approval queue, a readable log — but the principle is the same. It is far cheaper to add on day one than after an incident.
Will guardrails make the AI less useful?: They make it usable at all. Without boundaries the only safe way to run an AI system is with a person watching every action, which is not automation. With boundaries you can let it run unattended inside the lines and only look at what crosses them.
Can this be added to an AI system we already have?: Usually, yes. Permission scoping, logging and an approval queue can be wrapped around most existing systems. Where the existing design makes that impossible, I will tell you — that finding alone is worth the review.
What is an autonomy level, in practical terms?: A written statement of what the system may do without a human, from read-only up to irreversible changes. Each level withholds specific actions — deploy, spend, production writes — and moving up a level is an explicit decision made after the system has proven itself at the level below.
Who can see the audit log?: Whoever you decide. It is stored where you control it, in a format a person can read, and it is yours. Nothing about the log depends on me or on a third-party service you might stop paying for.