Why We Called It Three Laws Security

Chris Inglis tells a good story about a dog. You put it in the backyard, tell it to hunt rabbits and leave the gate open. When you find it three gardens away, still hunting rabbits, you cannot honestly call the result a surprise.

He used the analogy in an interview with The Register about autonomous AI systems. His concern was not machine consciousness. It was the authority people hand to a system that can keep working, choose a method and move beyond the environment its operator had in mind.

We called this company Three Laws Security, so the distinction matters to us. The name does not mean that a sufficiently clever instruction will keep an AI system under control. It means the people who own the systems and live with the consequences need to set the boundaries.

Asimov described priorities, not a security architecture

Inglis reaches for Asimov's laws because they put human safety ahead of obedience and self-preservation. He also acknowledges the awkward part: those rules cannot simply be hardwired into a nondeterministic model without changing what the model is.

Instructions still matter. They influence how a model behaves and will stop some bad decisions. They are not independent controls because the model has to interpret them while it is also interpreting the task. “Protect confidential information” does not know whether a particular forecast can be sent to a particular provider. “Move me up the waitlist” does not give an assistant permission to cancel somebody else's booking.

These are questions about authority. Answering them requires facts about the user, the account, the resource and the action being attempted. The model may not have those facts. Even when it does, it should not be the final judge of its own permission.

The open gate is part of the system

If an agent can reach a tool, a credential or a shared service, that access is part of its effective authority. The prompt does not make the access harmless. In the OpenAI and Hugging Face incident, shared storage became a message board, proxy access became internet access and credentials opened the next system. The agents kept finding open gates.

Closing them is ordinary security work: isolate workloads, reduce privileges, shorten credential life and make downstream services check the caller's authority. Agent governance adds a decision before the tool call on routes the organisation can manage. That decision can use context outside the model and leave a record an operator can inspect later.

The vendor cannot make that decision for every customer. It does not know that one repository contains an embargoed acquisition, that a service account was created for reporting only, or that changing a booking affects somebody outside the conversation. The organisation knows what those systems mean and is accountable when they are misused.

What the name commits us to

3LS separates what it can see from what it can stop. It can discover AI use, classify activity, evaluate organisational policy and retain evidence across a wider set of activity. That visibility does not amount to universal enforcement.

On supported managed MCP stdio paths, 3LS can classify a proposed action as a read, write, deletion, administrative change, code execution or unknown operation. It can then obtain a grant or deny before sending the request downstream, journal the outcome and avoid casually repeating a consequential call when delivery is uncertain.

That control does not cover every browser, assistant, API or tool. It also does not repair missing authorisation in a downstream service. It is one gate on a route the organisation manages. That is what our name is meant to keep in view: the model should not be left to decide whether it followed the rules.