An agent is governed by four controls that live in the system, not in the model's good behavior: an audit log of every action, minimum permissions per agent, limits enforced in code, and a stop switch a person can pull at any moment. They are what makes the principle real: your team steers, agents execute, and everything is audited.
What does the audit log record?
Every agent action leaves a record that can be queried and can't be quietly rewritten:
- What it did, on which system and which record.
- When, with which credential and inside which process.
- What information it had in view and what reason it gave for acting.
- What it said and to whom, when the action was a communication.
- Whether it required approval, who gave it and when.
The log serves three readers: operations, who review what happened; IT, who investigate a failure; and internal control or audit, who need evidence. To serve all three, the record is designed before the agent is built, not added afterward.
How are permissions defined?
By least privilege: the agent receives only the actions its task requires.
- Its own identity. Each agent has its own credentials in each system, separate from any person's.
- Read and write kept apart. An agent can read more than it can modify.
- Limits per action. For example, which statuses it can change or how many contacts it can make in a day.
- A closed catalog. The agent can only call the actions the connector exposes. There is nothing to "discover".
- Periodic review. Permissions are reviewed like a person's: when the process, the team or the system changes.
Where do the limits live?
In code, not in instructions. If you tell a model "don't contact anyone after 8 p.m.", that is a request the model will usually follow. If the connector rejects any send outside allowed hours, that is a control that holds every time. Together they give you an agent that behaves well and a system that doesn't depend on it behaving well.
The working rule: every important restriction is implemented as validation in the connector or the core, and tested by trying to violate it. A test that only shows the agent behaves when asked nicely proves nothing.
How does a person step in?
Three ways, from lightest to heaviest:
- Approval. Sensitive actions stop until a person authorizes them. They see the proposal and the evidence, and decide.
- Takeover. A person joins a conversation or case in progress, handles it, and when finished hands it back to the agent. The agent picks up with what happened in view.
- Rule-based escalation. The core itself sends a person whatever exceeds its limits or that it doesn't understand, with the context already assembled.
The agent doesn't argue or resist: when a person takes over, the agent yields. And it never passes as a person: whoever is talking to it knows it is an agent.
How do you stop an agent?
With a stop switch visible to whoever operates, immediate and graduated:
- Pause a case. Stops a single conversation or process.
- Pause an agent. Stops everything that agent does, without touching the others.
- Close a connector. Cuts access to one system. The agent stays alive but loses that entry point.
- Stop everything. Halts all agent activity and hands the work back to the team.
A stop switch that exists only in theory is useless. It gets tested, and it is written down who may use it. This is part of what Synthetic OS does in our architecture: it directs each agent with its rules, monitoring and stop switch, while Agentic OS operates your systems.
Where does the team see all this?
In an operations view where you see the agents, their conversations, their open cases and their audit log, and from which you approve, step in and stop. We call it the Agentic Office. The idea is that supervising an agent feels more like reviewing a work board than reading technical logs.
With governance in place, the natural next topic is security and data. To see control applied to a concrete process, review agentic cores or go back to the guide.