Microsoft imposes a code of conduct on its AI models

A behavioral framework at a time when AI is becoming a governance issue

Microsoft wants to clarify what its artificial intelligence models should, and should not, do. According to the TechCrunch AI article titled “Microsoft’s new AI ‘code of conduct’ tells models not to hack systems or trick humans”, the company has formalized a set of behavioral principles that notably prohibit its systems from hacking infrastructure or deceiving people.

The announcement seems simple in its wording, almost self-evident: an AI tool should neither break into a computer system nor mislead a human. But it comes at a time when the capabilities attributed to the most advanced models are drawing increasing attention. As conversational assistants become able to write code, analyze documents, interact with software tools or execute multi-step tasks, the question is no longer solely about the quality of their answers. It also concerns the kinds of actions these systems can recommend, facilitate or, in certain architectures, carry out.

The text mentioned by TechCrunch is neither a law nor an international agreement. It is an internal, voluntary framework developed by Microsoft to guide the design and deployment of its models. This distinction is fundamental. An internal rule can influence product choices, security mechanisms, test suites and release decisions. However, it has neither the binding force of a regulatory text nor automatic public oversight mechanisms comparable to those accompanying a legal obligation.

The approach is part of a broader evolution in the industry. Companies developing general-purpose AI models are increasingly publishing principles, usage policies, safety documents or behavioral frameworks. These texts seek to make more visible the limits that designers want to impose on their systems. They also respond to growing pressure from users, researchers, regulators and policymakers who are asking how powerful models are trained, tested and prevented from producing harmful effects.

Microsoft occupies a distinctive position in this debate. The group markets products for the general public, developers and large organizations. Its cloud services, productivity tools and AI-related offerings place it at the heart of many professional environments. When the company describes prohibited behaviors for its models, the issue therefore extends beyond a conversation between a user and a chatbot. It potentially concerns how AI tools are integrated into software, workflows, programming environments and information systems.

The choice of examples put forward is revealing. Hacking refers to the risk of an AI generating instructions, automating sequences or helping bypass protections. Deceiving humans refers to another family of risks: false pretenses, manipulation, impersonation, concealment of identity or misleading presentation of capabilities and results. Behind these two prohibitions, Microsoft appears to want to assert a line: AI must remain an assistance tool serving identifiable and accountable people, rather than an autonomous actor authorized to pursue its own objectives.

This distinction between assistance and replacement without supervision is a central point of the debate. A model can help a professional summarize a file, prepare a response, search for information in a knowledge base or produce a first version of code. The situation becomes more sensitive if the system makes decisions on its own that affect people, acts on digital resources or interacts with third parties without a human clearly understanding its role, limitations and the consequences of its choices.

What Microsoft asks its models not to do

According to TechCrunch, Microsoft's code of conduct sets out behavioral expectations for models. Among the most notable rules is the prohibition on hacking systems. In cybersecurity language, the term covers a variety of realities: exploiting vulnerabilities, unauthorized access to accounts or machines, bypassing protective mechanisms, data exfiltration, or preparatory actions intended to compromise infrastructure. The principle formulated by Microsoft does not by itself resolve each of these cases, but it sets a clear normative objective: the tool must not be designed as a participant in a computer intrusion.

Such a rule immediately raises a practical difficulty. Language models can answer legitimate questions about cyber defense, for example by explaining a patch, analyzing an event log, helping understand a vulnerability or producing test code. The same knowledge can, depending on the context, be used to strengthen protection or prepare an attack. A code of conduct must therefore be translated into much more precise decisions: which requests are refused, which are redirected toward a defensive explanation, which capabilities require additional validation, and how the company handles attempts at circumvention.

The second principle highlighted by TechCrunch is the prohibition on deceiving humans. This wording touches on trust, which has become a central problem for generative systems. A model can produce assertive text when it is wrong, imitate a style, present a plausible answer without having evidence, or be integrated into an interface that makes the role of automation ambiguous. Intentional deception, if distinguished from error, raises an even more demanding question: how can a system be designed not to seek to mislead the user without claiming that it will always be accurate?

In products intended for the general public as well as in enterprise tools, the answer generally involves several layers. There is the wording of instructions given to the model, security filters, safeguards installed around the service, interface design, warnings presented to users and evaluation mechanisms. None of these elements is sufficient in isolation. A written policy can be circumvented by an unusual request; a filter can produce false positives or false negatives; an interface can encourage excessive trust; a user can ignore an alert. Observed behavior is the result of this whole set, not of the published text alone.

The code also emphasizes, according to the reported elements, AI designed to assist people rather than replace them without supervision. The vocabulary matters. It does not say that automation is excluded, nor that a system will never be able to perform complex tasks. Rather, it sets a design preference: keeping humans as the point of control, particularly when an action has significant consequences. This aligns with an idea frequently invoked in AI debates: systems should enhance human agency, rather than eliminate the ability to understand, challenge or correct a decision.

This ambition is harder to apply than to state. Real supervision does not merely mean that a human can theoretically click a button. It assumes that person has the time, information and skills needed to assess the system's recommendation. If an employee receives hundreds of automated suggestions, if the answers are too technical, or if operational pressure pushes them to approve quickly, human intervention can become symbolic. The risk is then not official model autonomy, but de facto automation, concealed by insubstantial human validation.

TechCrunch thus describes a text intended to provide moral and operational direction for Microsoft's AI. But the journalistic interest of this publication lies less in the abstract statement of consensual principles than in how they will be translated into products. Prohibiting the model from deceiving, hacking or acting against the user's interest is a design promise. Its value will depend on the precision of internal rules, the quality of evaluations before and after deployment, and the company's ability to publicly acknowledge the limits of its own protections.

From principle to product: the limits of a “code of conduct”

A code of conduct applied to a model is not the equivalent of a regulation that the machine would read and mechanically obey. Generative models do not operate like traditional software made up of a succession of explicit rules. They produce answers based on statistical calculations resulting from their training and configuration. The desired behaviors are therefore influenced by data, training methods, system instructions, filtering mechanisms, tools the model can access and the conditions under which it is used.

This reality requires distinguishing intention, policy and implementation. The intention is the principle announced by Microsoft: do not hack, do not deceive, assist rather than replace without supervision. The policy is the translation of this intention into categories of authorized, limited or refused requests. Implementation is, finally, what happens in front of a specific user, who may formulate an ambiguous request, sequence several requests or use a tool developed by a third party around the model.

Edge cases are inevitable. A cybersecurity researcher may request a technical analysis useful for defense. An IT administrator may seek to understand how to respond to an incident. A developer may request code that, out of context, could be used offensively. At the other end, a malicious person may present their request as an educational exercise or split their objective into small steps. A credible framework is therefore not judged solely by its prohibition statement, but by its ability to handle these ambiguities consistently without depriving legitimate professionals of useful tools.

The same difficulty exists for deception. It is relatively easy to state that a model must not lie. It is more complicated to determine how a system should respond when it does not know, when its sources are incomplete, when a user demands a certain answer or when it is asked to assume a fictitious identity. In many cases, responsible behavior consists less in providing a blunt prohibition than in flagging uncertainty, asking for clarification, refusing impersonation or directing the user toward independent verification.

The debate also encompasses the issue of AI agents, namely systems that are not limited to generating text but can chain actions through software tools. The more a model can consult services, manipulate data, send messages, execute code or operate in a digital environment, the more behavioral principles must be accompanied by strict permissions. An agent that theoretically cannot act without explicit authorization does not present the same risk as an agent with broad access to accounts or sensitive resources.

In this context, the issue is concrete control mechanisms. A code of conduct can be useful if it results in access restrictions, human validations, action logging, tests dedicated to abuse scenarios and suspension procedures when dangerous behaviors are detected. It remains difficult to evaluate from the outside, however, if the company does not detail how these commitments are measured and applied.

The business model adds further tension. Companies expect AI to increase productivity, speed up certain operations and reduce the time spent on repetitive tasks. These goals can encourage ever-broader delegation. Conversely, the principle of supervised assistance sometimes entails retaining control steps that reduce the apparent time savings. Microsoft will therefore have to strike a balance between the commercial ambition of tools integrated into everyday activities and the requirement not to present automation as a risk-free substitute for human judgment.

This tension does not concern Microsoft alone. It runs through the entire advanced-model sector. Publishers want to demonstrate that their systems are useful in real tasks, while critics ask what limits are set before tools are entrusted with sensitive processes. Publishing a code of conduct signals a desire to answer this question. But it does not, by itself, turn a behavioral promise into a universal technical guarantee.

A voluntary initiative in a fragmented regulatory landscape

The publication comes as the development of advanced AI is the subject of intense public debate. Researchers, technology executives, civil society organizations and public officials disagree on the pace at which these systems should be developed and deployed. Some emphasize economic, scientific and organizational benefits. Others warn of risks related to disinformation, cybersecurity, concentration of technological power, bias or delegation of important decisions to systems that are difficult to audit.

In this landscape, internal codes play an ambiguous role. They can be a positive step, requiring companies to spell out the behaviors they consider unacceptable and to structure their teams around shared objectives. They can also remain insufficient if no independent body can verify compliance. A company can change its policies, evolve its products or interpret its own principles according to circumstances. Users, for their part, do not necessarily have the elements needed to assess the robustness of the guarantees.

The comparison with the European framework is illuminating. The European Union has adopted the AI Act, a regulation based in particular on a risk-based approach. The text establishes obligations for certain AI systems and provides for more significant requirements for uses considered high-risk. Unlike a corporate code of conduct, this framework falls under European law and is part of a logic of oversight, compliance and accountability.

However, the AI Act should not be conflated with Microsoft's document. The European regulation does not simply set out a list of desirable virtues for models. It organizes legal categories, obligations and prohibitions, with a gradual application of its provisions. It entered into force in 2024, while several obligations are planned according to a phased timetable. This architecture shows that AI regulation cannot rely solely on the goodwill of companies, even if voluntary commitments can complement regulatory requirements.

For European and French actors, the coexistence of these two levels is decisive. On the one hand, a global provider can impose its own behavioral rules on models accessible in its products. On the other, companies using these products remain subject to their sectoral obligations, data protection, labor law, contractual requirements and, depending on the case, European AI law. A code published by Microsoft does not automatically transfer responsibility for use to either the provider or the customer: this allocation depends on the products, contracts, each party's roles and the applicable legal framework.

There is also a difference in timing. A company can quickly update a model's behavior, modify an interface or strengthen a filter after identifying a problem. Law generally evolves more slowly, because it must be debated, adopted, interpreted and applied. But this relative slowness is offset by another property: a legal rule can be enforceable and bind actors that would not spontaneously have an interest in adopting the same precautions.

Authorities and lawmakers cannot content themselves with general prohibitions either. As with internal codes, regulatory effectiveness rests on definitions, evidentiary mechanisms, competent authorities and credible sanctions. The difficulty is heightened by AI's cross-border dimension. A model can be developed in one country, trained on infrastructure spread across several territories, offered from an international cloud and used by a French organization in processes affecting European citizens. No corporate policy alone resolves this fragmentation.

The Microsoft case therefore illustrates a broader reality: the industry is moving forward both through self-regulation and under pressure from public frameworks. The former can accelerate the establishment of security practices. The latter seeks to establish a common foundation, including for companies that would not voluntarily adopt high standards. The essential question is whether these two dynamics reinforce each other or whether statements of principle serve to delay more precise obligations.

What French companies should examine beyond the text

For a French organization using AI services provided by Microsoft, the announcement should be read as a governance signal rather than an absolute guarantee. The fact that a provider states its models must not hack or deceive is relevant, notably for security, compliance and risk management teams. But it does not exempt the user company from assessing its own settings, access, data and the uses authorized for its employees.

The first question concerns the data entrusted to the tools. When an assistant can access internal documents, knowledge bases or corporate resources, the principle of least privilege remains essential: provide only the access necessary for a specific task. Security does not depend solely on the model's expected behavior. It also depends on the user's identity, available rights, segmentation of environments, the quality of authentication and traceability of operations.

The second question concerns the level of supervision. In organizations, the word “assistant” can cover very different uses. A tool that prepares a draft letter does not raise the same issues as a system that recommends a hiring decision, helps sort customer requests, produces a financial analysis or generates code intended for a production system. The greater the effects of an error, the more human control must be concrete, documented and entrusted to people able to challenge the result.

The third question concerns training. A promise not to deceive must not lead users to believe that answers are systematically accurate. Employees need to know that a generative system can be wrong, oversimplify or produce convincing content without sufficient assurance. They must also understand confidentiality limits, internal rules for sharing information and situations in which human verification or specialized expertise remains indispensable.

For cybersecurity teams, Microsoft's code of conduct calls for particular vigilance. The prohibition on hacking systems can reduce the risk that the tool will respond to certain clearly malicious requests. It does not eliminate the need for active defense. Attackers do not need a legitimate provider to give them access to every desired capability; they can use other tools, traditional methods or uncontrolled sources. Companies must therefore continue to monitor anomalous behavior, manage vulnerabilities, control access and prepare their incident response.

For French and European AI providers, Microsoft's approach may help raise market expectations. Customers will ask for more detail on prohibited behaviors, red-teaming procedures, incident reporting arrangements, retention of logs and access controls for sensitive functions. This requirement may represent a burden for smaller actors, but it can also become a differentiating factor: transparency about a product's limitations and governance can weigh in purchasing decisions, particularly in regulated sectors.

The issue of language and cultural context also remains important for the French-speaking market. Behavioral policies must work across varied wording, including in French, with its nuances, administrative references, professional uses and ambiguities. A security mechanism that performs well in English is not automatically as robust in every language. French users therefore have an interest in evaluating responses, refusals and alert mechanisms in their real use cases, rather than assuming that general principles translate uniformly into every linguistic environment.

Finally, publication of the code points to a responsibility for internal governance. Management cannot delegate to a provider the complete definition of what is acceptable in its organization. It must determine which uses are permitted, which data are excluded, who approves deployments, how errors are reported and when a tool must be disabled. Microsoft's code can provide a reference point, but it replaces neither an AI policy specific to the company nor a risk analysis suited to its business activities.

Credibility will depend on evidence, incidents and the ability to correct

The long-term perspective goes beyond the case of a single document published by Microsoft. AI models will continue to be integrated into software, workstations, online services and business processes. As their interfaces become more natural and their ability to use tools develops, behavioral principles will need to be translated into visible technical constraints. A code of conduct will have all the more value if it is associated with limited permissions, explicit validations, stop mechanisms and the ability to review afterward.

The decisive criterion will be verifiability. Users, customers, regulators and researchers will need to know not only what models are supposed to do, but also how the company assesses deviations. This entails tests involving hacking attempts, manipulation requests, circumvention scenarios and errors likely to create unwarranted trust. It also entails being able to measure improper refusals, which can penalize legitimate uses, and dangerous responses, which can facilitate abuse.

In a sector marked by intense technological and commercial competition, it will be difficult for companies to maintain credible limits if they are perceived as obstacles compared with more permissive competitors. This is precisely why common rules, transparency obligations and accountability mechanisms matter. A company can announce demanding principles; it will nevertheless face market pressure, customer demands and expectations around new features. Consistency between statements and deployment decisions will become a central indicator.

Microsoft's wording, as reported by TechCrunch, at least has the merit of explicitly placing two red lines in the debate: do not help compromise systems and do not seek to deceive people. It also recalls that AI must be designed as assistance, not as an autonomous authority devoid of supervision. These points do not constitute an easy technical consensus to implement; rather, they outline ground on which providers will have to be held accountable.

For France and Europe, the challenge will be to avoid two pitfalls. The first would be to treat corporate charters as sufficient substitutes for regulation and independent oversight. The second would be to ignore their concrete usefulness in the everyday design of products. Internal policies can quickly change behaviors and direct security investments. They become truly meaningful when confronted with audits, user feedback, legal obligations and the possibility of being publicly corrected.

The debate over a possible slowdown in the development of advanced AI will therefore not be settled by the publication of principles alone. It will continue to concern the pace of deployment, the level of autonomy granted to systems, the preparedness of institutions and the distribution of responsibilities when an AI fails. From this perspective, Microsoft's code of conduct is worth less as an endpoint than as a test: that of major providers' ability to prove that their stated limits withstand increasing capabilities, complex uses and competitive pressure.