Docs / Policy

The policy you write

Ten rules, phrased so you can lift them into your own document, and which of them Mindset already enforces without anyone policing it.

This is a policy you write and own. It is not a Mindset setting and not something we apply on your behalf. What follows is the version we see working across the companies Mindset runs in: ten rules, phrased so you can lift them into your own document.

The reason it is short is that seven of the ten are already true. Mindset enforces them whether or not anybody has read the policy, so writing them down is documenting a control rather than issuing an instruction. The remaining three are conventions your team has to hold, and those are the ones that decay if nobody is watching.

Rule one: Everything reaching an outside system goes through a named operation

Not a system, an operation. The unit of permission is get the purchase order matching this invoice number, not the finance system. Permission at operation level is what makes the rest of the policy possible, because a list of operations is something a person can actually read and sign off.

Rule two: Credentials sit with Mindset's secure secret keeper, never with the agent or in a chat

The login details for a connection are held by Mindset. They do not reach the agent and they do not reach the model. An agent running under a named person's credentials is the single most expensive thing to unwind later, because every log you own will attribute its actions to that person.

Rule three: A write waits for a person

The agent records exactly what it wants to send, the run finishes, and the change waits behind an approval link. This is on by default. It can be turned off, but only as a deliberate setting on the whole Mindset organisation, and the record then names the policy rather than inventing an approver.

Two design rules make approval worth having. Make one change rather than fifty, because one approval covering a batch is a decision somebody actually reads and fifty separate ones get waved through. And put enough in the approval that whoever reads it does not have to go and look anything up.

Worth knowing before you rely on it. A study of more than 40,000 agent runs and roughly 409,000 approve-or-deny decisions found around one in three dangerous commands were approved, and that people catch what looks dangerous rather than what is. The EU AI Act names automation bias in Article 14, requiring that anyone overseeing a system stays aware of it. Showing what is about to happen, rather than asking yes or no, is materially better than a bare prompt. Volume is still the thing that breaks it.

Rule four: An agent can never approve a write

Not its own, and not another agent's. There is no setting on an operation that changes the rule. The rule matters more as agents start calling other agents, because that is the point at which a chain of approvals could otherwise close on itself.

Rule five: Every action is recorded against the run it belonged to

Agents cannot skip the record. Every run can be read back afterwards step by step, exactly as it happened. If your evidence has to live somewhere else, spans export over OpenTelemetry into whatever your team already audits.

Rule six: What is built in one Mindset environment cannot see another

Mindset Test and Mindset Production are separate partitions with separate Mindset connections. Nothing crosses on its own. Separation is what lets people build against real shapes without touching real systems.

Rule seven: Nothing goes live until every test criterion passes

Not most of them. Every one. A better average never overrides a single failure. The criteria are written by whoever built the agent, so the review that matters is of the criteria themselves, and that goes to the system owner once before the first version goes live. The set that passed is recorded against the version.

The three rules that are yours

These are conventions rather than controls, and they are the ones that decay.

• Each agent has a named owner and a backup. There is no owner field, so the owner and backup go in the agent's description, in the same format every time. The failure is never that nobody can do the job. It is that everybody could, so nobody does.
• Personal tools stay personal. Do not register them, do not review them. A policy that governs the agent tidying somebody's meeting notes will not be taken seriously on the agent touching bank details.
• Agents nobody uses get archived. Anything that has not run in thirty days is a question, not a fixture.

Write the policy as ten lines, not ten pages. Seven of them are already true. Three of them are promises your team is making, and being honest about which is which is what stops the document being decoration.

Deciding what the policy covers

The rules above are what a governed agent lives under. This is how you decide which agents those are, and it is the half that stops a policy being ignored.

Six times no and the automation is somebody's personal tool. Leave it alone. Do not register it, do not review it, do not ask anyone to declare it. A policy that governs the agent tidying somebody's meeting notes will not be taken seriously on the agent touching bank details.

The triggers that appear later

An agent's risk profile changes during its life, not at the start of it. A policy that only assesses at the start will be wrong within months.

• Crossing a boundary. An agent that starts reaching between domains, or between systems that were previously separate, has changed shape even if nothing about its instructions changed.
• Delegation. An agent that calls other agents is a different risk from one that does not. Mindset records a delegated run inside the run that called it, so delegation is visible rather than inferred.
• Compositional risk. Two operations that are each safe and are not safe together. Nobody catches this by reviewing operations individually.
• Drift. The agent behaves differently without anyone changing it. The comparison of what an agent was granted against what it actually called is where this shows up first.
• Failure history. Something that has failed before deserves tighter handling than something that has not.
• Volume and velocity. A change in how often the agent runs, or how much it does per run, against its own baseline.
• Facing outward. Anything a customer or a third party sees.

Three tiers, if you need something more graduated

In or out is enough for most organisations. If you need more, three tiers is the smallest version that still means something.

This is the Cloud Security Alliance's autonomy scale cut down to the levels you can operate. Their own position is that the top of their scale is not appropriate for enterprise deployment today. Everything Mindset does by default is the middle tier.