AI security: 7 essential steps after Nadella's warning

An AI assistant that writes a first draft is one thing. An agent that can read customer data, change files and send information elsewhere is another. The moment we give the model tools, the quality of its answer becomes only part of the question. We also need to know what the system is allowed to do, how its actions are checked and who can stop it.

On 10 October 2026, Microsoft CEO Satya Nadella published the essay “Models as Insider Risks in the Super Intelligence Era”. His main point is that security controls must sit outside the model. This is a useful direction for the debate about AI security.

At the same time, his message comes just days after a series of Microsoft announcements about control, agent management and local AI. That gives us reason to read the text with both technical interest and commercial scepticism. For a Norwegian business, the key question is what these principles mean in practice: how do we use the technology without giving it more authority than the task requires?

This guide distinguishes between the documented statements, our assessment of them and practical suggestions for safer workflows. The practical examples are hypothetical situations, not accounts of events involving Kodemagisk's customers.

AI security

Here, AI security means keeping an assistant or agent within a clearly defined remit. The system should be able to help with the task, but its access to data, tools and actions must be limited and verifiable. A good answer is valuable. A good answer from a system with unnecessarily broad permissions can still be a poor solution.

This is particularly relevant when a business moves from asking a chatbot for advice to connecting AI directly to its own systems. A writing assistant can suggest a reply to a customer. An agent with email access can send it. An assistant can explain a code change. An agent with production access can make that change. The difference lies in the consequences of a mistake.

Security should therefore be assessed alongside the benefits. Ask what the task actually requires and what might happen if a misunderstanding turns into an action. A suggested blog headline needs a different workflow from a change to payment details. Both can use language models, but there is little reason to give them the same authority.

We recommend starting with a simple map: what information the system can read, what suggestions it can make and what actions it can perform. This map should be understandable both to the person commissioning the solution and to the person building it. If the description merely says that the agent “has access to the company's tools”, its remit is too vague to assess properly.

Why a language model needs different controls

It is tempting to say that conventional software is understandable while AI is a black box. The difference is more nuanced. Traditional software can also be complex, have many dependencies and be difficult to debug. Even so, a developer can often examine specific rules, state changes and the execution that led to a result.

A generated answer does not, in itself, offer equivalent insight into why the model chose that particular wording or action. A well-written explanation from the agent should therefore not be the only evidence that the task was completed correctly. Check the result against sources, expectations and the actual state of the systems it used.

Consider an agent that says it only changed a product description. What matters is which fields the content management system actually recorded as changed. An explanation can help an editor understand the suggestion. The change history provides a different, more concrete basis for checking it. When both are available, it is easier to spot a discrepancy before the customer sees it.

The point is practical: build controls around observable actions and clear permissions. A business does not need to understand every detail of a language model to require publishing, permission changes and other important operations to follow separate rules.

What Nadella actually calls for

Nadella proposes treating the model as a potential insider risk: it has access and capabilities, but should not be its own oversight mechanism. The essay describes model diversity, readable and tamper-resistant records, continuous verification, independent checks and audits, isolation and openness about incidents. He also discusses human responsibility and the ability of an authorised person to stop the system while it is running. Read the original essay on X.

This is an argument for controls around the model. Planning for the possibility that a model is compromised is a security assumption, not evidence of an actual attack.

Towards the end, he writes:

It will be the one that enables us to trust the model the least.

A robust system should therefore require as little trust in the model as possible. Source: Nadella.

Microsoft's tools: what is available now?

Microsoft published several relevant announcements on 7 October 2026. They cover different aspects of working with agents and have different availability statuses. The table presents the manufacturer's descriptions as they stood at our review on 12 October. It is not an independent test of the products.

The statuses come from Microsoft's technical MXC announcement, Windows announcement and Surface announcement.

MXC sets boundaries, but the configuration determines the outcome

Microsoft describes MXC as a layer that enforces access policies outside the agent's own control. The solution can restrict access to files and networks, among other resources. The documentation distinguishes between several forms of isolation and operating modes. One important detail is that “Permissive” records access that the policy would otherwise deny, but allows the operation to continue. “Learning” blocks and records it. “Enforcement” enforces the boundaries without this activity report. Source: Windows Developer Blog.

Our assessment: a business should ask for a demonstration of the actual configuration. A product name or an enabled report does not, on its own, tell you whether unwanted access is blocked. Ask the supplier to attempt an operation the agent should not be able to perform, and show the result in the target system. Supplement these restrictions with separate logging of important actions. This provides a concrete answer about what the setup protects and what still needs other measures.

HydraFusion routes tasks; it does not prove security

Microsoft and GitHub describe HydraFusion as an orchestrator that can select one or more models based on performance, cost and latency. The Windows extension is also intended to support local models; an experimental preview was announced for later in October. Sources: the technical explanation and the Windows announcement.

Our assessment: this kind of routing can be useful, but should be evaluated separately from oversight of an important decision. The ability to use multiple models does not tell you who checks the result, what data the check relies on or whether execution can be blocked. When a supplier uses terms such as “multi-model” in a security argument, ask for an explanation of the specific workflow and the failure cases it is designed to handle.

Surface Laptop Ultra: local capacity is one part of the picture

Microsoft states a suggested starting price of 2,599 US dollars and up to 128 GB of unified memory, depending on the configuration. Pre-orders opened on 7 October, with availability from 16 October. The maximum memory capacity is therefore not the same as what the starting price includes. Source: Microsoft Devices Blog.

Our assessment: running models locally may be useful when a business wants to control where processing takes place. But a local agent still needs a clear remit. If the workflow sends data through other tools or has access to folders it does not need, location alone does not solve the problem. Assess the data flow from start to finish before buying hardware to gain control. This is as much a question of architecture as of capacity.

When the security message also supports a business

It is reasonable to see a commercial connection between Microsoft's new tools and Nadella's security message. Control, agent identity, model orchestration and local capacity are both technical needs and areas in which the company wants to sell solutions. This is our editorial interpretation of the timing and content of the documented statements.

The essay does not name the products. We therefore have no basis for presenting it as a proven attempt to hide a sales catalogue. The stronger criticism is also more useful: sound security principles must be assessable independently of the supplier presenting them. A business should be able to ask for the same controls from Microsoft, other platforms or a custom solution.

That requires questions that can be answered through a demonstration. Can you stop a run without waiting for the agent to follow an instruction? Who can change its permissions? Which actions are recorded? What happens if the model encounters text encouraging it to go beyond its task? Which parts of the setup continue to work if you change the model?

It is also worth examining who checks the supplier's own claims. A salesperson can show a good example, and a developer can explain a thoughtful design. Both are useful. Before giving the system greater authority, however, the business should request tests that challenge the solution and ask someone who is not responsible for selling it to assess the findings.

A commercial interest does not make security advice wrong. It makes it necessary to separate the advice from the purchasing decision. Start with the risk you want to reduce. Define a measurable requirement. Then compare how possible solutions meet it. That way, the purchase is driven by the need, and a striking product launch does not define the entire problem in advance.

Amodei addresses another part of the same debate

The link to Dario Amodei's “We Must Pace the Frontier”, dated September 2026, leads to a different essay from Nadella's. Amodei proposes external evaluators with ongoing access, coordination between democratic countries and companies, and a broader attempt at global coordination. He argues that the pace of development must give safety work time to keep up.

Our assessment is that these perspectives can complement each other. One question concerns the controls around an agent used today. Another concerns how the largest models are developed and scrutinised. Norwegian businesses have limited influence over the latter, but they can set specific requirements for the solutions they adopt.

There is therefore little reason to wait for agreement on the direction of the entire AI industry before clarifying who can publish from the content management system, which customer data an assistant may read or how an automation is stopped. These choices are within the business's own control. The following steps are our suggestion for how to begin.

Least privilege: start with the task

OWASP describes “Excessive Agency” as a risk associated with excessive functionality, overly broad permissions and too much autonomy. Among other measures, the project recommends human approval for important actions and enforcing permissions in the systems the agent uses. The recommendations below make these control needs concrete through our own hypothetical workflows.

Give an AI agent only the access it needs for a specific task. This limits what can go wrong when the agent misunderstands an instruction, uses incorrect information or is influenced by content it reads. A good description of the desired behaviour is useful, but access rules must be enforced by the system around the model.

Start with a simple question: what should the agent actually do? Summarising an order requires different access from changing the delivery address. Writing a suggested blog post requires different access from publishing it. If every task receives the same broad access, the business loses the ability to control their consequences separately.

Imagine an online shop testing an agent for customer service. This is a hypothetical example. The agent should find an order's status and suggest a reply to the customer. It may need the order number, delivery status and relevant product information. It does not need the entire customer database, payment information or the ability to issue refunds. A restricted tool that retrieves one specific order establishes a clearer boundary than general database access.

Also clarify which customers, documents and workspaces the agent may access. Access to one customer's case should not automatically give it access to all other cases. The system must check the user's permissions whenever the agent requests information. The model should not decide whom a request belongs to or which permissions the request grants.

This aspect of AI security often involves making existing access management more precise. Write down the permitted actions, expected data needs and actions that require a person. This gives both developers and those responsible within the business a concrete basis for assessing whether the access is appropriate.

Separate reading, suggestions and actions

Divide the workflow into stages with different permissions. The agent can first read selected information, then produce a suggestion and finally ask a separate system to perform an approved action. Do not let a successful reading stage automatically open the door to publishing, payments or changes to customer data.

Read access is not risk-free either. Information can be sent elsewhere if the agent can also use external services, send messages or open arbitrary web addresses. Assess access to information alongside the ability to send it out. An agent producing internal summaries rarely needs unrestricted permission to send content to external recipients.

For a developer, this may mean building small tools with clear parameters. A tool for suggesting a refund can return an amount and a reason without moving money. Another tool can carry out the refund after the necessary checks have passed. Check amount limits, the recipient and the link to the order in conventional code, even when the model supplies a convincing suggestion.

Make the transitions visible to the user. A suggestion saved as a draft should appear as a draft. A button approving a message should show what will be sent and to whom. If the user thinks the agent is only writing text while it is also changing the system, the workflow is difficult to control.

Choose the degree of automation according to the consequences. A limited classification task can often run automatically when errors are easy to detect and correct. An action affecting money, access or a customer's rights needs stronger controls. The aim is a clear connection between the task, the permission and the consequence.

Isolation that limits damage

Run the agent in a restricted environment with controlled connections to the rest of the business. This makes it easier to limit the consequences of mistakes and stop a task without disrupting everything else. Isolation should cover the workspace, tools, network access and information the agent can use.

A separate environment provides little benefit if the agent also receives keys with extensive access to production systems. Look at the entire chain. Which files are accessible? Which services can the agent contact? What actions can its tools perform? How long does access last? The boundaries must hold in practice, even when the model asks for something else.

Imagine a coding agent fixing a bug on a website. In this hypothetical example, it can work in a separate copy of the project, read relevant files and run agreed checks. It receives no production keys and no permission to deploy the changes. The result is a change the developer can inspect and test before it affects customers.

A publishing system can use the same principle. A content agent can write to a specific draft and upload an image, while publishing requires a separate permission. This restriction should exist in the tool or publishing platform. An instruction to remember not to publish is not a technical access boundary.

Also limit the time and resources the agent may use. Set limits on task duration, number of tool calls and cost where relevant. A task that goes round in circles should be able to stop in a controlled way. The business needs an understandable result even when the agent fails: what was done, what remains and which changes already exist.

An emergency stop that actually works

Create a way to stop the agent that works without the model's cooperation. A cancel button in the interface is useful, but it must be connected to the controls governing execution, access and actions. Otherwise, the user may believe the work has stopped while a background task continues.

Define what stopping means in the specific workflow. Should new tool calls be blocked? Should pending messages be held back? Should temporary access be revoked? Should a running job be terminated? Different systems need different mechanisms, but the consequence must be clear to the person pressing the button.

An emergency stop cannot undo every previous action. An email already sent cannot normally be treated as though it was never sent. That is why it is important to distinguish between stopping further work and correcting what has happened. Show which actions have been completed and which are still pending.

Appoint someone responsible for using the stop function and following up afterwards. In a small business, this might be the same person responsible for customer service or the website. They need short, accessible instructions explaining how to stop the run, where to find the event log and how to identify affected tasks.

Test the stop function before the agent works independently. Start a harmless test task, interrupt it midway and check that new actions are actually blocked. Also test a task with queued actions. An emergency stop is part of operations and must work when the rest of the workflow is difficult to follow.

Logs that stand up to scrutiny

Record important actions outside the model's own control. This kind of log makes it possible to investigate what the system actually did, which tools it used and which approvals it received. The agent's own summary can help with readability, but should not be the only record of events.

Start with the questions you may face after a mistake: which task was active? Who started it? What information was retrieved? Which tool changed the order? Who approved the message? What response came from the service receiving the request? Log structured events that make these questions answerable.

Link the events to a task and use clear timestamps. It is often useful to record which model and tool versions were used, along with the results of access checks. If an action was denied, that should also be visible. A series of successful events alone tells you little about whether the agent also attempted something it was not allowed to do.

Imagine a customer service agent suggesting a delivery address change in a hypothetical online shop. A useful log shows the request, proposed change, check of the customer's access, any approval and the result from the order system. An agent's statement that the address was updated does not document that the order system actually accepted the change.

The logs must also be protected against unauthorised changes and deletion. The agent performing the task should not be able to edit the record of its own actions. Choose a storage setup that makes relevant changes traceable. At the same time, remember that a log describes observable events; it does not necessarily provide a reliable explanation of the model's internal reasoning.

Protect the information in the log too

Log what is needed for oversight and troubleshooting, and avoid collecting sensitive information without a clear reason. Otherwise, a log can become an additional collection of customer data, internal documents and secrets. Recording everything indiscriminately can make a problem harder to handle.

Distinguish between documenting an action and copying all of its content in full. For some events, it is enough to record the order reference, action type and result. Other investigations may require more detail. Assess the need in advance, and apply access controls to those who can read the logs as well.

Pay particular attention to tool parameters and error messages. They may contain access keys or other information that should never appear in an ordinary operational log. Masking should happen before data is stored. Do not expect the model to consistently recognise and remove every secret from its own description.

Define who can read which information and how long you actually need it. Customer service may need an overview of the actions in one case, while developers need technical error codes. This does not mean everyone should have access to the entire conversation or every document the agent used.

Check the logs with realistic test data before putting the solution into use. Can you follow a task from start to finish? Is the error understandable? Is there information that should not have been stored? Good AI security requires both traceability and limits on information. Logs should help the business investigate an incident without creating unnecessary access to more data.

Multiple models can help, but also share blind spots

You can use an additional model as a check, but assess the result against specific requirements and external sources. Two models that agree can still be wrong. The value lies in how the check is designed and which errors it actually detects.

An additional model might, for example, check whether an answer lacks source references, whether a suggestion exceeds a stated amount limit or whether a text contains claims requiring evidence. That is more useful than asking the model for a general assessment of whether everything looks fine. The clearer the checking question, the easier it is to test the check with known errors.

However, the models may share assumptions, knowledge gaps or vulnerability to the same content. If both receive a document containing a hidden instruction, both may be influenced. If both assess incorrect order data, agreement does not solve the problem. Multiple models therefore offer no automatic guarantee of independence.

In a hypothetical content management system, one model might write an article and another flag unsupported factual claims. This can help the editor identify passages needing verification. The editor must still open the relevant sources and examine what they actually say. A checking model that invents a source can otherwise make the text more convincing without making it more accurate.

Use conventional system checks when a requirement can be expressed precisely. Amount limits, permitted recipients, required fields and access rules can often be checked directly. Models can then handle tasks requiring linguistic judgement, while clear boundaries are enforced predictably. Choose the combination according to the risk and cost of the specific workflow.

Human approval must be specific

Give the person approving an action enough information to understand it and its consequences. Approving a vague plan is a weak control point. The same applies to a button labelled “continue” when it is difficult to see what the agent will do next.

Show the specific action: recipient, content, amount, document or change. For code changes, the developer should be able to inspect the diff and see relevant test results. For publishing, the editor should see the text, image, sources and page to be updated. Do not put the entire assessment burden into a long conversation history.

Approval must be tied to the suggestion the person actually saw. If the agent later changes the recipient or content, the system should require a new assessment when the change is material. Otherwise, permission for one action can be used for another.

At the same time, avoid requesting confirmation for every insignificant operation. Too many interruptions can turn approval into a habit without meaningful consideration. Place checkpoints where a mistake would have noticeable consequences, and use clear limits for smaller actions that can run automatically.

Also clarify what happens when no one responds. A deadline is not the same as approval. An agent waiting for permission to send a customer message should not interpret silence as consent. Show that the task is waiting, and give the responsible person a simple way to reject or change the suggestion. Human oversight works best when the person has visibility, time and the ability to intervene.

Test the system throughout its life

Test the agent's actual workflow before use and after changes. The model, instructions, tools and data sources work together, so a good language model alone tells you little about the safety of the whole system. A test should check both the result and the route the system took to get there.

Create a small set of representative business tasks. Include routine cases, unclear instructions, missing information and situations where the agent must stop. Describe in advance which actions are permitted, what a good result involves and which events should appear in the log. This makes the assessment more concrete than simply deciding that the answer seems reasonable.

Pay particular attention to whether the agent respects access boundaries. Can it retrieve another customer's order? Can it publish a draft without the correct permission? Can it send information to an unapproved recipient? These checks concern enforcement by the system, not just what the agent promises in its text.

Repeat relevant tests when you change the model, instructions, tools or integrations. An update can affect which action the agent chooses and how it handles errors. Record which versions the tests covered, so a previously approved result is not used as evidence for a different solution.

Monitor normal use as well. Look for stalled tasks, unexpected tool calls, denied actions and user feedback. Choose specific signals that someone is responsible for following up. AI security becomes part of operations when the business can detect changes in behaviour and adjust boundaries before problems grow.

Test failure cases before customers encounter them

Test what happens when assumptions fail. A service may be unavailable, a response may be incomplete or an action may be carried out even though its confirmation never arrives. The agent must handle these situations without inventing a successful result or carelessly repeating a sensitive action.

In a hypothetical order system, a refund may be completed while the request times out. If the agent immediately tries again without checking the status, the same refund could be issued twice. The tool should be designed to handle repeated requests for the same action in a controlled way. Also test how the agent explains the uncertainty to the responsible person.

Try content that attempts to give the agent new instructions. This might be an email, web page or document asking the system to ignore previous rules or send information elsewhere. Such data must not automatically receive the same authority as the business's instructions. Examine both the model's response and whether the tools continue to enforce the boundaries.

Include missing approvals, interruptions midway and tasks that end with partial changes. Can the business determine what remains? Can a person take over without repeating work already completed? A clear partial result is often safer than the agent continually trying new ways to finish.

When a test uncovers a mistake, keep it as a new check in the test set. Fix the weakness and test the affected workflow again. The goal is not to prove that the agent can never make a mistake. The goal is to know which boundaries are enforced, how errors are detected and who can take over when automation is no longer appropriate.

A practical starting point for Norwegian businesses

Start with a task you can describe and measure. “We will use AI” is too broad. “We will receive suggested answers to questions about delivery times, based on approved information” is specific. This makes it easier to choose the data sources, restrict access and find someone who can actually assess the result.

A small pilot can be built around these seven steps. This is our practical prioritisation, not a verbatim reproduction of Nadella's list:

• Clarify the task, data and minimum necessary access.
• Separate suggestions from actions in other systems.
• Isolate execution and test that the emergency stop works.
• Record important actions independently of the agent's explanation.
• Use checking models where they add value, and give people a clear basis for decisions.
• Test misunderstandings, manipulated input and changes to the setup.
• Arrange an independent review and a plan for handling incidents.

Choose a workflow with a natural stopping point before it affects the customer. A content draft is a good example. An editor can review the text, check sources and decide whether to publish it. The system does not need publishing permissions to contribute to the work. This boundary makes the pilot's consequences easier to understand.

Also define what you want to learn. The pilot might establish whether the assistant finds the right information, asks for help when the evidence is missing and saves the specialist time once checking work is included. Record where it creates extra work. If a suggestion appears quick but takes a long time to correct and verify, that is important information for the next decision.

It is sensible to include the people who will use the solution. A developer can demonstrate that an access rule works, but a customer service representative knows which phrases may create expectations the business cannot meet. An editor knows which sources need examination. An operations lead knows who can actually respond when something stops. Security becomes more concrete when these perspectives address the same workflow.

What must be in place before the agent gets more responsibility?

Write acceptance criteria before considering broader access. A criterion should describe both the expected result and what should happen when the system cannot deliver. “The answers seem good” is difficult to check. “The suggestion uses approved delivery information and flags when it is missing” provides a clearer basis.

For a hypothetical customer service pilot, you could require the assistant to read only the relevant case, prevent a reply from being sent without approval and reject all attempted changes outside its remit. It must also be possible to retrieve which suggestion was approved, by whom and based on which data. The specific list should be adapted to the task and the business's risks.

An independent review needs a defined scope. Ask the reviewer to examine permissions, the stopping procedure and specific test results. The review should make clear what was examined, what was not examined and which assumptions underpin the assessment. A vague “approved” stamp is less useful than a precise description of findings and limitations.

Also create a simple incident procedure before you need it. Decide who can stop the agent, who checks whether other systems are affected and who decides whether to resume operation. Preserve relevant records. Distinguish between stopping new actions and dealing with what has already been done. If a message was sent incorrectly, stopping the model does not unsend it.

During an incident, the responsible person should gather confirmed information: what was done, which data or people may be affected and which measures have actually been completed. Communication must be based on what has been investigated. An agent-generated explanation alone is not sufficient grounds to declare the system safe. Any notification requirements must be established according to the specific situation and relevant agreements and rules.

Expand the remit one step at a time. If you later want to allow messages to be sent, first test a small, clearly restricted category of messages. Keep previous test cases and run them again after the change. This lets you see whether the new benefit actually outweighs the new risk and whether earlier boundaries still hold.

A pilot succeeds when the business has a better basis for making a choice. This may mean expanding the solution. It may also mean keeping it as an assistant, changing the workflow or ending the trial. All three are sensible outcomes when the decision is based on observed results and clear needs.

Frequently asked questions about AI security

Is Nadella saying we cannot use AI?

No. The essay advocates stronger control around the models. Our practical recommendation is to assess each use according to its task, access and consequences. An assistant suggesting wording does not need the same authority as an agent that can change customer data. Read Nadella's original text.

It is therefore better to ask a specific question than to choose between total trust and total rejection: what can the solution do if it is wrong? If the answer is that it only creates a draft for a person to review, the risk is different from a system that performs irreversible actions itself. The workflow around the model determines much of what the business should require.

What does treating a model as an insider risk mean?

It means planning for the possibility that an actor with access may make a mistake or be influenced to exceed its remit. A practical way to apply this idea is to restrict access, check important actions and ensure others can investigate what happened. This does not require a claim that the model has human intentions.

Consider an assistant helping with one customer case. It should receive the information needed for that case. It does not automatically need access to the whole customer database. Security then becomes a question of authority and consequences, which the business can examine without having to determine what the model “really wants”.

Is an additional model enough to check an important decision?

An additional model can raise useful questions or identify discrepancies, but the number of models is not proof of quality. The check must rely on relevant sources and a correct understanding of the task. If both models receive the same incomplete information, they may arrive at the same mistake.

We recommend using models to assist with checking while retaining clear rules for actions with major consequences. Show the responsible person what will be done, what information the suggestion relies on and which changes it will cause. An approval button has limited value if it hides the basis for the decision.

Is an agent safe if the model runs locally?

Local execution describes where the model processes the task. On its own, it says nothing about which files, networks or other systems the agent can use. In our assessment, local execution must therefore be considered alongside permissions, tools and data flows.

A hypothetical local assistant might, for example, have good control over the model's execution while using a tool that sends a document to an external service. The business must assess that transfer separately. Start with an overview of the whole workflow: retrieval, model processing, tool calls, storage and any transfers. Location is one characteristic of the solution; it does not replace this mapping.

Are Microsoft's announced agent features already available?

Their statuses differ. Our review is dated 12 October 2026; the statuses and links are listed in the product table earlier in the article. Use it as a starting point, and check the current documentation before planning an implementation. Product plans and actual availability can change.

Also request information for your specific setup. A feature may be presented in a broader launch without being fully available for every platform, customer or workflow. Asking for a demonstration of the feature you will actually use, and clarification of which parts of the delivery depend on future updates, is a useful purchasing question.

Where should a small business start with AI security?

Choose one limited task, a named person responsible for it and a natural stopping point before an important action. Use a restricted set of data. Test routine cases as well as situations where information is incomplete or contradictory. Also examine what the system does when it attempts to use access it does not have.

Measure the result after accounting for checking and corrections. A small business needs an understandable answer about whether the solution helps, who oversees it and how to stop it. Then expand only the parts with a clear justification. This makes both the investment and responsibility easier to manage, and provides more useful experience than a large project with unclear authority.

Conclusion: trust must be verifiable

Nadella's statement offers an opportunity to ask better questions about the agents we adopt. Those same questions should accompany the entire purchasing and implementation process: what task does the system solve? Which permissions does it need? Who checks important actions? How do we detect and stop a deviation?

It is possible to be interested in AI while requiring clear answers. A model can provide useful suggestions even if we do not give it access to perform every action it proposes. This allows the business to gain experience and value within boundaries it understands.

The commercial security message should be assessed with the same clear judgement. A product may be useful, but its value lies in the controls that actually work in your workflow. Ask for demonstrations, document the limitations and give the responsible person a real basis for making a decision.

For Kodemagisk, the practical direction is clear: start with the need, build in the boundaries and expand based on observed results. If you are considering an AI assistant for a website, customer portal or internal workflow, a good first conversation can focus on the task and its authority. See how we work with web applications and internal tools, or contact us to discuss your needs.