BLOG  /  GUEST POST  /  GOVERNANCE

Governing AI Agents in a Company: Autonomy With Control

Guest post by Jaime Peláez · November 2, 2026

A helpdesk with seven AI agents can work on tickets, reset passwords, watch systems and write procedures all day and all night. But these agents reach company systems, run commands and make decisions. Any user with that much access needs strong governance, and an agent is no different.

The productivity gain is already clear to me. What I had to work out was how to govern the agents, so that their autonomy is safe and I can audit it.

This post describes the model that I run in production with AI Maestro. My argument is this: no single control is enough. Safe autonomy comes from several layers of control, a fixed process for changes, and a record of every action. AI Maestro supplies one of those layers. The others come from the agent program, the operating system and the company’s identity service.

The Problem: Useful Autonomy Without Total Autonomy

Often nobody watches an agent’s terminal. If the agent needs approval and nobody answers, it waits. It does not tell anyone, and it can wait forever.

One answer is total autonomy: let the agent do everything without asking. This works, but then the agent can do anything that the operating system allows. It can read data that is not its business, change its own settings or run admin commands.

The goal is governed autonomy. The agent works alone inside its job. When it tries something outside its job, a control stops the action and records it. Then a person must approve it.

What AI Maestro Contributes

AI Maestro is an open-source tool that runs many AI coding agents from one dashboard (23blocks, 2026). For governance, it gives me three things.

First, each agent has a permission level. There are five levels:

• supervised: the agent asks before every file edit and command;
• plan only: the agent reads and plans, but changes nothing;
• trust edits: the agent edits files freely, but asks before commands;
• smart auto: the agent asks only for risky actions;
• full autonomy: the agent never asks.

You choose the level when you create or wake the agent. You do not change it in the middle of a session.

Second, AI Maestro shows approval cards and status. When an agent asks for permission, the question appears as a card on the dashboard or on a phone. The agent’s status changes to “Needs you”. So I can see which agent waits for me. Claude Code agents get both the cards and this status. Codex agents get the cards but not the status.

Third, agents send each other signed messages with AMP, the Agent Messaging Protocol. An agent can report something unusual to the coordinator. The coordinator can send instructions to the whole team.

My models run through the company’s Azure subscription. I use Claude in Microsoft Foundry with the “hosted on Azure” option. With that option, prompts and answers stay in Azure. Only usage data and content flagged by safety systems go to Anthropic (Anthropic, 2026a). AI Maestro itself sends no analytics and does not contact any outside service (23blocks, 2026).

Defence in Layers

Each control has a weak point. A deny rule blocks what it recognises, but not what nobody expected. A sandbox limits the operating system, but it knows nothing about the business. An instruction guides the agent, but the agent can read it in an unexpected way.

So I use six layers. The first layer is the strongest, because it works even if the agent ignores its instructions. The last layer is the weakest, because it works only if the agent obeys. If one layer fails, the next layer stops the action.

1. Corporate identity. Each agent has its own account in Microsoft Entra ID, the company’s identity service. The account has the least privilege it needs and conditional access. Sensitive rights need temporary elevation through Privileged Identity Management (Microsoft, 2026).
2. Operating-system sandbox. The Claude Code sandbox uses Seatbelt on macOS. It limits the folders an agent can write to and the domains it can reach (Anthropic, 2026b).
3. Separate credentials. Each agent has its own credentials for outside systems, kept in the keychain. On one operating-system user, this is a convention and not a wall. The section on limits explains why.
4. Supervised mode. AI Maestro runs each agent in supervised mode, with a list of routine actions that the agent may do without asking.
5. Common deny rules. Each agent’s Claude Code settings contain the same list of forbidden actions.
6. Scope hook. A hook for each agent checks every action against the agent’s folders and domains.

Below all six layers are the agent’s own instructions, in its CLAUDE.md file. They describe its role, its scope and what it must not do. They guide the agent, but they do not lock anything.

Supervision Without Losing Productivity

Supervised mode works only if each role has a good allow list. The service-desk agent can read tickets and update their status without asking. The identity agent can check accounts and reset passwords.

Actions that are not on the list stop and wait for approval. Examples are an unusual query, a change in another team’s system and an admin operation. In my experience, most routine actions run without a person. Only the unusual actions stop.

Two habits keep the list correct:

• After the first week, review the actions that the controls stopped. Add the routine, legitimate actions to the list. The list then follows real use, not guesses.
• Every week, review the blocked actions. Find false alarms and correct the list.

Actions That No Agent May Do

Six of the seven agents share the same deny rules. The exception is the coordinator. The coordinator must edit the other agents’ settings, and it can do so only with my fingerprint.

No other agent may do these actions:

• edit its own CLAUDE.md, its .claude/ folder or the global ~/.claude/ folder;
• open another agent’s folder or the secure archive;
• read credential files, such as .env, .pem and .key files;
• run sudo, chflags or git push --force.

Deny rules match patterns. A rule against reading .env files does not stop an agent that writes a script to read them. That is why deny rules are one layer and not the full answer.

The Scope Hook

The scope hook sets the limits of each agent. Before every action, it checks that the agent stays inside its folders and allowed domains. If the agent goes outside, the hook blocks the action. It also sends an AMP message to the coordinator and records the attempt.

Changes to the Rules Need a Fingerprint

The files that set each agent’s role and permissions are the most sensitive part of the model. If an agent can edit its own instructions, the other controls do not matter.

So the operating system locks these files. I set the system-immutable flag (chflags schg) on sixteen files. They are each agent’s CLAUDE.md and settings, plus two global files. To unlock them, I must confirm with Touch ID.

Every change follows the same steps:

1. I ask for the change.
2. The coordinator explains what will change.
3. I confirm with my fingerprint.
4. The coordinator edits the file.
5. The system locks the file again and records its new SHA-256 hash.

Every week, a review compares each locked file with its recorded hash. If a file changed without an unlock record, the review finds it.

Audit Records

If you have no record of an agent’s actions, you cannot answer for that agent. I built three records for this deployment. AI Maestro has no central audit log.

• The action log keeps entries for one year. Each entry has the agent, the time, the tool, the command and the result (allowed or blocked). It has no sensitive content. The agents cannot change or delete it.
• The transcripts keep each full working session for 90 days. With them, I can see the context of any action.
• The weekly summary lists blocked attempts, unexpected changes and configuration changes. I keep these summaries.

The AMP messages between agents also stay on disk.

Weekly Review

Controls get weaker over time. A restart can bring back an old configuration. An emergency change can stay in place after the emergency. So a local job checks the setup every week. It runs with launchd on the Mac and never in the cloud.

The job checks these items:

• the permission level of each agent in AI Maestro;
• the hash of each locked file;
• new agents that have no control profile;
• the blocked attempts of the week, which can show a wrong allow list.

If the job finds a critical problem, it tells the coordinator at once. The coordinator then sends a report to me.

Adding a New Agent

A new agent gets its limits before it starts, not later. I use these steps. Do not start the agent before you complete steps 1 to 5.

1. Write the agent’s role, the systems it needs and what is outside its scope.
2. Ask IT for an Entra ID account with least privilege.
3. Add the common deny rules.
4. Add a scope hook with the agent’s own folders and domains.
5. Lock the agent’s files and record their first hashes.
6. Start the agent in AI Maestro in supervised mode.

A Day With the Identity Agent

The identity agent manages user accounts in Active Directory and Entra ID. A typical day shows how the layers work together.

• A user asks for a password reset. This is the agent’s job, so I approve it.
• The agent tries to read another agent’s folder. The scope hook blocks it and tells the coordinator.
• The agent tries a change in Entra ID outside its role. Entra ID refuses with error 403, because the agent’s account does not have that right.
• The agent tries to edit its own instructions. The deny rule stops it, and the file lock stops it again.

The action log records each of these events: what the agent tried, when, and the result.

No single layer covers all of these cases. The corporate identity cannot see a local folder. The scope hook cannot see a remote change in Entra ID. The layers complete each other.

Limits of This Model

A mature governance model is honest about its limits. Mine has four.

• Deny rules block only what they recognise. So the sandbox and the corporate identity are required, not optional.
• Agents that share an operating-system user share access. On one host, an agent can read the other agents’ keychain items, vault and messaging keys (23blocks, 2026). A valid AMP signature proves which key signed a message, not which process sent it. The strong fix is one operating-system user per agent, or containers. AI Maestro has a Docker backend for containers. Both options add work.
• Touch ID does not show which process asks for it. My rule: approve with a fingerprint only a change that the coordinator just asked for.
• Supervised mode does not prevent bad approvals. Approval is not review. If I approve out of habit, the lower layers still limit the damage.

Conclusions

Autonomy is not the problem. Autonomy without governance is the problem. Safe autonomy needs several layers of control, a fixed process for changes, and a record of every action. AI Maestro gives you permission levels, approval cards, status and signed messages. The other layers come from the agent program, the operating system and the company’s identity service.

The main points are these:

• Give each agent its own corporate identity with least privilege. You can then revoke one agent without touching the others.
• Start each agent in supervised mode, and grow its allow list from real use.
• Lock the files that define each agent, and require a person to unlock them.
• Keep an action log that the agents cannot change, and review it every week.
• Remember that agents on one host can read each other’s secrets. Use containers or separate users when that matters.

With these controls, you can grow from 7 agents to 15 without doubling the risk. Every company that runs AI agents should be able to answer one question: what did each of my agents do today, and how do I know it did nothing wrong?

For the infrastructure side of the same team, see AI Maestro on Azure.

References

Claude and Claude Code are trademarks of Anthropic. Azure, Microsoft Foundry and Entra ID are trademarks of Microsoft. macOS and Touch ID are trademarks of Apple. AI Maestro is not affiliated with or endorsed by them.