CoreWeave 官博发表 AI 安全（AI loop）观点文章，仅为思想领导力内容，无产品 GA、订单或财务增量

For years, security reviews were built around familiar sensitive assets, including databases, storage systems, applications, networks, and the identities allowed to reach them. AI doesn’t replace those concerns; it adds a new class of assets with a more dynamic lifecycle.
Model weights, training data, checkpoints, embeddings, prompts, traces, evaluation data, and inference paths can span environments beyond the one covered in the original review. Many of those assets can carry sensitive data or proprietary signals. A model may be trained in one place, tuned in another, served from a third, and evaluated through systems that keep changing as teams learn from production behavior. Agents change the shape of the control model because they can call tools, retrieve context, generate outputs, and create action paths that the review may not have fully anticipated.
As systems become more agentic, trust depends less on a single boundary and more on what can be enforced, observed, revoked, and verified at runtime.
This is increasingly how useful AI gets built, and it changes the CISO review. “Is this environment secure?” still matters, but it is not enough for the dynamic nature of production AI. The harder standard is whether controls can stay with the work and remain verifiable as the system evolves.
That dynamic operating pattern is what CoreWeave describes as the AI loop. Models and agents run for real users, teams observe how they behave, that signal becomes curated data, the system is improved, and the next version is evaluated before it runs again. CoreWeave Forge was built to connect that loop across the tools and workflows behind AI development so that every trace, evaluation, and iteration can help make the next version better.
Security has to account for that same operating pattern. Identity, key authority, telemetry, revocation, and audit evidence need to stay attached to the work at every stage, in every environment.
The AI loop tests the boundary at runtime
The current conversation around agent sandboxes gets to a broader issue that security teams understand from experience. The boundary that matters is not the one described in the review document. It is the one the system actually enforces when software, identities, data, and tools interact at runtime.
Agent workflows make the boundary more dynamic by combining model reasoning, memory, tools, and external systems within a single workflow. A sandbox may limit where a system can run, what it can call, or which resources it can touch, but those limits still depend on the controls around them. Security teams need to understand:
- Identity: who or what is acting, and with which credentials
- Key authority: which keys can be used, and what data they can make readable
- Data use: which systems can access customer data, for what purpose, and under which controls
- Telemetry: which events reach the SOC as the system runs
- Revocation: how quickly access can be removed
Those factors can change across training, inference, evaluation, and agent execution. A new tool is added, a new dataset becomes part of an evaluation, a trace becomes a training signal, and a checkpoint moves into object storage.
As software becomes easier to reproduce, proprietary data and the model behavior it creates become a more durable source of competitive advantage. Protecting that data is no longer just about where it’s stored or who can open it. It is about whether the enterprise can trust how that data is used as the system keeps changing. The system diagram may still look familiar, but the control surface has changed. Control drift begins when the system keeps moving, and the security model is still describing an earlier version of it.
The loop creates new artifacts, access paths, and evidence
Most CISOs are used to reviewing systems that change, but AI changes the pace and volume of what needs to be governed. A pre-training run creates checkpoints that may land in object storage every few hours. As teams move into post-training, those weights may be tuned, evaluated, rolled out, and compared against new behavior. Reinforcement learning through capabilities like CoreWeave RL Rollouts brings inference into the training loop, with rollout generation, reward logic, new checkpoints, and updated weights feeding the next round of improvement.
For security teams, the challenge is not only that more artifacts exist but also that those artifacts can become part of the next decision, the next model version, or the next production path, while still carrying traces of the proprietary or business-critical data that shaped them. A trace may become evaluation data. An evaluation may influence promotion. A rollout may produce new behavior that needs review. Without controls that travel with the work, security teams can end up governing the last approved version of the system instead of the one actually running.
Control portability makes that manageable. Identity, key authority, telemetry, revocation, and audit evidence remain attached as the work moves through the loop, so AI teams can keep iterating while security teams retain a clear record of what changed, who or what acted, which data became usable, and whether access was removed when it needed to be.
Encryption is necessary; authority is harder
Encryption is table stakes. In AI, the harder operational issue is authority. As checkpoints, weights, traces, prompts, evaluation sets, and inference outputs move through the loop, security teams need to know who can make protected data usable, where that authority applies, and how quickly it can be revoked.
That’s why I would treat key control as part of containment, not as a compliance checkbox. A sandbox helps define where a system can operate. Identity helps define who or what can act. Key authority helps determine when protected data can be used.
If those controls separate from one another, security teams lose the ability to understand what became readable, who or what caused it, where it happened, and whether access was removed quickly enough.
Key authority has to travel with the work
This is where capabilities like Remote Key Encryption (RKE) become practical.
Remote Key Encryption is CoreWeave’s approach to protecting data at rest. It is designed to let customers use keys from the key infrastructure they already operate, whether that is a software key manager, a hardware security module, or a KMS in another cloud, while running AI workloads on CoreWeave.
For security teams, that means key authority can stay aligned to the customer’s governance model instead of being rebuilt around an AI cloud. They should be able to understand where key authority lives, who can make protected data readable, how access is scoped, how revocation works, and where the evidence lands.
RKE is one example of customer control traveling with the work. It is not the whole story. RKE protects data at rest, while data in use is a separate boundary that requires different controls.
Confidential computing and attestation are part of that next boundary. Confidential computing is designed to protect sensitive workloads while data is being processed. Attestation helps customers verify that the expected hardware and software environment is intact. Together, customer-held keys and confidential computing point toward a future in which key custody, runtime protection, and infrastructure verification work more closely together. They should not be confused with what RKE does today.
AI loop security has to work as a system
As AI development becomes more continuous, security has to stay connected to the way the system actually runs. That does not mean security teams need a new tool for every stage of AI development. In most environments, that would make the problem worse. Security teams should be able to bring the control planes they already trust into the AI environment.
That applies to identity, keys, telemetry, revocation, audit evidence, detection, and response. If a SOC already depends on a platform like the CrowdStrike Falcon® platform, AI infrastructure should not require the team to rebuild its playbooks in a separate provider console. Existing workflows should stay connected as AI work moves through training, inference, evaluation, and agent workflows.
Agentic AI makes this a full-stack problem. Models, tools, data, memory, runtime, networking, isolation, and governance all come together inside the same operating path. A weakness in one layer can change the risk posture of another. A runtime issue can become an identity issue. A tool call can become a data access issue. A missing signal can become a response issue.
That is why security cannot be treated as a layer added after the infrastructure decision is made. The AI loop depends on performance, but it also depends on trust. Teams running, observing, improving, and redeploying AI systems faster need evidence that the controls around that loop are still working.
I would apply that standard to any AI infrastructure platform, including ours. The practical test is not whether the architecture diagram looked good on day one. It is whether the controls still hold after the model changes, the data changes, the evaluation path changes, and the agent has new tools in front of it.
9 questions for securing the AI loop
If I were reviewing an AI infrastructure platform for production use, I would start with these questions.
- What does the sandbox actually enforce, and how is that enforcement verified?
- Which identities can act inside the AI environment, and where is the source of truth for those identities?
- Where do keys live; who can cause protected data to become readable; and can key use be scoped by identity, environment, purpose, and stage of the AI lifecycle?
- When an identity, token, or key is revoked, how quickly does that take effect across the environment?
- Does telemetry flow into my SOC as the system runs or only after I ask the provider for evidence?
- Can my existing detection and response workflows stay connected to the AI environment?
- Which controls are available and documented today, and which are still on the roadmap?
- What is protected at rest, in transit, and in use, and what can I verify today?
- Who has access to mission-critical data, and has everyone else been removed from that trust boundary?
Production trust has to be built on what is available, documented, enforceable, and verifiable now. Roadmaps have a place, but security teams need to know exactly what they’re trusting. Security cannot be a one-time approval around a system that keeps evolving. Controls need to travel with the work, and the evidence needs to travel with them.
Ready to secure your AI loop? Start here:
- See how CoreWeave Forge connects the AI loop and turns every iteration into compounding improvement
- Learn more about CoreWeave Remote Key Encryption
- Visit the CoreWeave Trust Center