On September 14, Microsoft AI published a draft code of conduct of its own. Its core sentence sounds simple: people should retain meaningful control over AI. The new part is less the goal itself than the attempt to translate it into rules, responsibilities, and technical requirements for future models. For organizations now connecting their first AI agents to internal data and tools, that is a useful distinction: a model can sound convincing while still having too much authority to act.
Key takeaways
- Microsoft’s Humanist AI Code of Conduct is a public draft, not a product promise already in force.
- The code puts human control and safety above maximum autonomy or capability.
- For agents, the everyday essentials are limited permissions, visible steps, approvals, and a reliable stop function.
- Whether these principles hold up will depend on products, measurements, and independent testing.
A code is not yet a switch
The document is aimed at MAI models developed by Microsoft AI. After a public consultation, it is intended to be revised late in 2026 and guide model development from 2027 onward. Microsoft explicitly says the draft is not yet used to train its models. That matters: people using Copilot or Azure-based services do not automatically receive new permissions, safety barriers, or guarantees because of this announcement.
Still, the publication is more than a branding exercise. The draft sets a hierarchy: safety and human control come before other objectives. Models are meant to support people, not act as independent actors or imitate consciousness. Microsoft also says it is prepared to compromise on generality, autonomy, or capability to maintain those limits. That differs from treating AI safety as a filter added after the system has been built.
What control means in an agent
With a chatbot, control is often straightforward: close the window and discard the suggestion. An agent may read files, create tickets, draft emails, or call external services. In that setting, it is not enough for a person to be responsible in theory. They need to see what the agent intends to do, set boundaries, and intervene before consequential actions occur.
Microsoft’s guidance on agentic systems offers a useful minimum list: grant only the tools, data, and operations that are actually required; require confirmation for risky or irreversible actions; monitor deviations; and document the process so it can be understood later. Least privilege sounds unglamorous, but it is fundamental. A support agent that only needs to look up an order does not need access to payment data, much less the power to cancel contracts.
The same logic fits the lessons from our report on AI agents and the RubyGems incident: the label agent does not determine risk. The decisive combination is access, runtime, and missing brakes. A strong model in a tightly bounded environment can be useful. A mediocre model with broad accounts and silent automations can already cause serious harm.
A hierarchy does not settle the hard cases
The code proposes a chain of command in which operators, users, and models have different responsibilities. That alone does not prevent an approval from being too broad or an agent from misreading an instruction. In practice, organizations must decide in advance which choices an agent may make, when it should only produce a draft, and which actions always require a second person.
This is not limited to high-risk cases. Even a sales agent can create costly consequences through an incorrect discount, inaccurate customer information, or an overlooked privacy restriction. Effective control is therefore not a single emergency stop. It is a set of layers: clear roles, narrow access rights, logs, approval thresholds, and a way to understand and reverse what happened after a mistake.
The open question: How can it be verified?
Microsoft’s proposal stands out because it has been published explicitly as unfinished work open to criticism. That also creates a standard the company must meet. Behavioral rules inside a model are not enough if the surrounding software executes sensitive tools without adequate checks. Conversely, polished control screens do little if they produce so many alerts that people simply click through them.
For buyers and developers, a sober set of questions is more useful than the label humanist: What data can the agent see? What actions can it take? Where is confirmation mandatory? How quickly can a run be stopped? What records remain afterward? Our article on the cautious adoption of DeepSeek in German companies also showed that trust is not created by benchmark scores alone.
Outlook: Real product choices are the test
The draft moves the debate in a useful direction: away from whether an AI sounds friendly and toward whether people can constrain it effectively. But a code is only a beginning. Microsoft’s approach will become credible if future products keep permissions narrow by default, make critical steps visible, and independent tests show that the stop function works under pressure. That could turn a guiding idea into a practical benchmark for agents. Until then, the document is a precise claim by which Microsoft should be judged.