The cleanest Ockam demo began with a little trick. A database lived in one private network. Its client lived somewhere else. Neither side opened an inbound port, changed a firewall, shared a long-lived password, or joined a giant virtual network. Ockam placed a small portal beside each application, created a mutually authenticated encrypted channel between them, and made the faraway database appear on localhost. The network did not actually vanish. It simply stopped being the developer’s problem.
That was the San Francisco company’s thesis in miniature. Distributed software had escaped the old corporate perimeter, but security practices still assumed that trusted things shared a network. Ockam moved the decision up a layer. Each workload received a cryptographic identity. Every connection authenticated both ends. Policies decided which identity could reach which service. Keys rotated; credentials expired; messages stayed encrypted across clouds, brokers, relays, and company boundaries.
Matthew Gregory and Mrinal Wadhwa arrived at the idea from opposite directions. Gregory had built real-time telemetry for America’s Cup boats and later developer APIs at Weather Underground. Wadhwa had watched connected devices become attractive targets as IoT spread. When they met in 2018, both had reached the same conclusion: identity, key management, secure protocols, and reliable routing were becoming a tax on every distributed application. Most teams could not afford specialists to assemble the stack correctly.
The first thing that failed was the sensible choice
In 2019, Ockam began in C. The logic was difficult to fault. C ran on tiny microcontrollers and powerful servers, and nearly every popular programming language could call into it. A portable core could support hardware security modules, different transports, and language-specific wrappers. For a company promising trust from edge device to cloud, “runs everywhere” sounded like the right first constraint.
Then the interface fought back. Secure channels are not a single encryption call. They are asynchronous, stateful exchanges that establish keys, authenticate identities, route messages, recover from errors, and keep their internal transitions in the correct order. Ockam wanted an application developer to create one safely with a line or two of code. In C, its attempts kept leaking the state machine into the user’s hands. The implementation could be portable and still be too easy to misuse.
“We wanted to hide these footguns away and provide developer interfaces that are easy to use correctly.”Mrinal Wadhwa, Ockam CTO
What changed the team’s mind was a prototype in Elixir. Its lightweight actors could each hold state, exchange messages, and run concurrently. Suddenly the layers - transport, routing, secure channel - could do their work behind one comprehensible function. Elixir was awkward for constrained hardware, but the actor model proved the product experience was possible. Rust supplied the missing combination: memory safety, performance, portable compilation, async functions, and pluggable runtimes. Ockam discarded tens of thousands of lines of C and rebuilt.
This was Ockam’s most expensive product lesson, even if the company never published a price for the rewrite. Months of work and a large C codebase were sunk. The alternative was worse: preserve the implementation and ship an abstraction that failed its central promise. The team chose the interface over the inventory.
What Ockam actually sold
The open-source repository supplied the primitives: identifiers, vaults, credentials, secure channels, routing, relays, and attribute-based access control. Ockam Command packaged them into terminal workflows. Portals sat beside unmodified applications and carried TCP protocols through secure channels. Orchestrator handled projects, enrollment, managed elastic relays, and operational chores in the cloud.
The business followed a familiar open-core shape. The code used the Apache 2.0 license. The managed layer sold subscriptions, usage, support, and cloud-marketplace convenience. Historical terms describe recurring and per-unit charges, but no dependable public price list survives. Customers were expected to compare that bill with a more slippery cost: engineers waiting on network approvals, specialists maintaining certificates and keys, and incident risk when shared secrets refused to die.
The target buyer was not a person searching for “better encryption.” It was a platform team connecting a client to a private database, a SaaS vendor adding private connectivity as an enterprise feature, or a data engineer moving Kafka events into Snowflake. Ockam’s public material names integrations and partners more often than paying customers, so its commercial scale is hard to measure. Its wedge, however, is visible: arrive where two valuable systems need to exchange data and neither owner wants to reconfigure the other’s network.
A narrow place between big categories
VPNs connect networks. Service meshes manage service-to-service traffic inside an environment. PrivateLink and VPC peering bind customers to cloud-specific network machinery. Reverse tunnels can expose a private endpoint without opening an inbound port. Secrets managers protect credentials. Ockam pulled parts of each job into a point-to-point, application-layer system and made identity the anchor.
The distinction mattered. A portal did not hand an application access to a subnet; it connected that application to one service. The endpoints authenticated one another cryptographically rather than trusting an IP address. An operator of an intermediate Kafka broker could carry ciphertext without being able to read it. Trail of Bits later reviewed the protocol design and said its cryptographic primitives followed industry best practice, while recommending clearer threat-model and design documentation.
Partnerships showed how Ockam hoped to distribute the idea. With InfluxData, it demonstrated unique, least-privilege credentials that could expire after 15 minutes instead of one fleet-wide token living forever. With Redpanda, it added producer-to-consumer trust to a streaming platform with more than 200 connectors. Snowflake marketplace workflows linked private databases, Kafka, SFTP, WebDAV, and APIs without asking users to expose an inbound service.
Security teams wanted control. Developers wanted localhost. Ockam built in the small strip where both could get what they wanted.
The part worth stealing
The first copyable idea is to make simplicity a security control. Ockam’s name nodded to Occam’s razor, and its rewrite followed the principle literally: remove decisions from the path where a user can make an unsafe one. A strong developer-security product should not merely document the secure configuration. It should make that configuration the shortest route.
Define exactly who needs to speak. Avoid granting a whole network when one service is enough.
Authenticate applications, not addresses. Attach policy to verifiable attributes.
Generate keys in place. Rotate them. Lease credentials with narrow scope and an expiry.
Test the developer experience in the architecture best suited to it before optimizing portability.
The second idea is organizational. Ockam published a team handbook that named Trust as its only value and exposed hiring, compensation, and operating beliefs. For a small remote company selling invisible infrastructure, this made the team legible. A founder can copy that without copying the rhetoric: publish how decisions are made, what “done” means, and what colleagues can expect when the company is under pressure.
The third is commercial focus. Ockam did not ask customers to replace Postgres, Kafka, or Snowflake. It wrapped those systems at the boundary and sought distribution through their ecosystems. Infrastructure startups often improve their odds when the new control arrives as an additive connection, not a migration.
When the pattern does not fit
Application-layer portals are a poor match when policy must cover an entire network, when endpoints cannot run a sidecar or change a host setting, when regulators require a particular network appliance, or when a team cannot operate the identity and relay lifecycle. Open code also does not replace a maintained commercial service: production adopters must verify releases, security patches, support, and any hosted dependencies.
The final pivot, and the untidy ending
In its later chapter, Ockam extended its actor system and trust machinery into Autonomy, a platform for long-running swarms of AI agents. The move was not as strange as it looked. Autonomous agents also need identities, private workspaces, controlled credentials, attribution, messaging, and elastic coordination. The company had spent years building those lower layers for distributed applications; agents were a newly urgent customer for the same architecture.
But relevance does not guarantee permanence. Ockam’s current LinkedIn description says the company dissolved in July 2026 after raising $17.5 million. Funding databases place the figure near $17.6 million, including a $12.5 million Series A completed in December 2021. Its public record does not provide a single autopsy, and inventing one would flatten a complicated business into a clean moral.
What remains is more concrete. The repository still carries thousands of stars, hundreds of forks, extensive documentation, and an Apache license. The audit is public. So are the rewrite story and handbook. They preserve a serious attempt to answer a question that has only grown louder: when software moves everywhere, where should trust live?
Ockam’s answer was close to the application, expressed through identity, and hidden behind a small interface. The company could not make every part of the business disappear cleanly. It did show which complexity was worth absorbing for the developer on the other side.