AI Security

Saunier opens with the figure that 90 per cent of AI-generated prototypes never reach production and immediately declines to treat it as a problem, saying it is for good reasons. That is the right starting position and rarer than it should be. The failure he describes is structural rather than careless: generating a working application is fast, while everything that makes one safe to expose — authentication, access control, secret handling, tenancy — is not part of what gets generated because it was not part of what was asked. An engineer building by hand meets those questions as unavoidable steps; generation skips them, and their absence is invisible in a demonstration. His alternative is guardrails and templates with platform primitives already present, which matters because an agent cannot forget something it is not responsible for. Prompts are advice; templates are structure, and only one survives a model having an off day.

Microsoft Build

The session opens with an analyst projection that over forty per cent of agentic projects will be cancelled by 2027, and the diagnosis offered is the useful part: none of these are model problems, they are runtime problems. Two failures make the case. An agent that restarts loses context, cache and intermediate state and pays the setup cost again, which turns a restart during a long-running task into total loss of accumulated work exactly when the value is highest. And an agent running as trusted code on a developer's machine inherits that environment — SSH keys, browser cookies, everything — which is the arrangement most agent development actually uses and does not survive a process running unattended against a prompt someone else influenced. The reframing is testable against the failures people describe, none of which are failures of intelligence.

Microsoft Build

The chart organising this session is not about productivity. It shows roughly three times more issues arriving and considerably more open pull requests since January, which is the honest shape of a successful agent rollout and almost never the number presented. The team's response was to move from monthly to weekly releases, a change forced by throughput rather than chosen for confidence. Their code-survival metric — the share of a model's output that actually gets committed — is unusually well chosen because it is measured after the human decision and so cannot be inflated by generating more. The most transferable practice is running the editor with and without a change and attaching the comparison to the pull request, which turns the pull request into the specification. They also state plainly that running AI over community-submitted issues means running it on untrusted input, without detailing the mitigation.

Microsoft Build

The finding that contradicts how most teams deploy AI assistance is stated almost in passing: the tenfold return arrives where an engineer is weakest rather than strongest, so someone without a security background suddenly shows a better security posture. That reverses the usual rollout order, which gives these tools to the strongest engineers first on the theory that leverage compounds on capability. It also creates a verification problem, because the reviewer most likely to be assigned shares the same gap. The speaker who previously ran the foundation behind Kubernetes brings a specific scepticism about lock-in, framed as this era already reproducing the last one's portability and cost-control problems — though the sharper observation is that context held in implicit memory or a conversation window has no export format at all. Their overnight scheduler blocks only for architectural decisions, which is a well-drawn line with no one watching it.

Microsoft Build

Most of this session is a platform tour. The part that will still matter is a taxonomy of three agent identities and the fact that capability is gated by which one you choose rather than by which model you use. An assistive agent extends the person operating it and inherits their access; an autonomous one runs in the background with permissions granted directly on cloud resources, and loses the tools that were previously reached through a person's identity; the third has its own account, alias and ability to act on its own behalf. That progression is an administrative commitment rather than a capability upgrade, which is why the last tier requires approval through an administrative console. The harness abstraction supplies tools and context compaction without extra work, and the demo's own network failures illustrate the operational character of these systems better than the architecture slides do.

Microsoft Build

What generalises past the products is where agents get their reach: connectors for mail, chat, drive, calendar and contacts, with search across them. That list is the substance, because an agent with access to a person's calendar, correspondence and documents can do work another cannot — not by reasoning better but by knowing things. The example offered is ordinary and the shift underneath is not: the value of a meeting summary is not the summary, it is that attending stops being the only way to know what happened, which changes the calculus of every scheduling conflict. The uncomfortable part is that the connector list is simultaneously the product and the risk surface. An agent that can search mail to answer a question can search mail to answer a question it was manipulated into asking, and the permission model governing a person was not built for that.

Google I/O

Pichai's framing of Google as the buffer between people and the raw internet is offered as continuity — search did it, browsers did it, agents do it more — and it is also the most contested claim in the industry, because a buffer decides what passes through. He reaches immediately for the counterweight, the connection people feel to creators they follow, which is precisely the tension the company is currently managing without resolving. Two answers are sharper than the format usually produces. On competition he describes participants running on different pre-training and release cadences rather than at different speeds in one race, which is a more honest account than the leaderboard framing and comes from someone with an interest in leaderboards. On security he acknowledges models improving at cyber work, which is the one domain where better capability does not obviously net out positive, since an attacker needs one vulnerability and a defender needs all of them.

Google I/O

The most honest moment here is an aside about how the presenters have tracked their own projects: plans in documents, plans in spreadsheets, plans in bug comments, and once a plan written on a receipt. That describes the actual category being addressed — not software nobody has built, but the small internal tool every team improvises badly because building it properly was never worth the effort. The demo turns on a single question: the generated app is strictly single player, so what happens when you want to share it with the team? That boundary is where improvised tools historically died, because it is where accounts, shared storage and access rules begin. Here it is crossed in one step, with the access rules generated and deployed automatically — which is convenient, and is also the moment the application acquires obligations nobody reviewed.

Google I/O

The most consequential sentence here concerns what happens after the demo: sometimes you want a quickly assembled application as a proof of concept, and other times you want it to stick around with real users and persistent data. The security additions are best read as answers to the failure modes that creates — keeping prompts off the client, restricting model access to the application, rate limits preventing a few users consuming everyone's quota, ignoring prompts arriving from the client. Each assumption being corrected is one a rapidly built application makes by default, harmless in a demonstration and consequential the first day it is public. The claim that strong security rules were written by the agent deserves the most scrutiny, because an overly permissive access rule produces no visible symptom — it works fine while allowing access it should not.

Google I/O

The claim most likely to matter here is about data rather than computation. The measurements behind modern structural biology began accumulating in the 1970s and took roughly fifty years of painstaking work to become the database that made the protein-structure breakthrough possible — and a quantum computer could produce valuable training sets where collecting them experimentally is impractical. That inverts the usual framing, because a dataset does not need a fully error-corrected machine: it needs to be produced once, correctly, and then has permanent value. The technical status report is specific, with coherence times improved roughly tenfold and the remaining obstacles described as system-level engineering rather than physics. The most actionable statement concerns cryptography, where an algorithmic result rather than hardware progress moved the timeline inward.

Google I/O

The fact that makes this session difficult is not that the scam compounds are hidden but that they are known. International law enforcement knows their street addresses, because hundreds of survivors have said so and digital traces corroborate it — four or five hundred facilities across three countries that stole between 50 and 85 billion dollars in a single year. This is not a detection problem. The strongest argument made is that the captive workforce is the operation's weakest link rather than merely its cruellest feature, because thousands escape and can describe who is doing this, where and how. The proposed lever is deliberately modest: international physical inspection of five or six facilities rather than all of them. The structural diagnosis is about tempo, and synthetic media widens the asymmetry further.

World Economic Forum Annual Meeting

The framing statistic is organisational rather than technical: around eighty per cent of organisations expected to have platform engineering teams going into 2026, up from about forty-five per cent a couple of years earlier. The interesting part is the doubling. The problem described is teams solving the same problems separately, producing inconsistency and redundancy — dangerous not because of duplicated effort but because each independent solution has its own security properties, and the organisation's real posture is the weakest rather than the average. The most valuable content is that two financial services organisations went in diametrically opposite directions on workload identity and both are described as working, which implies the choice is determined by context rather than by a general answer. The honest note follows immediately: even with standardised patterns the result remains fragmented.

AWS re:Invent

Buried near the end is the most useful sentence in the session: three agentic products are in production, one is about to launch, and one was taken back to the drawing board — and that last one produced some of the most valuable data the team got. The technical argument builds toward verification, starting from a limitation rather than a capability: traditional testing only goes so far because these models are probabilistic, which quietly invalidates most of an enterprise QA apparatus. Their answer is to measure properties rather than check outputs, tracking relevance, completeness and tone while noting other organisations will need different measures. The distinction between hard and soft guardrails clarifies the design question of how much safety requirement can be pushed into a deterministic layer, and their red-teaming runs as a schedule rather than a gate.

AWS re:Invent

The example that makes this session concrete comes from medicine: a nurse who sees a physician about to administer the wrong medication and, in an environment where speaking up carries risk, does not. Nothing about the nurse's competence was the failure — the information existed in the room and did not move. Security work makes this worse, because the cost of a missed signal is delayed and the person who spots it is often junior to the person who would be contradicted. The anxiety zone described — real pressure to deliver with no safety to contribute — is a fair description of an organisation during an incident, which is exactly when information most needs to travel. The four-stage model localises the failure so a leader can tell which intervention is needed, and the reframing of reversible decisions separates mistakes that deserve a penalty from those that do not.

AWS re:Invent

Beer names the constraint that makes key management genuinely hard, and it is not the mathematics: the key at the top of a hierarchy must be in plain text at all times for the system to stay available. Everything below can be encrypted by something above; the root cannot, or there is nothing to start from. The threat model that has moved from theoretical to planning-relevant is harvest now, decrypt later — capture encrypted traffic today, decrypt it when capability arrives — which means the exposure is to everything transmitted now rather than to a future secret, and inverts the usual reasoning about when to migrate. The strategic argument is about delegation, and it is a vendor's argument that happens to be right: cryptographic agility is not something most organisations can retrofit, because the assumptions live in code written by people who have left. One remark connects the session to the rest of the conference, on certificate infrastructure built for a countable number of endpoints.

AWS re:Invent

The most honest moment in this session comes near the end: most of the security processes the team has automated still route their output to security engineers rather than the business, because the results are not good enough. That sits half an hour after a story about two engineers building a working prototype in two days that runs a training exercise in seven minutes for ninety-one cents. The gap between the two is the subject. What distinguishes them is not model capability but whether the task has a verification loop a machine can close, which reframes the automation question entirely. Three loops appear — citation, self-checking, and a compiler pass that guarantees syntactic validity — and only the last removes a person. The rejection of single-number evaluation scores in favour of precision and recall follows directly, because in security the two error types have wildly different costs.

AWS re:Invent

The number in this session's title is a triage improvement. The story underneath is that the queue being triaged should never have grown that large, and what fixed the root cause was not AI. The diagnosis is candid: it was easier to obtain an exception than to fix the problem, partly because application teams did not know how to fix certain vulnerabilities — not bad developers, simply not security engineers. That produces a self-reinforcing failure where a better scanner makes things worse, because more findings enter a pipeline limited by developer capability. Average false-positive review time falling from thirty days to thirteen is real and is a faster way to process the symptom. The durable change is a tiered security champions programme whose second tier exists to verify the first, anticipating the incentive that delegation creates.

AWS re:Invent

The session opens by dismantling the reassuring version of its own subject: you put a box around the workload, secure it, call it confidential computing, and the problem is solved — which is why the presentation exists. The gap comes down to one question: how do you know the code you are talking to is the code that is running, rather than taking someone's word for it. A protected environment addresses operator access but not the customer's actual objection, which is that they cannot confirm any of it. Attestation converts the claim into a signed measurement, and the step that turns evidence into a control is a key policy permitting operations only when the environment matches. Trust becomes arithmetic rather than process, with no reviewer to convince and no exception to grant, which is what allows a model owner and a data owner to collaborate without trusting each other.

AWS re:Invent

The design decision at the centre of this session is one most teams get wrong: rather than assembling a large context and handing it to the agent, extract what actually matters from the conversation. That is the difference between a longer window and a memory — one holds more, the other decides what is worth holding. The instinct to add room fails invisibly, because an agent with an enormous context does not attend to all of it equally. The most instructive moment is an admission that the identifier for whose memory this is happens to be hardcoded, and should instead derive from who is logged in. Trivial in a notebook and the entire security model in production, since memory is per-actor by construction and the wrong binding produces an agent that recalls someone else's details — a breach that presents as good service.

AWS re:Invent

Twenty-nine minutes after asking whether anyone really wants to hand production keys to an agent, the demonstration disables tool confirmation entirely. That is not hypocrisy — approving every call would be unwatchable — but the gap between the stated concern and the working configuration is the one every team will meet. The scope makes it concrete: the example prompt blocks network addresses and creates snapshots, which are write operations on production initiated by a chain of reasoning that started as a sentence in English. The design response is decomposition, and the split between an investigating agent and an acting one is where a permission boundary can sit. The construction itself is genuinely simple, and the generated report of 859 critical findings is both the session's most useful artefact and the place the trust question returns in a form nobody can check by hand.

AWS re:Invent