IT EN
Start a trial

Operational notes Partnerships

KODE Labs and Palantir FedStart: the FedRAMP High Authorization Belongs to Someone Else

7 min read

Air ducts, pipework and cable trays beneath a building ceiling, with a smoke detector, black-and-white photograph
Ducts, panels, sensors: what a building operations platform puts under one command is not screens — it is machines.

On 5 August 2026 KODE Labs, a Detroit company, announced via GlobeNewswire that it had “achieved FedRAMP® High authorization through Palantir Technologies’ FedStart program.” The release is accurate: the platform “is assessed against the NIST SP 800-53 Rev. 5 High baseline and is now listed on the FedRAMP Marketplace as part of Palantir’s Federal Cloud Service.” Read quickly, the headline sounds like a company’s own top-tier federal authorisation. The regulator’s register says something different: the authorisation is Palantir’s; KODE OS is a named component inside someone else’s authorised perimeter.

Who KODE Labs is, and what it signed with the GSA

KODE Labs was founded in Detroit and keeps operational offices in Detroit and Prishtina, Kosovo. It describes itself as “the intelligence infrastructure for the physical world,” deployed on “hundreds of millions of square feet.” In 2023 it was named a World Economic Forum Technology Pioneer. The release states a $14.35 million contract with the General Services Administration’s (GSA) Public Buildings Service, to deploy the platform across 150 buildings in the National Capital Region.

The federal record tells the same relationship with a different level of detail. The contract, PIID 47PM0024C0003, is held by KODE LABS, INC., administered by GSA/Public Buildings Service: signed on 9 September 2024, period of performance 10 September 2024 to 9 September 2029 (potential completion date 31 March 2030). A DEFINITIVE CONTRACT, awarded under FULL AND OPEN COMPETITION, no set-aside, solicitation 47PM0024R0003. The stated purpose, verbatim: “unified user interface (UUI) solution development to integrate, converge, and view data from various operational technologies for remote control and monitoring of facility equipment and systems.” As of today the obligated value on record is $9,564,451 (base plus exercised options); total potential value is not published (record last modified 21 August 2025). The declared $14.35 million and the obligated $9.56 million are not a contradiction: they are two different figures, the same distinction between promised and booked that we measured on another multi-year contract with options.

The technology: not a dashboard, a command

A “building operations platform” is not management software. It is the layer that integrates a building’s HVAC, lighting, access control, metering and sensors — systems that normally do not talk to one another, from different vendors and generations — into a single model that both monitors and commands. The GSA contract’s own purpose says as much: remote control and monitoring. This is operational technology (OT), not a records system: a command issued from this platform changes the physical state of a machine — a valve, a compressor, a gate — inside a federal building.

The register says something else

The FedRAMP Marketplace is the public catalogue of authorised cloud services. On today’s reading, across the whole catalogue the word “KODE” appears in exactly one place — and it is not a listing: no service is held in KODE’s name, either as provider (CSP) or as service (CSO). There are instead two Palantir listings, both “FedRAMP Certified” at the High impact level: FR2434554673, “Palantir Federal Cloud Service,” and FR2315464863, “Palantir Federal Cloud Service – Supporting Services” (PFCS-SS).

Inside the latter’s service description is where KODE appears: “KODE OS for Government – KODE OS is a FedRAMP High authorized, cloud-native building operations platform deployed within the Palantir FedStart environment that enables federal, state, local, and government contractor organizations to securely centralize, monitor, control, and optimize distributed facility infrastructure through unified data integration, real-time analytics, role-based access control, and automated…”

The same description names other third-party products hosted within the same perimeter: GovSignals.ai, Hyperscience Hypercell, Knightscope Security Operations Center (KSOC), Unstructured Platform, Valinor Harbor (HarborOS) — a perimeter shared by many tenants, not an arrangement dedicated to KODE. The published contacts are PFCS-SS@palantir.com for commercial enquiries and fedramp-isso@palantir.com for security: the named Information System Security Officer is Palantir’s, not KODE’s. This is not the first time we have seen the mechanism: we have written about the same FedStart before, for Oligo Security — same programme, different business.

The asymmetry in the communications

Whoever needs to announce something is usually not the one hosting it. The press release list on palantir.com/newsroom/press-releases is current — the most recent entry is from 3 August 2026, the second-quarter results — with no mention of KODE. The list is live and recent: the absence is a fact, not a limit of the search. No intent is implied: the small side of the deal is the one being announced.

What it means

For KODE, the deal is fast access to an otherwise prohibitive market: pursuing FedRAMP authorisation on one’s own takes years and an investment a young company can rarely carry. Co-founder Etrit Demaj put it his way: “Reaching FedRAMP® High is a milestone we’re proud of, but to us it means more than compliance.” It is also, though, a structural dependency: KODE is selling something that lives inside someone else’s perimeter. For Palantir, every tenant named in a listing like PFCS-SS is a channel bringing in further federal customers: it becomes the compliance infrastructure of an entire ecosystem, not just a software vendor.

For the market and for procurement, the effect is concentration: different suppliers — KODE’s building operations, Knightscope’s physical security, Unstructured’s data platform — end up behind the same perimeter, with the same ISSO. A problem there does not stay a single product’s problem. The same question applies to Europe and Italy, where cloud qualification catalogues are being built: how much do they risk reproducing the same architecture, an authorisation obtained inside someone else’s environment rather than one’s own? A question worth asking, not a regulatory forecast.

This is not a piece against either party. A young company that legitimately gains access to an otherwise closed market is making a sound industrial choice, and states it in the right words — “through,” “as part of.” A supplier that opens its own accredited perimeter is offering a real service, one that lowers a notoriously high barrier to entry. The point is not either party’s correctness: it is that buyers must know how to read what they bought — and the correct reading is not in the headline of the press release, it is in the catalogue listing.

The operational lesson

  1. When a supplier claims “we are certified,” ask whose authorisation it is and read the regulator’s catalogue listing, not the press release: if the supplier’s name is not the holder, the authorisation is not theirs.
  2. Check who is named as responsible for security in the catalogue listing: that name tells you who actually answers for it, not the logo on the press release.
  3. A component inside someone else’s perimeter inherits its fate: if the parent authorisation is suspended, whatever sits inside it stops too. Put in the contract what happens then.
  4. Ask about the exit before the entry: if the supplier leaves that perimeter, the authorisation does not stay with you — data, integrations and service continuity need to be settled before the first installation, not after.
  5. Check what the system commands, not just what it displays: for an OT system the right question is “who can move a machine, and with what log.”
  6. Always distinguish the declared amount from the obligated amount: on a multi-year contract with options the gap is normal, but it should always be checked.

The same check — whose authorisation this is, who the ISSO is, what happens if the perimeter falls, what is left if the supplier exits — is not a one-off review filed away. It becomes a control running on the client’s contracts and systems, feeding a register of critical dependencies — for every supplier: which authorisation, held by whom, with what expiry, with what alternative — with the audit trail ready to show an inspector. The same system unifies contracts, suppliers, archives, management software and documents into a single operational model on which AI agents execute decisions with a human operator in command, for large enterprises, defence, the public sector and healthcare. Always in two modes: on-premises on self-contained machines that do not require deep integration into the client’s network, or a dedicated cloud with a dedicated VPN and a data centre in Italy — always with shared management.

Do you need to check who actually answers for the security of a supplier that presents a certification obtained “through” a major partner? Let’s talk for thirty minutes.

Sources