Securing Software at the Speed of AI

Lessons from building an agentic software security strategy at Palantir

Introduction

Palantir’s Product Security Team began experimenting with agentic AI across a variety of security workflows over a year ago. By the time Anthropic launched Project Glasswing, we were already using an internal multi-agent review harness with AI security agents focused on different areas of security expertise. Anthropic’s Mythos model and OpenAI’s cyber program helped to accelerate that work.

Today, our team has operating capabilities for multi-agent source-code review, analyst-directed vulnerability hunting, product-team triage, and runtime validation. Agentic design review and penetration testing continue to develop, supported by the context generated through code and product reviews. In addition to using these capabilities to improve the security of our own software, we have also productionized our model-agnostic AI reviewer platform — called Security Forge — for customers to use for their own cyber defense.

Five key insights have shaped our software security strategy and Security Forge product:

A model alone is not a security-review program. Models need a harness — the software, instructions, tools, and controls that divide work among agents, determine what each agent can access, preserve evidence, challenge findings, and route results to engineers. We leverage our Palantir Artificial Intelligence Platform (AIP) as an orchestrator of agent-driven workloads.
The quality of a harness depends heavily on the organizational context it is able to leverage for a specific task. A model is more useful when it understands how services relate, where trust boundaries sit, which configurations are deployed, what earlier reviews concluded, and who owns the affected software. We leverage our Palantir Foundry data operations platform to connect that context through ontological lineage across source material, findings, decisions, and remediation.
An organization’s context is their alpha, and must stay under their ownership and control. The context that enables security agents to be effective — data, models, decisions, actions, deployment environments, and accumulated knowledge — is part of an organization’s unique alpha and should not be exposed externally. Sovereignty over an AI security pipeline is key to ensuring the intelligence an organization generates compounds back into its own systems rather than benefiting third parties who could repackage it, resell it, or use it to erode the organization’s competitive position.
Remediation is the new bottleneck. The pace of vulnerability identification has fundamentally accelerated. This has shifted the bottleneck in cyber defense from identification to remediation: how quickly can fixes be deployed across vast, heterogeneous environments? We leverage our Palantir Apollo software production platform to ontologize the properties of our environment and provide an established path for delivering verified fixes across our entire software fleet.
Models and harnesses will continue to improve. The durable capability is the governed process and infrastructure around them. As models and harnesses improve over time, the infrastructure around them will determine whether an organization’s security program actually gets better as a result. Our security pipeline — Foundry compounding security context and memory, AIP orchestrating swappable agents, and Apollo applying fixes across our software estate — provides a durable framework that lets us adapt as models and threats change.

Expanding on the Insights

In our early evaluations of agentic AI, Palantir tested agents across Request for Comment (RFC) and engineering review, source-code analysis, Common Vulnerabilities and Exposures (CVE) triage, patch development, and penetration testing. Not all agents were uniformly useful. Code review and vulnerability analysis produced the fastest and most repeatable value. They generated actionable findings tied to specific code paths while building knowledge about products, services, trust boundaries, architecture, prior findings, and the reasons behind security decisions.

As a result of that experimentation, reviewing existing software became the foundation of our strategy: identify risk in what runs today, retain the context from each assessment, and apply that knowledge to future development, dynamic testing, and remediation. That context made RFC review more useful and gave dynamic testing stronger hypotheses than off-the-shelf tools could provide. We also built workflows for product engineers to validate, prioritize, and remediate the resulting findings.

Below, we elaborate on the insights that have helped us evolve and accelerate many aspects of our internal software security strategy and our Security Forge product.

Models Need a Harness

Models need a harness — the software, instructions, tools, data access, and controls that organize work across agents, determine what each agent can access, preserve evidence, and route validated results to engineers. In our security pipeline, AIP provides this harness and orchestration layer, coordinating multiple agents and models through structured workflows tuned for analytical depth, operational efficiency, or specific vulnerability classes.

AIP organizes code-review and security-analysis workflows into sequential and parallel stages designed to increase coverage, challenge weak findings, and produce structured, evidence-backed results. The workflow begins with a Foundation stage, in which agents map the target environment. They inspect the repository, dependencies, interfaces, authentication paths, deployment context, and available design material. Using this information, they establish an initial threat model and identify the relevant attack surface.

AIP then orchestrates specialized agents in parallel during the Hunt stage. One agent may trace authorization decisions while another examines untrusted parsing, outbound requests, secret handling, or dependency behavior. Other agents can investigate how individually modest weaknesses might combine across components to create a broader exploit path. Because AIP connects models to organizational data and operational systems, these analyses can incorporate not only source code but also deployment information, asset relationships, runtime context, and other data represented in the Foundry Ontology (see below).

As agents develop hypotheses, AIP coordinates independent validation and challenge stages intended to disprove or refine those hypotheses. Deterministic deduplication is particularly important. Semantic similarity alone can be inconsistent, so the workflow also compares each finding’s source-to-sink path: how untrusted input moves from its entry point to the operation that creates the risk. This comparison helps determine whether multiple reports reflect the same root cause or represent distinct vulnerabilities. A separate judging agent, operating independently from the original analysis session, can then challenge the evidence, assess exploitability, and validate the finding before it reaches the final report.

AIP governs access to the data and tools available at each stage of the analysis. Depending on the task, agents may receive controlled access to source code, documentation, dependency information, build systems, deployment metadata, threat intelligence, or isolated execution environments for testing proposed fixes. AIP’s orchestration and control mechanisms ensure that agents operate within approved boundaries while preserving the evidence behind every finding. That evidence can be reviewed and challenged by another agent, a security engineer, or the product owner.

The Synthesis stage consolidates the results. AIP correlates raw flags, filters likely false positives, validates exploitability, and collapses related weaknesses into unified findings with documented exploit paths, severity assessments, weakness mappings, and remediation guidance. Analyst decisions and adjudications can be captured in the Ontology as structured organizational knowledge, allowing future agent runs to incorporate prior conclusions, avoid repeatedly surfacing dismissed findings, and improve detection fidelity over time.

A model itself is only one part of this system, and no single model or run provides complete coverage. We have found that different models identify different attack surfaces, vulnerability classes, and critical issues under the same AIP-orchestrated workflow. They also vary in refusal behavior, duplicate rate, severity calibration, cost, runtime, and ability to complete long attack chains. Newer models are not uniformly better at every task; an older model may remain more effective for a particular workflow or vulnerability class.

Repeated runs of the same model also produce meaningful variation. Agentic systems are probabilistic, so a single successful analysis should not be treated as proof of complete coverage. AIP enables repeated execution, independent validation, and cross-model comparison, helping to surface additional findings and reveal where each configuration is strong or weak.

AIP is therefore model-agnostic by design. It enables us to evaluate output quality for the task at hand and orchestrate complementary commercial, government-owned, or third-party models through the same controlled workflow. By coordinating models, agents, tools, data, validation steps, and human approvals, AIP reduces blind spots, improves coverage, and supports the deployment, governance, security, and sovereignty requirements of our operational environment.

Harnesses Need Organizational Context

One key finding of our agentic AI experimentation was that allowing agents to review existing software helped to build valuable context for future reviews. Each assessment taught the system about how a product was assembled: its service relationships, identity assumptions, exposed interfaces, deployment shapes, known mitigations, accepted risks, and prior fixes.

That knowledge can then improve every subsequent line of work. An RFC review becomes more useful when the agent can compare a proposed design with the actual trust boundaries and failure modes of related services. A code review becomes more precise when it can reuse earlier reachability decisions instead of inferring the environment from scratch. A runtime-testing agent can choose better actions when it knows which paths the source review considered plausible.

We use our Foundry data operations platform to build and maintain this organizational context. Foundry lets us create an Ontology for our cyber defense work — a shared operational model that connects products, services, repositories, models, assessments, findings, evidence, owners, triage decisions, patches, and deployment status as a single source of operational truth. AIP runs on this Ontology in Foundry, turning all agentic activity into operational context that feeds back into the orchestration layer and compounds into model effectiveness over time.

The Ontology also preserves data lineage, which is necessary for showing how a conclusion was reached — which source and context were reviewed, which model and harness produced the candidate, what evidence survived validation, who made the decision, and what remediation followed. That lineage enables model output to be authenticated, either by humans and/or by other agents. A product engineer needs to inspect the evidence and understand the assumptions behind a finding. A later agent needs to know whether an earlier issue was disproved, accepted, mitigated elsewhere, or fixed. Security leadership needs to see verified risk and remediation progress rather than a total count of alerts.

In our security environment, our Apollo software production platform (see more below) serves as a starting baseline for building an ontological model of our attack surface. With all assets already governed by Apollo, each asset’s existence and many of its characteristics are already a known quantity. Those properties can be ingested into the Ontology from the start, helping to power discovery or visibility workloads on day one.

As the Ontology matures, every review can improve the next one, and the context gathered from existing software can feed everything from design review to code review, dynamic testing, and remediation.

Organizational Context Must Remain Sovereign

The context that enables security agents to be effective — data, models, decisions, actions, deployment environments, and accumulated knowledge — is part of an organization’s unique alpha and should not be exposed externally. Every detection, triage decision, and remediation action an agent takes generates information about how an organization actually operates. If that signal is captured by a hosted model provider rather than the organization itself, the feedback loop that should be improving the organization’s own defenses instead flows outward, refining someone else’s model at the organization’s expense. This asymmetry compounds over time, with the provider’s system growing smarter across its entire customer base while the originating organization sees none of the differentiated advantage its own operational history should be producing. That signal must be retained in order to turn security operations into a compounding institutional asset.

Furthermore, an organization’s security posture cannot be hostage to a single model account, cloud region, or vendor’s roadmap. The organization should be able to route detection, triage, and response across any model, any compute, and any deployment environment — on-premises, sovereign cloud, or at the edge. This is especially critical for security workloads, where operational speed requires the ability to act on findings in real time. A governed loop that connects detection through remediation and rollout must stay under the organization’s own authority to move at the speed threats actually demand.

For these reasons, we strongly advocate for a “sovereign” approach to AI, in which an organization controls and independently operates its own AI environment. A sovereign approach is not opposed to using best-in-class commercial models. An organization can and should use whatever model performs best for a given task — but it should still own the data, the decision logic, the audit trail, and the resulting institutional memory. Without that ownership, security teams are unable to build the kind of durable, differentiated defense posture that only comes from an organization controlling and learning from its own accumulated experience.

As an example of AI sovereignty, we recently completed a migration of all Palantir employees away from frontier-provided clients in favor of internally developed productivity tooling. This has given us flexibility over model usage and architecture and total control over the fate of any alpha present in a given workload. We expect to see a similar norm propagate throughout industry as institutions weigh risks that may imperil their own means of production.

Remediation is the New Bottleneck

Until recently, the main bottleneck in cyber defense was an organization’s ability to find vulnerabilities in its software. This was a highly manual process that relied on large teams of security engineers. Today, agentic AI can do this easily and with unprecedented speed and depth, uncovering novel vulnerabilities and developing multi-stage exploits at a velocity that humans cannot match. This shifts the bottleneck to the remediation process — how quickly can a security team fix all of the issues its agents are finding?

Palantir entered this period of agentic AI with a major advantage: software production and delivery was already highly automated through our Apollo platform. Apollo serves a dual and critical function in our security pipeline: it is simultaneously the monitoring and alerting mechanism that surfaces security-relevant events across our environments, and the remediation capability through which validated fixes, patches, and configuration changes are deployed at scale. This dual role is architecturally significant because in most security environments, detection and remediation are handled by separate tools with manual handoffs between them. Apollo eliminates this gap, providing a single, auditable control plane that spans the full lifecycle from alert generation to confirmed remediation without requiring manual intervention.

Apollo manages deployments, upgrades, rollbacks, service health, and the distribution of software across a wide range of connected and disconnected environments. Once a fix is established, Apollo manages the release mechanics across our entire software estate. This has made the new agentic discovery tempo manageable; a higher finding rate does not automatically create a proportional release-management burden.

Information from Apollo additionally serves as a source of visibility feeding back into the Ontology in Foundry. From the earliest phases of operating an AI-driven security platform, and actively throughout its lifecycle, the deployment orchestration layer is an ongoing source of institutional knowledge about the environment’s attack surface. Its properties and characteristics feed the Ontology, which in turn provides context and a superior understanding of state for successive agentic workloads operating against the environment.

Process and Infrastructure are the Durable Capabilities

Every generation of models will be faster, cheaper, and better at finding and fixing vulnerabilities than the last. The question is whether an organization’s security program actually gets better as a result, or whether each model upgrade brings the program back to square one instead of building on past experience. The answer depends on everything around the model: how the organization records what was found, keeps track of decisions, audits both human and agentic activity, and turns approved fixes into deployed changes. Those surrounding processes and systems are what preserve institutional knowledge, maintain accountability, and allow the program to improve over time.

In our security program:

Foundry provides context and continuity. Each detection pass is connected to the Ontology, which maintains a persistent view of our assets, identities, and relevant behaviors across review cycles. When an engineer confirms or dismisses a finding, that decision — and the reasoning behind it — is recorded as structured context rather than left in a chat or buried in a closed ticket. Future agent runs can use that history, so the same finding does not have to be evaluated from scratch every time. It also gives us a clear record of each review: what was found, who or what produced it, and why it was accepted or rejected.
AIP runs the detection and triage work. We can use approved commercial, government, or third-party models, and replace or add models as they are evaluated and authorized. That keeps our security program from depending on any single vendor and lets us adopt better cyber-focused models without rebuilding the surrounding process. AIP can survey the environment, run specialized agents in parallel, correlate and validate their results, and produce a prioritized queue of findings that have been checked for exploitability. This lets our human reviewers focus on the decisions that require their unique judgment, such as triage, policy approvals, disclosures, and change reviews.
Apollo carries approved fixes through the fleet. Patches, configuration changes, and actions such as host isolation are staged, health-checked, and authorized before reaching production. Each action is logged with the information needed to support change control and establish what happened after the fact. That makes it possible to move quickly across a large, heterogeneous fleet without losing the review trail our engineers and oversight teams rely on.

Together, Foundry, AIP, and Apollo give the program a stable foundation as models and threats evolve. Foundry preserves the context, AIP provides a replaceable intelligence layer, and Apollo ensures that approved changes are carried out in a controlled and traceable way. The models can change anytime without forcing us to redesign the entire security program around them.

Security Forge — A Solution for Customers

For customers who want to use Palantir capabilities for their own cyber defense, we developed Security Forge, a model-agnostic AI reviewer platform that automates the high-volume, repetitive elements of security operations while preserving human judgment at the decisions that matter most. Security Forge includes the Foundry, AIP, and Apollo platforms discussed above in an integrated solution that customers can use in their own environments. Security Forge enables organizations to:

Use cyber-tuned LLMs with code and network access to actively hunt for vulnerabilities;
Apply organizational context (team staffing, asset criticality, usage data, real-world data and intelligence) to prioritize findings intelligently;
Feed findings into a remediation agent that automatically recommends and builds code and architectural changes as well as mitigating controls that can break the kill-chain; and
Automatically deploy remediations to software and network assets at a speed humans alone cannot match.

Security Forge creates a continuously operating, feedback-driven cycle that improves detection fidelity over time, reduces analyst burden, and accelerates time-to-containment for confirmed threats.

Building Your Own Agentic Security Pipeline

For organizations seeking to build their own agentic security pipeline using other technologies, we offer the following as a practical starting sequence:

Build a software inventory. Connect repositories, services, dependencies, owners, deployed versions, and runtime environments. Agents need to know what exists and who is accountable for it.
Start with bounded code-review tasks. Choose targets where findings can be tied to specific code paths and checked by engineers. Use those reviews to establish evidence standards and build initial context.
Put a controlled harness around the models. Divide work among scoped agents, restrict tools and credentials by stage, preserve the evidence behind each finding, challenge candidate findings independently, and deduplicate the results before they reach engineers.
Evaluate multiple models and repeated runs. Compare models and harnesses against the same targets and known security cases. Track coverage, validation rate, cost, runtime, refusal behavior, and duplicate rate. Do not assume that the newest model or one successful scan provides complete coverage.
Retain the decisions as organizational context. Store findings, false positives, reachability decisions, accepted risks, mitigations, and fixes in a governed system with lineage. Each review should make later code, design, and dynamic reviews better informed.
Keep your context sovereign. Maintain ownership and control over the value you create. We outline 15 steps that every company can take to ensure both their sovereignty and alpha here.
Give security and product engineers a shared workflow. Engineers need to inspect evidence, add system context, validate severity, assign ownership, and develop and approve remediations without creating another disconnected security queue.
Connect verified fixes to normal software delivery. Approved patches should move through the same release, deployment, health-monitoring, and rollback controls used for other software changes.
Define success correctly. Generating a long list of findings is not the same as actually improving security. Success means reducing verified risk in deployed software and doing so with fixes that are delivered quickly, reliably, and efficiently.

Securing Software at the Speed of AI was originally published in Palantir Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.