Josh spent 15 years at Workday, the last 10 as Chief Trust Officer and CISO.
Every prospective customer eventually asks some version of the same question: how do I know I can trust this system?
Having sat on both sides of that table, I’ve learned that trust isn’t something a vendor gets to claim because it hired the right people or checked the right boxes. It’s earned by showing how the thing was built, and by the people who built it being able to explain why.
Sol is still in the early stages, and that’s the point of writing this now. The decisions that determine whether an HR platform can be trusted are made at the beginning, in the architecture and in the culture, long before anyone asks for a certificate. We want to show you those decisions while they’re being made.
Culture first
Security professionals like to say people are the weakest link, but I’ve never bought that. People are the first line of defense.
That’s why I’m here this early. We have a window to make security and privacy part of how Sol operates, not just a function that reviews what everyone else did. Nobody at Sol needs to be as paranoid as a CISO. But everyone should be a little professionally paranoid, and treat protecting people’s data as part of their job. Commit to that early enough and it stops being a program and becomes part of the company DNA.
I didn’t have to talk anyone into this. Sol’s leadership understood that security takes sustained investment long before any crisis justifies it. Jim has written about it from the product side, and it looks the same from where I sit: security as a foundation, not an add-on.
Security is personal
It’s easy to talk about security in the language of systems: encryption, identity, detection, response, audit logs etc. All of it matters. None of it captures what’s at stake.
An HR system holds people’s compensation, their benefits, their performance reviews, and the private conversations about their careers. Many of those people will be our own friends, neighbors, and family, working somewhere that has the same job we do: keep it safe. Protecting that data is protecting people, and it’s about as personal as it gets.
Why “agentic” raises the bar
A peer can’t see a peer’s compensation, but their manager can, and that rule has to hold on every interaction, for every person, all the time. Add agents that can read and act across the company, and two new questions appear: whose authority is the agent using, and what did it see along the way?
A chat window bolted onto an old system can’t answer either. The permission model has to be the thing the agent runs on, not a layer it talks to.
The principles we build to
We may be early, but we made sure we were clear on our building principles from the start:
One permission model for people and agents. Whether a person clicks a button or an agent calls a tool, the same authorization applies. An agent acting on your behalf holds what you’ve delegated to it and nothing more. It can reason freely, but it can only act through governed paths, and actions with real consequences bring a human into the loop.
Privacy is a property of the data, not the screen. Every piece of personal data is classified as it’s defined, and that classification follows the data everywhere: what a role can see, what an agent can be shown, what appears in a decision record, how long it’s kept, how it’s erased. Asking the privacy question at the moment data is created, by the engineer creating it, is how privacy by design becomes more than a slogan.
Model access through one pre-determined path. Nothing in Sol talks to a model on its own. Every request passes through one governed checkpoint, so what it saw and said is always answerable.
Decisions are explainable, not just logged. An audit trail says what happened. A decision record says why: what information was available, which policies applied, and for agents, which model was involved and what it was working from. Anyone affected by a decision should be able to get an explanation in plain language.
Identity tied to employment. Access begins with a hire and ends with a termination, on terms each company sets for itself. Each customer’s data stays entirely its own, and inside our infrastructure nothing is trusted just because it arrived from somewhere upstream.
Where culture meets code
These aren’t just policies in a binder; they’re constraints the platform places on the people building it, so the secure path is the default path and the privacy question can’t be skipped.
Having built a platform of that scale once, I know which decisions, like how data gets classified or where authorization lives, are cheap to make on day one and nearly impossible to unmake later. So we made sure they were settled first at Sol.
Starting clean makes this possible. We don’t have decades of shortcuts to unwind, so these principles were set before the first customer record existed rather than retrofitted afterward. A clean slate isn’t an easy one, though. It means declining the shortcut every time, even when it would ship faster.
Trust is earned in the open
A real security conversation includes the parts that don’t fit on a marketing page, and I’ll keep having those directly. Our program is young and we’ll keep doing the work as the product and the threats around it evolve.
Fifteen years ago companies were deciding whether to trust a vendor with their most sensitive data in the cloud. We’re having a version of that conversation again. A CHRO choosing an AI-native HR platform is putting their own credibility on the line, and I understand that from years of sitting across the table from people making exactly that decision.
So if you ask how you can trust Sol, we’ll show you how it’s designed, introduce you to the people who designed it, and tell you where we’d push if we were sitting in your seat. Trust is a design decision. We’re making it on purpose.
