It is important to understand that the customers don't have a clear view of the types of access controls they want until they start field exercises. By having relatively limited access controls in the prototype, they discover in real use cases that allowing some data access which never would have occurred to them is highly valuable which can then be refined into specific types of data sharing. In a default locked down environment, these beneficial interactions would never be discovered because they can't occur. All of the ways the users access and use data in the prototypes is logged and studied.
Similarly, other types of data sharing expose real risks that can be reduced to specific scenarios developed during operational exercises. The problem with an exhaustive access control model is that it simply has too many degrees of freedom to be usable for most people.
During development, the universe of all possible uses of access control is reduced to a much simpler and more understandable model of the key data it is important to restrict and the key data it is important to share, grounded in real-world operational learnings. These models are simpler and more precise to implement, and also easier to verify the correctness of, than a default "access control all the things" approach.
There's been no launch. It's a prototype.
We reject the notion of gating, pay-walling, or upselling core security controls like audit logging, single sign-on, and multi-factor authentication. Whether you’re a small business or a federal agency, you get access to every core enterprise security feature in our standard offering:
Mandatory encryption of all data, both in transit and at rest, that uses robust, modern cryptography standards. Strong authentication and identity protection controls, including single sign-on and multi-factor authentication. Strong authorization controls, including mandatory and discretionary access controls. Robust security audit logging for detecting and investigating potential abuse. Highly extensible information governance, management, and privacy controls to meet the needs of any use case. »
Given that segmentation of data access is a core part of the pitch (see e.g. https://www.palantir.com/docs/gotham) - if security controls were intentionally omitted from the prototype scope, that seems like a reckless scoping decision to make. And if security controls were unintentionally bypassed, this speaks to insufficient red-teaming of the prototype before launch.
I couldn't be more pleased that this is coming to light, though. Perhaps it opens decisionmakers' eyes to the dangers of over-centralizing military operations on a system that simultaneously allows operators to diffuse accountability to a semi-autonomous target-calling system, and is foundationally connected to surveillance-state systems tracking U.S. citizens. Entire genres of movies posit the negative outcomes of this kind of system on civilians and military personnel alike; they are cautionary tales to Not Create The Torment Nexus. Sometimes decentralized, human-in-the-loop, need-to-look-the-target-in-the-eyes operational coordination is a feature, not a bug.