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 precisely why the presentation exists (2:20).
The gap between that summary and the reality is the whole talk, and it comes down to one question: how do you know the code you are talking to is actually the code that is running, rather than taking someone's word for it (6:29)?
Why the box is not enough
The starting problem is ordinary. A customer has data sensitive enough that they will not send it to you (1:24). A protected execution environment addresses the technical exposure — operators cannot reach inside — but it does not address the customer's actual objection, which is that they have no way to confirm any of it.
Assurance that arrives as a claim is not assurance. The customer's position is unchanged: they are trusting you, just with more architecture diagrams.
Attestation is what converts the claim into evidence. The environment produces a document identifying what was running in that instance, at that moment, in that configuration (9:15) — a measurement, cryptographically signed, that anyone can compare against the code they expected.
The mechanism that makes it enforceable
The step that turns evidence into a control is the key policy: operations on a key are permitted only when the environment matches the expected measurement (10:08).
That is the elegant part and it deserves stating plainly. The protection is not that someone checks the attestation and decides to proceed. It is that the wrong environment cannot decrypt the data at all, because the key management service will not perform the operation.
Trust becomes a matter of arithmetic rather than of process. There is no reviewer to convince, no exception to grant, no step someone can skip when a deadline approaches. Either the measurement matches or the data stays encrypted.
The bootstrapping problem the session raises is the reason this design is necessary. If you need a secret inside the environment and you seed it at launch, it may effectively be public, because anyone who can inspect the launch can obtain it (7:50). Attestation-gated key release is the answer: the environment proves what it is first, and only then receives what it needs.
The two-sided case
The most useful illustration is a collaboration where both parties have something to lose. A model owner worries about weights being extracted; the party supplying the data worries about their data (24:16).
Conventionally one side must trust the other, which is why these arrangements usually collapse into contracts and audits. With attestation, neither has to. The weights are published encrypted with envelope encryption before being handed over (27:28), the data is supplied the same way, and both keys unlock only inside an environment whose measurement both sides have approved.
Neither party trusts the other. Both trust the measurement, which is a considerably easier thing to agree on than trusting an organisation.
The practical costs
The session is honest about what this demands.
The isolated environment is ephemeral and typically has no persistent storage, and it depends on a parent application to function (22:02). That constrains what can be built inside one — anything requiring state has to keep it elsewhere, encrypted, and re-establish it on each launch.
The treatment of private code is the neatest consequence: if you need code nobody should see, encrypt it and treat it as data (11:06). Code and data stop being different categories once the boundary is drawn around execution rather than around storage.
And the wry aside that the first feature launched is in some ways the more complicated one (17:30) is the honest note about adoption. The setup is described as usually worth it (22:02), which is a fair way of saying it is not trivial — and the whole approach only makes sense when the alternative is a customer who otherwise will not share their data at all.
演讲章节
关键要点
- 01
The framing question is how you know the code you are talking to is actually running, rather than accepting an assurance. 6:29
- 02
An attestation document identifies what was running in that instance at that moment, which converts a claim into checkable evidence. 9:15
- 03
A key policy permits operations only when the environment matches the expected measurement, so the wrong environment simply cannot decrypt. 10:08
- 04
Seeding a secret at launch risks making it effectively public, which is why attestation-gated key release exists at all. 7:50
- 05
A model owner fearing weight extraction and a data owner fearing exposure can collaborate without either trusting the other. 24:16
提及的实体
相关演讲
The practical counterpart to the argument made elsewhere this season that specification is what contains model entropy. Raval and Harris name the failure they are addressing precisely — a prompt-and-pray loop in which working code arrives with no record of what the model assumed, which requirements were fuzzy, what design was chosen or why, leaving nothing to review and nothing to iterate against when a defect surfaces months later. Their answer is three committed markdown artefacts: requirements written in a structured requirements syntax with acceptance criteria attached to each user story, a design document carrying technical decisions together with the reasoning behind them, and a task list whose entries cite the requirement numbers they satisfy. The traceability is the point — a reviewer questioning a decision in a pull request can follow it back through the task to the design to the requirement, all in the same repository. Notably they keep the human between each phase rather than after it, with the agent surfacing ambiguity as questions before proceeding.
Drawn from a year of engagements with more than a hundred companies, this is the most direct challenge in the season's programme to the assumption that faster code generation produces faster delivery. Mishra and Raja open with external evidence rather than their own: an industry study putting realised velocity gains in the ten to fifteen per cent range, and a controlled experiment in which developers using AI estimated themselves roughly a fifth more productive while measurement showed them a fifth slower. Their diagnosis is that both prevailing working styles fail for opposite reasons. Handing an ambiguous problem to an agent and awaiting a finished result produces a volume of code the developer must nonetheless sign for and cannot confidently review, so it stalls before production. The senior engineer's alternative — decomposing the work personally and inserting AI into narrow slots — keeps the intellectual load exactly where it was, and leaves the surrounding process untouched, so hours saved in editing are consumed by the meetings that process still requires.
Brooker builds the definition from the bottom up rather than asserting it, using a deliberately absurd arithmetic task to separate three categories: what a model computes reliably as a fixed function of its input, what merely needs to arrive in the system prompt, and what genuinely requires reaching into the world. Only the third category justifies a tool, and the distinction matters because most production disappointment comes from tools built for the first two. His working definition follows — a system given a goal that loops between inference and tool calls until it reaches one — with the observation that modern agents increasingly embed code in their definitions, not for expressiveness but because replacing inference steps with deterministic code improves reliability while lowering both latency and cost. The remainder covers what production actually demands around that loop: somewhere to run, memory that persists preferences, a gateway to internal and external tools, evaluation, and formal methods applied to policy.
The most concrete attempt this conference season to answer a question the agentic coding sessions mostly leave open: if commit counts and hours saved are the wrong measures, what replaces them? Otto's account is unusually specific about why the obvious alternative fails — summing the small time savings a platform team delivers produces figures exceeding a hundred per cent of a developer's time, and a minute returned is not code in production. Their replacement borrows from Amazon's retail supply chain, where cost to serve measures what it takes to place a package on a doorstep, and applies the same shape to software: total cost divided by units of delivery, with the unit chosen to fit the team. The supporting research is the more quotable finding — across tens of thousands of developers over five years, individual velocity reverts to the team's mean, making team velocity the strongest predictor of both individual output and perceived productivity, which is the empirical case against measuring individuals at all.
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.
The line that explains this session comes from the customer in the last ten minutes: they are preparing for a world where metadata is how agent-based systems find the data they need and access it through the controls being built. That relocates a function — governance has spent two decades as compliance activity describing data that people locate by other means, and if agents navigate by the catalogue then the catalogue stops describing the access path and becomes it. An incomplete catalogue is a documentation problem when humans can ask a colleague; an agent has no such workaround. The most honest moment addresses the perennial failure that rules get written and ignored, with enforcement rather than publication as the argument. Generated descriptions and greyed-out classification suggestions divide the labour correctly, keeping a person accountable while removing the burden of finding candidates.