Optimizing Security Incident Response with LLMs at Google
google · Tech · 2024 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: Security incident response communications
Google needed to reduce the time incident responders spent drafting security and privacy incident summaries while preserving factual accuracy, privacy, regulatory accountability, and stakeholder-ready communication quality.
Constraints:
- Incident communications needed to serve executives, leads, and partner teams.
- Security and privacy incidents contain confidential, sensitive, and privileged data.
- Incident inputs are messy, including logs, images, links, impact statistics, timelines, and code snippets.
- Generated drafts could hallucinate or be misinterpreted, so human accountability remained required.
- The system had to support both short summaries and more complex executive communications.
Architecture
Google built a privacy-preserving LLM drafting workflow for incident communications. Incident data is preprocessed into structured tags, noisy logs and code are collapsed into placeholders, the LLM drafts a summary or executive update from few-shot prompts, and the UI inserts the proposed text into a human review flow. Logging is disabled across the UI, model, and output path, so operational monitoring relies on metrics and indicators rather than retained incident content.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR Incident_facts["Incident facts"] --> Input_preprocessing["Input preprocessing"] Input_preprocessing --> LLM_drafting_prompt["LLM drafting prompt"] LLM_drafting_prompt --> Draft_review_UI["Draft review UI"] LLM_drafting_prompt --> Metrics_and_indicators["Metrics and indicators"] Draft_review_UI --> Human_incident_responder["Human incident responder"] Human_incident_responder --> Incident_communication_record["Incident communication record"]
Components
| Component | Role | Interacts with |
|---|---|---|
Incident facts |
Raw incident context such as free-form text, logs, images, links, impact statistics, timelines, and code snippets. | Input preprocessing |
Input preprocessing |
Structures incident data with semantic tags and replaces noisy logs or code with compact placeholders. | LLM drafting prompt |
LLM drafting prompt |
Uses refined instructions, few-shot examples, and tags to generate incident summaries or executive updates. | Draft review UI, Metrics and indicators |
Draft review UI |
Presents generated summaries to human responders for acceptance, editing, or rejection. | Human incident responder |
Human incident responder |
Reviews and accepts, modifies, or discards generated incident communications. | Incident communication record |
Incident communication record |
Final stakeholder-facing incident summary or executive update after human review. | — |
Metrics and indicators |
Provides operational visibility without storing sensitive incident content. | — |
Data flow
Incident facts from the response process are converted into structured tagged input; the prompt-guided LLM drafts a summary; the UI pre-populates a text field with the draft; a human accepts, edits, or discards it before it becomes part of the incident communication.
3 supporting quotes
“The type of data we process during incidents can be messy and often unstructured: Free-form text, logs, images, links, impact stats, timelines, and code snippets.”article, stated
“we refined this approach and added additional tags such as , <Actions Taken>, <Impact>, <Mitigation History>, <Comment>”</span><span class="rc">article, stated</span></div><div class="receipt"><span class="rq">“the UI had a ‘Generate Summary’ button, which would pre-populate a text field with the summary that the LLM proposed.”</span><span class="rc">article, stated</span></div></details>
<h3>Why this architecture</h3>
<p>Google chose a structured, reviewed drafting assistant instead of autonomous communication because security incidents are sensitive, messy, compliance-relevant, and prone to hallucination risk. Tagging makes incident facts legible to the model, few-shot prompts control format and quality, and human review preserves accountability.</p>
<blockquote>
<p>"we first replaced long and noisy sections of codes/logs by self-closing tags (<Code Section/> and <Logs/>) both to keep the structure while saving tokens"
— <em>article, stated</em>
"any LLM generated draft must be reviewed by a human. But not all risks are from the LLM - human misinterpretation of a fact or statement generated by the LLM can also happen."
— <em>article, stated</em></p>
</blockquote>
<p><strong>Models used:</strong> Large Language Model</p>
<h2>Scale</h2>
<ul>
<li>Google's incident response processes protect billions of global users.<blockquote>
<p>"Our detection and response processes are critical in protecting our billions of global users from the growing threat landscape"
— <em>article, stated</em></p>
</blockquote>
</li>
<li>Writing a thorough incident summary could take nearly an hour, while complex communications could take multiple hours.<blockquote>
<p>"We estimate that writing a thorough summary can take nearly an hour and more complex communications can take multiple hours."
— <em>article, stated</em></p>
</blockquote>
</li>
<li>The human-vs-LLM comparison used 50 human-written summaries and 50 LLM-written summaries.<blockquote>
<p>"We ran an experiment that took 50 human-written summaries from native and non-native English speakers, and 50 LLM-written ones with our finest (and final) prompt"
— <em>article, stated</em></p>
</blockquote>
</li>
<li>The summary tool saved 51% of drafting time on a 300-summary sample.<blockquote>
<p>"Our newly-built tool produced well-written and accurate summaries, resulting in 51% time saved, per incident summary drafted by an LLM, versus a human."
— <em>article, stated</em></p>
</blockquote>
</li>
<li>Inputs below 200 tokens are routed away from the LLM.<blockquote>
<p>"If the input size is smaller than 200 tokens, we won’t call the LLM for a summary and let the humans write it."
— <em>article, stated</em></p>
</blockquote>
</li>
<li>Executive updates saw a 53% drafting-time reduction.<blockquote>
<p>"LLM-generated drafts, reduced time ICs spent writing executive summaries by 53% of time, while delivering at least on-par content quality"
— <em>article, stated</em></p>
</blockquote>
</li>
</ul>
<h2>Alternatives considered (roads not taken)</h2>
<h3>Manual incident summary drafting</h3>
<p><strong>Rejected because:</strong> Manual drafting was tedious and time-consuming, taking nearly an hour or more for complex communications.</p>
<blockquote>
<p>"This can be a tedious and time-consuming process that heavily depends on the target group and the complexity of the incident."
— <em>article, stated</em></p>
</blockquote>
<h3>Simple summarization prompt</h3>
<p><strong>Rejected because:</strong> The first prompt produced summaries that were too long, missed important facts, and had inconsistent style.</p>
<blockquote>
<p>"The summary was too long, especially for executives trying to understand the risk and impact of the incident"
— <em>article, stated</em>
"Some important facts were not covered, such as the incident’s impact and its mitigation"
— <em>article, stated</em></p>
</blockquote>
<h3>More elaborate prompt without few-shot examples</h3>
<p><strong>Rejected because:</strong> The second prompt still lost task focus, missed latest updates, and produced minor hallucinations.</p>
<blockquote>
<p>"At times, the model lost sight of the task or did not take all the guidelines into account"
— <em>article, stated</em>
"We noticed a tendency to draw conclusions on hypotheses with some minor hallucinations"
— <em>article, stated</em></p>
</blockquote>
<h3>Call the LLM even for very small inputs</h3>
<p><strong>Rejected because:</strong> Small inputs caused hallucinated summaries, so the system skips the LLM below a 200-token threshold.</p>
<blockquote>
<p>"The only edge cases we have seen were around hallucinations when the input size was small in relation to the prompt size."
— <em>article, stated</em></p>
</blockquote>
<h2>Patterns</h2>
<h3><code>human-in-the-loop-gate</code> <em>(safety)</em></h3>
<p>Generated incident summaries are drafts that a human accepts, edits, or discards before use.</p>
<blockquote>
<p>"A human user can then either accept the summary and have it added to the incident, do manual changes to the summary and accept it, or discard the draft and start again."
— <em>article, stated</em></p>
</blockquote>
<h3><code>prompt-versioning</code> <em>(prompting)</em></h3>
<p>Google iterated across prompt versions until few-shot examples and a Good Summary tag produced the desired output.</p>
<blockquote>
<p>"For the final prompt, we inserted 2 human-crafted summary examples and introduced a <Good Summary> tag to highlight high quality summaries but also to tell the model to immediately start with the summary without first repeating the task at hand (as LLMs usually do)."
— <em>article, stated</em></p>
</blockquote>
<h3><code>privacy-preserving-processing</code> <em>(privacy)</em></h3>
<p>The incident-summary pipeline disables logging and retraining use because incident data is sensitive.</p>
<blockquote>
<p>"Every component of this pipeline - from the user interface to the LLM to output processing - has logging turned off."
— <em>article, stated</em></p>
</blockquote>
<h3><code>safety-policy-enforcement</code> <em>(safety)</em></h3>
<p>The system refuses to call the LLM when input is below 200 tokens because that edge case caused hallucinated summaries.</p>
<blockquote>
<p>"If the input size is smaller than 200 tokens, we won’t call the LLM for a summary and let the humans write it."
— <em>article, stated</em></p>
</blockquote>
<h3><code>eval-driven-development</code> <em>(quality)</em></h3>
<p>Google compared LLM and human summaries in a blind evaluation and measured time savings over a larger sample.</p>
<blockquote>
<p>"We ran an experiment that took 50 human-written summaries from native and non-native English speakers, and 50 LLM-written ones with our finest (and final) prompt"
— <em>article, stated</em></p>
</blockquote>
<h2>Tradeoffs</h2>
<h3>Use an LLM draft plus human review rather than autonomous incident communication.</h3>
<p><strong>Chose</strong> Human-reviewed generated drafts <strong>over</strong> Fully automated communication.</p>
<p><strong>Rationale:</strong> Human review mitigates hallucinations, misinterpretation, and accountability risks in high-stakes incident communications.</p>
<blockquote>
<p>"any LLM generated draft must be reviewed by a human. But not all risks are from the LLM - human misinterpretation of a fact or statement generated by the LLM can also happen."
— <em>article, stated</em></p>
</blockquote>
<h3>Disable logging instead of retaining incident traces for easier debugging.</h3>
<p><strong>Chose</strong> No stored incident content <strong>over</strong> Traditional content logging.</p>
<p><strong>Rationale:</strong> The sensitive incident domain made privacy more important than normal logging-based observability.</p>
<blockquote>
<p>"Every component of this pipeline - from the user interface to the LLM to output processing - has logging turned off."
— <em>article, stated</em></p>
</blockquote>
<h3>Collapse noisy logs and code into tags instead of passing full raw artifacts.</h3>
<p><strong>Chose</strong> Structured placeholders and semantic tags <strong>over</strong> Full raw logs and code in the prompt.</p>
<p><strong>Rationale:</strong> Tags preserve useful structure while saving tokens and reducing hallucination risk.</p>
<blockquote>
<p>"For that, we first replaced long and noisy sections of codes/logs by self-closing tags (<Code Section/> and <Logs/>) both to keep the structure while saving tokens for more important facts and to reduce risk of hallucinations."
— <em>article, stated</em></p>
</blockquote>
<h3>Route short inputs to humans rather than improving recall through extra model calls.</h3>
<p><strong>Chose</strong> Human-written summaries below 200 tokens <strong>over</strong> LLM generation for all incidents.</p>
<p><strong>Rationale:</strong> Small inputs had produced incorrect hallucinated key points.</p>
<blockquote>
<p>"If the input size is smaller than 200 tokens, we won’t call the LLM for a summary and let the humans write it."
— <em>article, stated</em></p>
</blockquote>
<h2>Gotchas (what bit them)</h2>
<h3>Short incident inputs caused hallucinated summaries.</h3>
<p><strong>Root cause:</strong> The prompt was large relative to the input, leaving too little grounded incident content.</p>
<p><strong>Resolution:</strong> Skip LLM generation below 200 input tokens and route the case to humans.</p>
<blockquote>
<p>"when the input size was small in relation to the prompt size. In these cases, the LLM made up most of the summary and key points were incorrect."
— <em>article, stated</em></p>
</blockquote>
<h3>Unstructured incident data can confuse summarization.</h3>
<p><strong>Root cause:</strong> Incidents include messy text, logs, images, links, impact statistics, timelines, and code snippets.</p>
<p><strong>Resolution:</strong> Preprocess incident data into semantic tags and compact placeholders before prompting.</p>
<blockquote>
<p>"The type of data we process during incidents can be messy and often unstructured: Free-form text, logs, images, links, impact stats, timelines, and code snippets."
— <em>article, stated</em></p>
</blockquote>
<h3>Privacy constraints remove normal debugging logs.</h3>
<p><strong>Root cause:</strong> Security incidents can contain confidential, sensitive, and privileged data.</p>
<p><strong>Resolution:</strong> Turn off logging throughout the pipeline and rely on metrics and indicators.</p>
<blockquote>
<p>"Given that our incidents can contain a mixture of confidential, sensitive, and privileged data, we had to ensure we built an infrastructure that does not store any data."
— <em>article, stated</em></p>
</blockquote>
<h3>Prompt instructions alone did not immediately produce stakeholder-ready summaries.</h3>
<p><strong>Root cause:</strong> Early prompts produced long, incomplete, inconsistent, or stale summaries.</p>
<p><strong>Resolution:</strong> Iterate prompt versions, add few-shot examples, and use a Good Summary tag.</p>
<blockquote>
<p>"This produced outstanding summaries, in the structure we wanted, with all key points covered, and almost without any hallucinations."
— <em>article, stated</em></p>
</blockquote>
<h2>Evaluation</h2>
<p>Google used blind comparison of human-written and LLM-written summaries plus a larger time-savings measurement over generated summaries.</p>
<p><strong>Metrics:</strong> 50 human-written summaries · 50 LLM-written summaries · 10% higher quality rating · 51% time saved · 300-summary time-savings sample · 53% executive-summary time reduction</p>
<blockquote>
<p>"We ran an experiment that took 50 human-written summaries from native and non-native English speakers, and 50 LLM-written ones with our finest (and final) prompt, and presented them to security teams without revealing the author."
— <em>article, stated</em>
"they were rated 10% higher than their human-written equivalents, and cut the time necessary to draft a summary in half."
— <em>article, stated</em>
"Time savings using LLM-generated summaries (sample size: 300)"
— <em>article, stated</em></p>
</blockquote>
<h2>Outcomes</h2>
<ul>
<li>LLM-written incident summaries were rated 10% higher than human-written equivalents.</li>
<li>Incident summary drafting became 51% faster.</li>
<li>Executive summary drafting time fell by 53%.</li>
<li>The final prompt produced structured summaries with all key points covered and almost no hallucinations.</li>
</ul>
<p>The system was evaluated over 50 human and 50 LLM summaries, measured time savings over 300 summaries, skips LLM calls under 200 input tokens, and operates within Google's security response context for billions of global users.</p>
<blockquote>
<p>"the LLM-written summaries covered all of the key points, they were rated 10% higher than their human-written equivalents"
— <em>article, stated</em>
"Our newly-built tool produced well-written and accurate summaries, resulting in 51% time saved, per incident summary drafted by an LLM, versus a human."
— <em>article, stated</em>
"Moreover, LLM-generated drafts, reduced time ICs spent writing executive summaries by 53% of time, while delivering at least on-par content quality in terms of factual accuracy and adherence to writing best practices."
— <em>article, stated</em></p>
</blockquote>
</article></main>
<footer>agentic-system-patterns · library v1 · generated from reviewed extractions — every claim quote-grounded</footer>
<script type="module">try{const m=(await import("https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs")).default;m.initialize({startOnLoad:false,securityLevel:"loose",theme:matchMedia("(prefers-color-scheme: dark)").matches?"dark":"neutral"});await m.run({querySelector:"pre.mermaid"});}catch(e){/* offline: diagrams remain as readable code */}</script>
<script>
(function(){
function setup(fig){
var view=fig.querySelector('.diagram-view'), pre=view&&view.querySelector('pre.mermaid'), svg=pre&&pre.querySelector('svg');
if(!svg||fig.dataset.pz)return; fig.dataset.pz='1';
// intrinsic diagram size from viewBox (reliable), fallback to bbox
var vb=svg.viewBox&&svg.viewBox.baseVal, w=vb&&vb.width?vb.width:0, h=vb&&vb.height?vb.height:0;
if(!w||!h){try{var bb=svg.getBBox();w=bb.width;h=bb.height;}catch(e){w=800;h=400;}}
svg.setAttribute('width',w); svg.setAttribute('height',h); svg.style.maxWidth='none'; svg.removeAttribute('style');
svg.setAttribute('width',w); svg.setAttribute('height',h);
var s=1,x=0,y=0,down=false,px=0,py=0;
function apply(){pre.style.transform='translate('+x+'px,'+y+'px) scale('+s+')';}
function fit(){var r=view.getBoundingClientRect();var sc=Math.min(r.width/w,r.height/h)*0.92;if(!isFinite(sc)||sc<=0)sc=1;s=sc;x=(r.width-w*sc)/2;y=(r.height-h*sc)/2;apply();}
function zoom(f,cx,cy){var r=view.getBoundingClientRect();cx=(cx==null?r.width/2:cx-r.left);cy=(cy==null?r.height/2:cy-r.top);var ns=Math.min(12,Math.max(.1,s*f));x=cx-(cx-x)*(ns/s);y=cy-(cy-y)*(ns/s);s=ns;apply();}
view.addEventListener('wheel',function(e){e.preventDefault();zoom(e.deltaY<0?1.12:.89,e.clientX,e.clientY);},{passive:false});
view.addEventListener('pointerdown',function(e){down=true;px=e.clientX;py=e.clientY;view.setPointerCapture(e.pointerId);view.style.cursor='grabbing';});
view.addEventListener('pointermove',function(e){if(!down)return;x+=e.clientX-px;y+=e.clientY-py;px=e.clientX;py=e.clientY;apply();});
var end=function(){down=false;view.style.cursor='grab';};
view.addEventListener('pointerup',end); view.addEventListener('pointercancel',end);
fig.querySelectorAll('button[data-z]').forEach(function(b){b.addEventListener('click',function(){
var z=b.dataset.z;
if(z==='in')zoom(1.3);else if(z==='out')zoom(.77);
else if(z==='reset')fit();
else if(z==='full'){if(!document.fullscreenElement)fig.requestFullscreen&&fig.requestFullscreen();else document.exitFullscreen();}
});});
document.addEventListener('fullscreenchange',function(){if(document.fullscreenElement===fig)setTimeout(fit,60);});
view.style.cursor='grab';
fit();
}
var t=setInterval(function(){document.querySelectorAll('figure.diagram').forEach(function(f){if(f.querySelector('pre.mermaid svg'))setup(f);});},200);
setTimeout(function(){clearInterval(t);},8000);
})();
</script>
</body>
</html>