Skip to content

Permit

Agents need more than prompts. They need boundaries.

An agent's behaviour cannot be secured by instructing it carefully. Anything enforced only in a prompt is a request, and anybody who can send your company a message can try to change it. So the controls here sit outside the model: identity, least privilege, tool-level authorisation, network policy, secret isolation, rate limits, approvals and an emergency stop.

Risk levels

Assigned by what happens if the call is wrong.

LowReading something that cannot be wrong for longRead analytics
MediumSomething a customer will seeSend an email
HighMoney, commitments or contractsChange a budget
CriticalAccess, security and the platform itselfChange a permission

A prompt is not a control

"Never issue a refund" in a system prompt is a preference. The refusal has to happen at the capability, after the model has decided to try, or it is not a limit.

Least privilege, enforced by default deny

Nothing is reachable until something grants it — capabilities, records, network endpoints. A new agent can do nothing, which is the only safe starting state.

Content from outside is never an instruction

Message bodies, attachments and imported pages are treated as data. In a product where anybody can email you, prompt injection is an expected input rather than an edge case.

Isolation between organisations is not a permission

Cross-organisation reads are not something anybody can be granted, including us. Enforced at the record level rather than by a filter somebody could forget.

Questions this answers

The things you currently have to ask somebody.

Each of these is a question an owner asks regularly and currently answers from memory, a spreadsheet, or by interrupting whoever is nearest.

What stops an agent doing something we never intended?

Could a customer's email change how our agent behaves?

Where do the credentials for our connected systems actually live?

What can an agent reach on the network?

Where this stops

What it does not do.

None of this makes an agent safe to point at anything. A correctly permissioned agent with a badly chosen job will do the wrong thing reliably and within its limits, and that is the customer's decision to get right. Security controls also cannot judge content: an agent permitted to email customers can send a badly worded email, and no boundary catches that. We hold no position that this product makes you compliant with any regime — no software does.

Next

Where this connects.

Give AI a job.

Build an agent, choose what it can access, define what it may do, and deploy it to work safely across your business.

No code required · Full SDKs and API · Stop any agent instantly · [email protected]