DAILY NEWSLETTER · 2026-09-02 · AGENT OPERATIONS · AI RED TEAMING · DATA CENTER COOLING

2026-09-02 — Designing Agent Authority, Attack Boundaries, and AI Data Center Heat Together

The next bottleneck in AI operations cannot be solved by model choice alone. Teams need to reconstruct how an agent acted, stop it when external content tries to alter its behavior, and manage heat and power as compute demand grows. Today connects execution traces, red teaming, and cooling infrastructure into one control system.

Today’s direction — As AI scales, put execution records, attack boundaries, and physical constraints on the same operating sheet

Agents are becoming execution actors that reason across multiple turns, call tools, and alter intermediate state, rather than interfaces that simply answer a question. That changes the operating team’s questions. Instead of asking only whether an answer sounded plausible, teams need to ask which tool was called with which input, where policy and authority took effect, and where a failed run diverged. Observability and evaluation become a flight record for authorized automation, not merely a quality report.

For the same reason, security cannot end with a single prompt filter. External content that an agent reads—web pages, documents, attachments, and search results—can carry indirect prompt injection. The design must prevent content from being interpreted as trusted instruction, keep agent authority narrow, and put human approval in front of consequential actions. Red teaming is the repeated experiment that tests whether these boundaries hold under realistic attack paths.

The data center that supports compute follows the same principle. As AI demand rises, cooling becomes an operating variable affecting availability, power, location, and expansion speed rather than a peripheral facility concern. Korean work on immersion-cooling collaboration is a development and proof-of-concept plan among specific firms, not proof of a universal outcome for every data center. It nevertheless makes one point clear: execution control, security, and heat management are service-design conditions, not separate departmental side tasks.

1. Agent operations — Join observability, authority, and evaluation in one execution record

An agent failure is difficult to explain from the final answer alone. Work unfolds across multiple turns; tool calls and intermediate results change later choices; and state persists. Operating teams therefore need to move beyond saving a conversation transcript and trace the execution unit itself. A single job needs a shared identifier linking its inputs and outputs, tool calls, tool returns, policy decisions, approvals, and errors.

Authority control works on top of that record. Reading and writing, internal retrieval and external transmission, draft creation and a real change all carry different risk. Giving an agent broad connector access and watching only the outcome means discovering a bad call after it happened. Separate each tool’s target system, data category, permitted action, time range, and approval condition. If live call parameters exceed the approved or policy-evaluated scope, stop the run before execution. High-impact actions such as external transmission, account changes, financial or contractual actions, and deployment require a distinct human-confirmation boundary.

Evaluation also cannot remain a pre-release test. An agent can take different execution paths on the same task, so repeated trials are necessary and one successful example does not establish production stability. Evaluation must include not only the final artifact, but also tool-call order, unauthorized authority use, treatment of intermediate results, and recovery behavior after failure. Production traces can support debugging and monitoring while also supplying material for datasets and evaluation cases. Access controls and retention rules must accompany that reuse so sensitive source material is not copied indiscriminately.

In practice, one connected flow is better than three separate dashboards. The execution view should show a job identifier and step-level trace; the policy view should show the authority rule applied to each call; and the evaluation view should connect success and failure distributions for the same task type. Operators can then inspect not just error rates, but pending approvals, denied calls, retries, failures in a particular tool, attempted policy bypasses, and evaluation regressions. Only then can decisions to grant more authority or replace a model rest on real work records rather than inference.

Source · AnthropicDemystifying evals for AI agentsExplains why agent evaluation for multi-turn systems with tools and state needs traces of outputs, tool calls, and intermediate results, plus repeated trials. Source · LangChainLangSmith Observability - Docs by LangChainIntroduces observability that records production traces and supports debugging, monitoring, datasets, and evaluation work.

2. Agent security — Treat prompt injection as an authority problem and verify it through red teaming

Prompt injection does not refer only to a malicious sentence entered directly by a user. If an agent reads websites, email, documents, search results, or files, instructions embedded in those sources can indirectly influence action. Testing only whether a phrase such as “ignore prior instructions” succeeds is not enough. Attackers may use untrusted content to seek external transmission, secret disclosure, tool misuse, or approval bypass. The system needs a clear boundary between functionality that reads content and functionality that executes actions.

The first defense is separating source and role. Text obtained from an external document may be evidence for answering a question, but it is not a system instruction. The agent must treat untrusted content as separate data and prevent it from changing tool authority or policy. The second defense is least privilege. Assuming prompt defenses are imperfect, begin with read-only tools and restricted workspaces, then grant external communication, file changes, sensitive-data access, and consequential execution narrowly and only when needed. The third defense is human review. For consequential requests, show not only a natural-language summary but also the target, recipient, call parameters, and data movement, allowing an approver to judge the actual action.

Red teaming should be a structured risk-measurement practice, not a one-time review just before release. Testing that includes independent external evaluation helps reveal failures outside the team’s familiar normal-use paths. Scenarios need to go beyond a list of attack strings: test when a search tool reads an untrusted web page, when a document-summary tool processes an attachment, when multiple agents pass results to one another, when a run retries after failure, and when an approval request changes its target. Success means more than the model refusing the attack. Unauthorized action must not execute, sensitive information must not be disclosed, and a trace and alert must remain.

In production, connect red-team findings to the authority table. If a test identifies a dangerous tool combination, prohibit that combination or require additional approval. If a particular document source repeatedly causes trouble, revise how it is collected, normalized, and displayed. A new model, search connector, document format, or automation authority each triggers retesting. Security teams can record the attack stage, the control that stopped it, residual authority, user impact, and revalidation plan—not merely the number of findings. That record becomes an operating asset that narrows the gap between convenient agent features and the real attack surface.

Source · OWASPLLM01:2025 Prompt InjectionCovers direct and indirect prompt injection through websites and files, along with trusted-content separation, least privilege, and human-in-the-loop mitigations. Source · NISTArtificial Intelligence Risk Management Framework: Generative Artificial Intelligence ProfileRecommends structured AI red teaming and independent external evaluation in risk measurement, and defines prompt injection.

3. Korean AI infrastructure — Data center cooling is a physical operating condition for model expansion

AI infrastructure discussions often focus on GPU counts and model scale, but service continuity also depends on the ability to supply power and remove heat. The IEA projects worldwide data-center electricity consumption to rise from 415 TWh in 2024 to about 945 TWh in 2030. It says electricity demand from AI-optimized data centers could increase by more than four-fold over that period. This is a worldwide projection rather than a performance figure for an individual facility, but it is an operating signal to assess cooling architecture and power planning together early as AI compute grows.

Cooling is not a late facility-selection decision for the server room. It affects rack density, equipment arrangement, piping and fluid management, maintenance procedures, fault isolation, expansion sequence, and supply chains. Nor should teams conclude too simply that an air-cooled design can immediately become an immersion-cooled one. They need to assess which workloads create heat limits at which density, what current facilities can support, and what changes a new approach requires in facilities and operating procedures. Adoption decisions should move below performance claims to actual load conditions, proof-of-concept scope, maintenance responsibility, and recovery plans.

The October 28, 2025 memorandum of understanding among LG Electronics, SK Enmove, and GRC concerns development and proof of concept for AI-data-center liquid immersion cooling solutions. The announced roles are LG cooling integration, SK Enmove heat-management fluid, and GRC immersion tanks. The collaboration shows that a Korean AI-data-center cooling ecosystem must address integration, fluid, and tanks together rather than treat cooling as one device category. At the same time, an MOU and proof-of-concept plan must not be represented as a verified universal result. Operators need to confirm the proof-of-concept conditions, measurement criteria, and constraints of the target facility.

Agent operations and infrastructure operations are not separate. More agent work can mean more model calls, data movement, longer execution traces, and greater compute demand. Product teams should design for service levels, scheduling time, power and cooling limits, and workload-priority policy alongside usage-driven cost. Infrastructure teams should agree with product teams on which work is delay-sensitive, which work can move to lower priority during an emergency, and which automations stop safely under constrained resources. AI service resilience appears not only in model responses, but in the ability to decide which work continues within heat and power constraints.

Source · LG ElectronicsLG, SK Enmove and GRC Sign MOU to Advance Liquid Immersion Cooling Solutions for AI Data CentersReports a development and proof-of-concept collaboration combining LG cooling integration, SK Enmove heat-management fluid, and GRC immersion tanks. Source · IEAEnergy and AIProjects worldwide data-center electricity consumption to rise from 415 TWh in 2024 to about 945 TWh in 2030, with AI-optimized data-center demand potentially growing more than four-fold.

Operator memo

First, replay one real agent task from beginning to end. Select a job identifier and verify that user input, model output, tool calls, intermediate results, policy decisions, approval state, and final result can be connected. Check that write or external-transmission calls expose their target and parameters, that changed values receive policy inspection again after approval, and that failure, cancellation, and retry appear in the same record. Without this evidence, evaluation and incident analysis remain guesses based on the final answer.

Second, run red-team scenarios involving untrusted content at boundaries similar to production. Test whether instructions embedded in web pages, PDFs, spreadsheets, email, and search results can lead to tool calls or data transfer. For every scenario, retain the content read by the agent, attempted action, authority applied, human-approval state, and blocking and alerting result. Do not end remediation with a prompt-text change; decide whether the fix belongs in content separation, reduced authority, approval rules, or tool policy.

Third, add cooling and power questions to the AI usage plan. Before the next model rollout or agent-function expansion, document expected compute demand, high-priority work, delay-tolerant work, facility constraints, and decision owners for expansion or proof of concept in one plan. When assessing immersion cooling, compare more than equipment claims: verify actual workloads, measurement criteria, maintenance, responsibility boundaries for fluids and facilities, and recovery procedures.

The common purpose of these three checks is to turn invisible dependencies into manageable operating units. Traces make agent behavior visible; red teaming reveals the combination of external content and authority; infrastructure planning reveals the physical limits of compute. Rather than scattering these boundaries across separate reports, organizations can manage them together in service-change review and incident-response documents. That reduces the risk that feature expansion, attack response, and capacity planning proceed at different speeds and consume one another’s safety margin.

Today’s core task is to design evidence of action, boundaries against attack, and physical conditions for compute before expanding AI capability. Agents need traces covering tool calls and intermediate results as well as outputs; external content must be treated as untrusted data rather than instruction; and AI infrastructure must count power and cooling as part of service operations.

Operational AI is not the system that automates the most work. It is the system that executes only necessary authority, stops safely when it encounters risky input, and sustains high-priority work under resource constraints. Applying that standard together to execution records, red teaming, and infrastructure planning preserves control and resilience alongside automation speed.